<div dir="ltr">Thanks! That looks promising. I was actually fiddling a little with timesyncd and trying to have it always update its /var/lib/systemd/timesyncd/clock file. But couldn't get it working. I guess I had the same problem that the thread mentions regarding startup-order. <div> </div><div>//Magnus</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 21, 2020 at 1:17 PM Dave Howorth <<a href="mailto:systemd@howorth.org.uk">systemd@howorth.org.uk</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 21 Sep 2020 10:16:38 +0200 Magnus Berglund <<a href="mailto:wmmabeu@gmail.com" target="_blank">wmmabeu@gmail.com</a>> wrote: > Hello, > > I have an embedded system that does not have a real-time clock. I was > hoping to run journald on it, but have run into some problems. > > My problem is that my system currently does not guarantee a > monotonically increasing time, and that seems to confuse journald a > bit. > > Btw: I've tested this on v243-stable. > > (The system syncs over NTP, but there are some issues with this as > well, more on that later) > > I originally found the problem since there were boots missing. E.g) > > # journalctl --list-boots > -4 44cabeed86e34d09a4eca0dbff43b19f Mon 2020-08-03 14:27:59 UTC—Tue > 2020-09-15 09:13:52 UTC > -3 71164e7d83a9448c9e70bb59b6190a45 Tue 2020-09-15 09:13:52 UTC—Tue > 2020-09-15 09:14:48 UTC > -2 2e565a1c8dc84d4e95055e4cb4d0cc25 Tue 2020-09-15 09:14:48 UTC—Tue > 2020-09-15 09:16:11 UTC > -1 3c672d6fb8084f5fa5923a1ae5e0e53d Tue 2020-09-15 09:16:11 UTC—Tue > 2020-09-15 09:31:52 UTC > 0 afc0d98f275e4999aa061c7bb61b85d2 Tue 2020-09-15 09:33:35 UTC—Tue > 2020-09-15 09:56:12 UTC > > # journalctl -F _BOOT_ID > 44cabeed86e34d09a4eca0dbff43b19f > 71164e7d83a9448c9e70bb59b6190a45 > 1465a36c753f43df92bcc0a76d8e763e > 2e565a1c8dc84d4e95055e4cb4d0cc25 > 3c672d6fb8084f5fa5923a1ae5e0e53d > afc0d98f275e4999aa061c7bb61b85d2 > 302cc41b146c4b3c88f06df102913c3f > > I've poked around in the source code think I found the reason for > this: journal_file_compare_locations() (in journal-file.c) compares > seqnum if within the the same seqnum_id, but uses current_realtime if > not within the same seqnum_id. Since my realtime can't be trusted I > sometimes have journalfiles within the same seqnum_id which "jumps" > back in time. That combined with the traversal in real_journal_next() > gives a stochastic behaviour. > > I have tried fixing my clock to give a monotonically increasing > clock. But: I want my system to boot as fast as possible, even without > a NTP-syncronized time. And I've noticed that if I shutdown before > getting a NTP time timesyncd will not have touched the "clock" file, > and I end up in the situation above. > > Now to my question: What is the best practice in using journald on > systems without RTC? It it even "supported"? > > /Regards, > Magnus Berglund There was recently a long thread about some of these issues, but specifically as they apply to Raspberry Pis. I think it's worth reading as a first step, though. The thread starts at <a href="https://lists.freedesktop.org/archives/systemd-devel/2020-August/045118.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/systemd-devel/2020-August/045118.html</a> _______________________________________________ systemd-devel mailing list <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div>