On Tue, Nov 06, 2012 at 02:21:52PM +0100, Carlos E. R. wrote:

On 2012-11-06 12:38, Frederic Crozat wrote:

...

Le mardi 06 novembre 2012 à 12:01 +0100, Dr. Werner Fink a écrit :

...

Hi,

due several bug reports, I'm currently reading the code of systemd-195 as found in oS:Factory. I'm a bit surprised about some missing features and bottlenecks:

* There is no --adjust functionality to handle systematic drift of the HW/RTC clock of the BIOS * There is no --badyear functionality for broken some Award BIOS * It ignores s390 as well as XEN clients * It does not provide --systohc functionality which had lead to several bug reports about the fact that the system clock is not written back to RTC at shutdown/reboot * It does not check for the SUSE /dev/shm/warpclock ... OK this does not cause a problem as settimeofday(2) with its timezone is sealed within the kernel after warpclock has been called in the initrd. I'm wondering how the timestamps of the root file system will be repaired if the timezone correction would not be done in the initrd.

... the question rises if we should try to implement this in the C source of systemd (src/shared/hwclock.c and src/timedate/timedated.c) or is there a way to avoid the systemd-timed service with a more complete but shell code script executed by a systemd service unit at boot as as at shutdown/reboot.

It would be much better to raise those points directly on upstream mailing list, since they are not openSUSE specific (and I don't know how they are handled by other distributions either).

Most if not all of those were handled previously by openSUSE scripts which systemd replaces.

Indeed as I'm the author of this script. Interesting there seems to be several solutions around: https://bugs.archlinux.org/task/31674 https://bugs.mageia.org/show_bug.cgi?id=2521 http://en.gentoo-wiki.com/wiki/Systemd#hwclock most of them outdated due upstream development. In other words only if /lib/systemd/system/systemd-timedated.service will be skipped such a /usr/lib/systemd/system/hwclock.service would make sence. But this would make both the documented timedatectl and also the usage over the dbus message channel useless. On the other hand using an optional hwclock.service after the upstream systemd-timedated.service could be an option simply to use hwclock --hctosys at shutdown Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Nov 06, 2012 at 02:21:52PM +0100, Carlos E. R. wrote:

On 2012-11-06 12:38, Frederic Crozat wrote:

...

Le mardi 06 novembre 2012 à 12:01 +0100, Dr. Werner Fink a écrit :

...

Hi,

due several bug reports, I'm currently reading the code of systemd-195 as found in oS:Factory. I'm a bit surprised about some missing features and bottlenecks:

* There is no --adjust functionality to handle systematic drift of the HW/RTC clock of the BIOS * There is no --badyear functionality for broken some Award BIOS * It ignores s390 as well as XEN clients * It does not provide --systohc functionality which had lead to several bug reports about the fact that the system clock is not written back to RTC at shutdown/reboot * It does not check for the SUSE /dev/shm/warpclock ... OK this does not cause a problem as settimeofday(2) with its timezone is sealed within the kernel after warpclock has been called in the initrd. I'm wondering how the timestamps of the root file system will be repaired if the timezone correction would not be done in the initrd.

... the question rises if we should try to implement this in the C source of systemd (src/shared/hwclock.c and src/timedate/timedated.c) or is there a way to avoid the systemd-timed service with a more complete but shell code script executed by a systemd service unit at boot as as at shutdown/reboot.

It would be much better to raise those points directly on upstream mailing list, since they are not openSUSE specific (and I don't know how they are handled by other distributions either).

Most if not all of those were handled previously by openSUSE scripts which systemd replaces.

Indeed as I'm the author of this script. Interesting there seems to be several solutions around: https://bugs.archlinux.org/task/31674 https://bugs.mageia.org/show_bug.cgi?id=2521 http://en.gentoo-wiki.com/wiki/Systemd#hwclock most of them outdated due upstream development. In other words only if /lib/systemd/system/systemd-timedated.service will be skipped such a /usr/lib/systemd/system/hwclock.service would make sence. But this would make both the documented timedatectl and also the usage over the dbus message channel useless. On the other hand using an optional hwclock.service after the upstream systemd-timedated.service could be an option simply to use hwclock --hctosys at shutdown Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org