Discussion:
systemd and hardware real time clock
Add Reply
Michał Zegan
2017-01-17 11:29:09 UTC
Reply
Permalink
Raw Message
Hello.

I am aware of the fact that systemd relies on the kernel to set system
clock from hardware clock, and that requires compiling rtc drivers into
the kernel, not as modules.
I am also aware that doing it othervise would mix timestamps in log entries.
The question is: if I have rtc driver as a module anyway, how to modify
initramfs so that system time would be set, in such a way so that it
happens *before* journald in initramfs starts? I assume it is an
initramfs using systemd inside of it.
One approach would be to have an udev rule that does trigger after rtc
appears or rtc symlink is added, this rule would start a service that
sets the system clock, but this service would have to always run before
journald, and that seems not possible in such a configuration, because
if someone would unplug the rtc the service would not run?
Another thing is to load rtc and i2c bus module where rtc is connected
statically without udev detection, and then the hwclock service would
always be triggered before journald without looking for rtcs appearing...
Lennart Poettering
2017-02-09 14:52:47 UTC
Reply
Permalink
Raw Message
Post by Michał Zegan
Hello.
I am aware of the fact that systemd relies on the kernel to set system
clock from hardware clock, and that requires compiling rtc drivers into
the kernel, not as modules.
I am also aware that doing it othervise would mix timestamps in log entries.
The question is: if I have rtc driver as a module anyway, how to modify
initramfs so that system time would be set, in such a way so that it
happens *before* journald in initramfs starts? I assume it is an
initramfs using systemd inside of it.
One approach would be to have an udev rule that does trigger after rtc
appears or rtc symlink is added, this rule would start a service that
sets the system clock, but this service would have to always run before
journald, and that seems not possible in such a configuration, because
if someone would unplug the rtc the service would not run?
Another thing is to load rtc and i2c bus module where rtc is connected
statically without udev detection, and then the hwclock service would
always be triggered before journald without looking for rtcs appearing...
Well, you could write a tool that uses libudev but listens on the
kernel mcast group instead of the udev one, and then, as soon as the
RTC showed up would do the /dev/thing. Then, make a service of it,
make sure to use StandardOutput=null + StandardError=null, so that you
don't get an implicit dependency on journald, and order the service
before journald.

Lennart
--
Lennart Poettering, Red Hat
Michał Zegan
2017-02-09 15:14:49 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Michał Zegan
Hello.
I am aware of the fact that systemd relies on the kernel to set system
clock from hardware clock, and that requires compiling rtc drivers into
the kernel, not as modules.
I am also aware that doing it othervise would mix timestamps in log entries.
The question is: if I have rtc driver as a module anyway, how to modify
initramfs so that system time would be set, in such a way so that it
happens *before* journald in initramfs starts? I assume it is an
initramfs using systemd inside of it.
One approach would be to have an udev rule that does trigger after rtc
appears or rtc symlink is added, this rule would start a service that
sets the system clock, but this service would have to always run before
journald, and that seems not possible in such a configuration, because
if someone would unplug the rtc the service would not run?
Another thing is to load rtc and i2c bus module where rtc is connected
statically without udev detection, and then the hwclock service would
always be triggered before journald without looking for rtcs appearing...
Well, you could write a tool that uses libudev but listens on the
kernel mcast group instead of the udev one, and then, as soon as the
RTC showed up would do the /dev/thing. Then, make a service of it,
make sure to use StandardOutput=null + StandardError=null, so that you
don't get an implicit dependency on journald, and order the service
before journald.
Lennart
Btw, about the argument that the kernel should set rtc time because of
wrong timestamps in logs, so I should compile the rtc into the kernel:
let's compare: if I read rtc time during bootup (and rtc is a module),
timestamps would be bad indeed for some time.
But one case is, what if there is no rtc? then the kernel cannot read
the clock. Neither can startup scripts or systemd (if it would ever
try). so log timestamps would be invalid for far longer, until time is
synchronized from network, and that will never happen if there is no
network. So I still think that systemd could do it, or, better,
initramfs could do it to make all real system logs have a valid
timestamp, like not sure if initramfs logs are important for anything if
there were no boot issues.
Lennart Poettering
2017-02-09 17:49:29 UTC
Reply
Permalink
Raw Message
Post by Michał Zegan
Btw, about the argument that the kernel should set rtc time because of
let's compare: if I read rtc time during bootup (and rtc is a module),
timestamps would be bad indeed for some time.
But one case is, what if there is no rtc? then the kernel cannot read
the clock. Neither can startup scripts or systemd (if it would ever
try). so log timestamps would be invalid for far longer, until time is
synchronized from network, and that will never happen if there is no
network. So I still think that systemd could do it, or, better,
initramfs could do it to make all real system logs have a valid
timestamp, like not sure if initramfs logs are important for anything if
there were no boot issues.
Not sure I follow? What precisely do you mean?

if there's no RTC then the timestamps of all logs before we managed to
get an NTP network fix will always be pretty bad, there's little we
can do about that? Or what are you saying?

Lennart
--
Lennart Poettering, Red Hat
Michał Zegan
2017-02-09 17:58:54 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Michał Zegan
Btw, about the argument that the kernel should set rtc time because of
let's compare: if I read rtc time during bootup (and rtc is a module),
timestamps would be bad indeed for some time.
But one case is, what if there is no rtc? then the kernel cannot read
the clock. Neither can startup scripts or systemd (if it would ever
try). so log timestamps would be invalid for far longer, until time is
synchronized from network, and that will never happen if there is no
network. So I still think that systemd could do it, or, better,
initramfs could do it to make all real system logs have a valid
timestamp, like not sure if initramfs logs are important for anything if
there were no boot issues.
Not sure I follow? What precisely do you mean?
if there's no RTC then the timestamps of all logs before we managed to
get an NTP network fix will always be pretty bad, there's little we
can do about that? Or what are you saying?
Lennart
Yes, exactly. In addition I was just saying that the above means, that
there is nothing bad in letting systemd (or something else after kernel)
handle modular rtcs. Because rtc in the kernel still does not cover all
possible cases (like missing rtc), and rtcs are very often compiled as
modules. Although I now believe initramfs may be a better place for
reading hardware clock than systemd running on a real root, that will
make proper boot logs have good timestamps I think, only initramfs and
the kernel will have timestamp problems.

Loading...