On Wed, 27.08.14 09:50, Lukasz Stelmach ([email protected]) wrote: > Yes that is a point. However, the current description the man page > provides is a bit less accurate than the above. Then, the delay you > describe does not seem as bad to me as you say. Suppose we've got two > services: aiccu, systemd-logind. Their dependencies look (very) roughly > like this: > > > multi-user.target > / \ > aiccu.service--------- systemd-logind.service > | \ | > time-sync.target \___basic.target > | > | sysinit.target > | / > systemd-timesyncd.service > > This means that waiting for systemd-timesyncd to contact NTP server > indeed delays reaching multi-user.target but it does not affect > systemd-logind (actually it does, because systemd-timesyncd is wanted by > sysinit.target but if it was a part of multi-user.target then it is not > a problem (time-sync-wait.service?)) or any other services that do not > depend on time-sync.target. If a service really needs "correct time" > then I assume its authors and users are aware of the fact it won't start > that instantly upon boot. > > You are right saying RTC provides acceptable accuracy in most cases and > NTP is ther to correct slight errors. There are systems (distributed > filesystems?) that need sub(micro?)second accuracy provided by PTP. > Other systems may use GPS receivers which make network connectivity > unnecessary. Mobiles may use GSM network to get time (I wonder if > entering PIN is required). > > All in all, IMHO, time-sync.target should be reached after synchronising > the system clock which doesn't have to mean delaying services that make > the system appear to boot fast. It appears to be easier to provide a > single target that modify many applications to check for STA_UNSYNC in a > loop.
I have now added a TODO list item, for a minimal service systemd-timesync-wait.service or so, that works akin to systemd-network-wait-online.service or so. I find this kinda ugly, but, I figure it might have some users.... That said, I can only recommend apps who really want accurate clocks to subscribe to time jumps via TFD_TIMER_CANCEL_ON_SET and then check for the STA_UNSYNC flag. It's certainly much nicer. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
