Package: ntp
Version: 1:4.2.4p6+dfsg-2
Severity: important
User: initscripts-ng-devel@lists.alioth.debian.org
Usertags: incorrect-dependency
I discovered this problem while working on the dependency based boot
sequencing. The issue at hand is in what order the ntp and syslog
services should start during boot, and related to this is the
definition of the $time virtual facility.
Services requiring correct clock is supposed to have their init.d
script depend on $time to get this. At the moment in Debian, $time do
not imply that ntp is active, because it would lead to a dependency
loop. The problem affects all syslog implementations, and for
simplicity my example only include rsyslog.
These are the dependency headers in question:
### BEGIN INIT INFO
# Provides: rsyslog
# Required-Start: $remote_fs $time
# Required-Stop: umountnfs $time
# X-Stop-After: sendsigs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO
### BEGIN INIT INFO
# Provides: ntp
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO
The ntp daemon want to log to syslog, and thus depend on $syslog. The
syslog daemon want a correct clock, and thus depend on $time. If
$time implies ntp to be started, we have a dependency loop like this:
rsyslog -> $time -> ntp -> $syslog -> rsyslog
I believe the correct behaviour is for syslog to get a correct clock,
and this can be done by splitting the ntp script in two, one setting
the clock once during boot, and the other starting the daemon. The
$time virtual facility can then depend on the once-during-boot script,
and the existing ntp script can continue depending on $syslog, leading
to this dependency thread:
ntp -> $syslog -> rsyslog -> $time -> ntp-once
An alternative, is for the ntp daemon to start before the syslog
collector is operational, loose a few syslog messages during boot and
get a correct clock in the syslog messages. For this to happpen, ntp
would need to drop its dependency on $syslog.
What is your opinion on this? I am aware that you recently dropped
the ntpdate script, which would have made sense to run before the
syslog implementation was operational.
Before this issue is resolved, it is impossible to change the
definition of $time to match the LSB specification:
$time
the system time has been set, for example by using a network-based
time program such as ntp or rdate, or via the hardware Real Time
Clock.
At the moment it only uses the hardware real time clock.
Happy hacking,
[...] Note that if you're trying to use ntpd to set the clock, it might take several minutes before it first attempts to correct the clock, so just depending on ntp is probably not going to give you the behaviour you want. Using something like rdate or ntpdate assumes the network is up and you can reach a suitable ntp server, which isn't always the case. You do not want to halt the whole boot process waiting for a timeout of that, which is why we started running it in the background. So depending on something like that is still not going to give you the behaviour you want. I think the hardware RTC is good enough for normal cases. The kernel writes the RTC when ntpd is running. Assuming the hardware properly keeps time while it's powered off, it's good enough. I also don't think it's useful to not log the message that ntpd generates while it's starting. Kurt
[Kurt Roeckx] I know. With concurrent booting, only those init.d scripts needing $time will wait for it, which might not be all. But I understand this could be a problem if the NTP server isn't local on the network. When I used ntpdate, it always returned quickly, so I never have experienced this problem myself. If I understand you correctly, you believe Debian should keep the non-LSB compliant behavoiur of $time? Is that correct? Happy hacking,
I don't see how it's not compliant? Kurt
[Kurt Roeckx] ntp and rdate is listed specificly in the $time definition, and I believe the reasonable expectation of people writing scripts depending on $time to have ntp synchronization done before their script is started. At least I understand the LSB comment to mean that if ntp or rdate is installed and available on the machine, they will be used for clock synchronization by $time. Of course, I might have misunderstood the intention of the LSB text, and I see that it can be interpreted differently. Happy hacking,
Yeah, I think I want syslog to start as soon as possible, even if the clock is slightly off. Actually, if your hardware clock is so far off that it would confuse syslog or make its entries useless, then ntp might also bail.
One possible solution to this would be to have $time be provided by another init script, say called ntp-done, that waits (via ntpq or something) until ntp has finally set the time.
I think the consensus among the ntp maintainers is that syslog should start before ntp. Do we need more discussion, perhaps on debian-devel, about how to achieve a proper $time facility implementation?
retitle 542602 "event based boot system needed to solve use cases" thanks <h01ger> pere, isnt #417118 solved by dependency booting? <pere> h01ger: nope. it is one of the problems that need event based boot to work. <h01ger> when do you expect event base booting in debian? IOW: isnt that something, the user needs to configure? <pere> h01ger: with the current rate of fixing the remaining stuff with upstart, in squeeze+1. <h01ger> upstart fixes that? <pere> upstart make it possible to fix that. it is a event based boot framework. <pere> then ntpdate can run when the network is up and the dns server is available. <h01ger> nice <pere> h01ger: a similar issue is #542602 <h01ger> pere, can i quote this in 417118? <pere> h01ger: sure. <pere> I suspect a workaround would be to have several init.d scripts for ntpdate, all running the program when their time has come. :)
I'm not sure why you send this to this bug. It's not useful to wait until ntpd is started, if you want to wait on something related to ntpd is that it decided it's in a sync state. And that can take some time. If there really are services that want to wait for that you can use something like ntp-wait. Upstream also seem to be working on a --wait-sync option to ntpd itself. Most services want the time to be more or less correct, for most an offset of a few seconds will probably not even be a problem. Maybe it would be useful to also have an "event" for that. This is something ntpdate can do now, maybe it would be useful that ntpd also has such an option? (Ntpdate will be removed at some point.) Maybe $time should be that event. Anyway, with some event based "boot" thing, it's probably easier to write something that waits for ntpd to be synchronised. Kurt
ntpd can also emulate ntpdate's behaviour with the -q option, and that doesn't take that long. Kurt
Hi Kurt, Because I'm stupid / made a mistake. It was ment for 417118... :-/ cheers, Holger
See also: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/288905 https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1125726 The way I read "man ntpd" (on Debian wheezy), we should replace ntpdate by "ntpd -q"; and if we are going to run ntpd then ntpdate is unnecessary anyway. If we have (or are going to have) ntpd, then we should simply skip /etc/network/if-up.d/ntpdate; seeing how that depends on NTPSERVERS in /etc/ntp.conf or somesuch, I do not see that /etc/network/if-up.d/ntpdate is ever any use. Cheers, Paul Paul Szabo psz@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia