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