Hello Lukas Wunner, Thanks for your bug report.
On Wed, Feb 15, 2017 at 01:55:30PM +0100, Lukas Wunner wrote: > Back in 2011, hwclock-set was amended to bail out if systemd is present. > According to #629811 the rationale was that "systemd > 25 sets the > hwclock itself, based on the contents of /etc/adjtime, so > /lib/udev/hwclock-set should not do anything if running under systemd." [...] > In most cases, the kernel itself initializes the system clock from the > RTC with the late_initcall rtc_hctosys(): > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/rtc/hctosys.c I see you've researched this well and agree with most of your rationale. > > But this doesn't work if the driver for the RTC is compiled as a module > or if the kernel was compiled with CONFIG_RTC_HCTOSYS disabled. Second (easy) case first, if CONFIG_RTC_HCTOSYS is disabled then I think we should not second guess this at all. period. For the module part, I'd consider this a problem on the kernel side primarily. If this problem won't/can't be fixed in the kernel itself then I'd rather see the entire kernel mechanism deprecated and a proper userspace component designed to handle it all. Usual rationale being that it's not the kernels job to define policy. There's just too many examples of unclear lines about what the kernel does and what userspace should handle that just causes problems when people randomly poke at small bits on either side. Oh well, so much for my wishful thinking.... > One use case where both of these prerequisites are not met is the > Raspberry Pi: > Raspbian ships with a kernel which disables CONFIG_RTC_HCTOSYS and also > compiles all RTC drivers as a module. This makes sense because the > Raspberry Pi does not possess an RTC. Instead, people use add-on boards > with various types of clocks and it wouldn't be reasonable to link all > of their drivers into the kernel. > > The Internet is full of recipes where /lib/udev/hwclock-set is edited to > remove the lines which cause it to bail out when detecting presence of > systemd, as otherwise the system clock is never initialized from the RTC. > But this approach has the disadvantage that the change will get > overwritten whenever the util-linux package is updated. Examples: > https://learn.adafruit.com/adding-a-real-time-clock-to-raspberry-pi/set-rtc-time > https://afterthoughtsoftware.com/products/rasclock > http://spellfoundry.com/sleepy-pi/setting-up-the-real-time-clock-on-raspbian-jessie/ A better approach would be for the RPi solutions to ship (a package containing) a separate rules file and a script that (in best of worlds detects it's being run on the targeted hardware) and does what's needed. No hacking of util-linux packaged files needed and no unwanted overwrites. > > Constrain the check for systemd presence in hwclock-set to the > invocation of "hwclock --systz", and do set the system clock from the > RTC unless the kernel has already done that (in which case > /sys/class/rtc/rtc0/hctosys contains "1".) > > This patch was developed for and tested successfully on a Revolution Pi > by Kunbus GmbH. Not a total fan of your patch. Consider the case where a system has more than one RTC. Consider specifically when CONFIG_RTC_HCTOSYS_DEVICE is set to rtc1. With your patch applied that would mean that we'd start running: /sbin/hwclock --rtc=rtc0 --hctosys (without first running: /sbin/hwclock --rtc=rtc0 --systz) right? That seems bad. (That the current udev rule only targets rtc0 is another thing I'd consider a bug. But that might be another discussion.) If we're trading one set of problems for another here, then I'm more comfortable with staying with what we currently have as with that these bitrotten and hacked up scripts are atleast pretty contained (overly unused means atleast they're not causing harm). Ideas welcome on something that would work for everyone. Regards, Andreas Henriksson
