[systemd-devel] systemd and hardware real time clock

[Michał Zegan]

W dniu 09.02.2017 o 18:49, Lennart Poettering pisze:
> On Thu, 09.02.17 16:14, Michał Zegan (webczat_200 at poczta.onet.pl) wrote:
> 
>> 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.
> 
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 525 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170209/21c83400/attachment.sig>