Bug#882851: live-config: Wrong time when RTC is set to local time
Hi Santiago and others,
Santiago García Mantiñán:
> I believe that systemd is reading /etc/adjtime before live systems adds the
> LOCAL label to it, or something similar (this is just my thought, no
> evicence pointing at this yet).
Right, systemd starts before live-config (well, it starts live-config)
so live-config's 1120-util-linux is simply late at the party.
FWIW the relevant systemd code lives in the initialize_clock function
(which calls clock_is_localtime, that parses /etc/adjtime).
> I have done some tests and at the time 1120-util-linux just a few systemd
> services are running:
> root 441 0.6 0.4 39176 4400 ? Ss 15:04 0:00 /lib/systemd/systemd-journald
> systemd+ 492 0.4 0.4 129344 4192 ? Ssl 15:04 0:00 /lib/systemd/systemd-timesyncd
> in fact, no other service is running except for init, lvmetad, the kernel
> processes and live-config itself.
I think timedatectl talks to systemd-timedated.service which is
activated on request over D-Bus. D-Bus typically starts after
live-config but systemd sets up its listening socket early, so I'm not
sure what's going on. I'm not sure that we can expect timedatectl to
work during this stage of the boot process but if you want to go
further down this path, I would suggest trying to do that in a new
live-config-hwclock.service that starts after dbus.service, at least
to better understand what's going on; and if despaired, add some
debugging to method_set_local_rtc in timedated.c.
> So... the question here is... how to we tell systemd at this time of the
> boot process that we have the RTC in LOCAL time if setting LOCAL on third
> line of /etc/adjtime at this time doesn't work and we cannot use timedatectl?
I think there are three main options:
1. Have live-config use hwclock to apply the updated /etc/adjtime
I guess calling "hwclock --systz" when utc=no should do
the trick: that's what dracut does in the initrd it generates,
whenever /etc/adjtime says "LOCAL". But beware:
- Reading the systemd source code and hwclock manpage, it seems
that some of the operations we want to perform only work the very
first time. So once systemd has done them once, it may be too
late, so I'm not sure if this can possibly work. But I think it's
cheap enough to be worth trying.
- Brutally applying a N hours offset to the system time while other
services have already started has potential to break all kinds of
things. Thankfully we have DefaultDependencies=no and
Before=basic.target so the risk is somewhat limited. It might be
worth checking if there's anything else we can do to start
live-config even earlier, before other important services that
have DefaultDependencies=no and might dislike time travel.
2. Move this to live-boot
There, mimic what dracut does and call "hwclock --systz" when
utc=no. I don't know if we also need to write /etc/adjtime there
and I don't know if there's a hook point for initramfs-tools
scripts to run after the root FS has been mounted read-write but
before init is started.
If that works and option #1 doesn't, it can be the cheapest
short-term solution. Long-term, given the move to dracut seems
unavoidable, it adds code that will need to be ported, which might
be problematic (although I expect that teaching dracut to honor
utc= would be easy).
3. Move this to systemd
i.e. add the equivalent of the live-config.utc= option there and
make sure clock_is_localtime honors it. At first glance it looks
like the best option: every systemd-based OS benefits from it, this
works with dracut too, and we can remove code from live-config.
Assuming that would be accepted upstream, the only major downside
I see is that it makes it harder to implement automatic discovery
of "is RTC in UTC?", which I'm very interested in: that's why
I landed here in the first place, will file a wishlist bug blocked
by this one shortly.
So I would recommend trying (1) and if that fails, trying (2).
Meta: is this something you're interested in working on
further yourself?
Cheers,
--
intrigeri
Reply to: