Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Thu, Dec 5, 2013 at 6:02 AM, Paul B. Henson hen...@acm.org wrote: Bug 493358 has a patch to fix this. With the patch, openntpd will background within approximately 15 seconds plus however long your resolver is configured to take to timeout a dns query. Perhaps now we can just ditch the syslog use flag and remove the option to run in debugging mode with stderr redirected? I don't think there was any need for it other than to resolve the delayed startup bug, which I'm reasonably confident this does... Awesome! Yeah, I think this should make it possible to roll back some of those other things. I'm glad I wasn't crazy, thanks for looking into this. Cheers, Dirkjan
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Fri, Nov 22, 2013 at 03:44:42PM -0800, Paul B. Henson wrote: I've tested a variety of scenarios, from the network interface being down/unplugged, providing invalid NTP servers, etc., and I haven't seen a delay longer than 15 seconds. I tracked down the failure mode where openntpd will take forever to start. If you use host names in your config rather than IP addresses, and dns lookups fail, there's a scenario where it will just sit there repeatedly making dns lookups until the end of time 8-/. Basically, the 15 second timeout in the current version only checks for the timeout to lapse while waiting for a response from the unpriv'd child process. If the child process has an ntp server to ask for the time, and it takes more than 15 seconds to get a response, the parent gives up on the initial time setting and backgrounds. However, in this failure scenario, the child asks for a dns lookup, the parent times out trying and tells the child sorry no go, and then the child asks again. And again. There is never a 15 second period where the child is unresponsive, the delay is always in the parent waiting for the dns lookup. Bug 493358 has a patch to fix this. With the patch, openntpd will background within approximately 15 seconds plus however long your resolver is configured to take to timeout a dns query. Perhaps now we can just ditch the syslog use flag and remove the option to run in debugging mode with stderr redirected? I don't think there was any need for it other than to resolve the delayed startup bug, which I'm reasonably confident this does...
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sun, Dec 01, 2013 at 09:59:37AM -0700, Christoph Junghans wrote: back to the original mechanism where openntpd runs normally as a daemon and logs to syslog This is exactly what the syslog use flag in openntpd-20080406-r5 does. (And syslog is enabled by default in most profiles.) The syslog use flag is a bit of a kludge, it makes the ebuild delete a hardcoded chunk of the init script when it installs it, plus the logrotate file is still installed unconditionally and could conflict with syslog logging, so I don't really think that's a good solution. And syslog isn't enabled in the default profile: virtz # eselect profile list Available profile symlink targets: [1] default/linux/amd64/13.0 * virtz # ACCEPT_KEYWORDS=~amd64 emerge -pv =net-misc/openntpd-20080406-r5 Calculating dependencies... done! [ebuild U ] net-misc/openntpd-20080406-r5 [20080406] USE=ssl (-selinux) -syslog% 12 kB I've seen two reasons for the current kludgy init script: * boot delays * openrc likes pid files Boot delays are avoided by not passing the -s option; and if the -s option causes a delay longer than 15 seconds that's a bug that should be fixed, not kludged around. It's far cleaner to just add pid file support directly to the daemon rather than try to kludge around it in an init script. There's really no valid reason not to just put the ebuild back to its original state, there's no need for a syslog use flag, and running in debug mode with hardcoded stderr logging isn't exactly a reasonably alternate logging mode. My offer to debug boot delays in excess of 15 seconds upon supply of a reproducible configuration that causes them still stands too... I hope djc, as the original person concerned, can comment on that. I saw a message from him early in the thread, but haven't seen any reproducible configuration resulting in an extended delay.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 09:21:32PM -0800, Paul B. Henson wrote: and logs to syslog, I'll put together a patch that adds a -p argument to optionally create a pid file after daemonizing... Bug 493082 contains a patch to openntpd adding a pid file option, along with an updated ebuild that uses it...
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Dnia 2013-11-30, o godz. 21:13:58 Paul B. Henson hen...@acm.org napisał(a): On Sat, Nov 30, 2013 at 09:14:30AM +0100, Michał Górny wrote: You know, usually it's enough to ping upstream. AFAIR there was a similar problem in irqbalance, and they have added plain '--foreground' for us. I think adding a pid option would be better than adding a foreground option, at least for openrc purposes; although a foreground option that wasn't debugging mode and still logged to syslog would be better than the current gentoo state. For current OpenRC -- maybe. For systemd and hopefully future OpenRC capable of service supervision, PID file is just useless cruft and foreground option is much more fun. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sun, Dec 01, 2013 at 02:17:18PM -0800, Paul B. Henson wrote: Bug 493082 contains a patch to openntpd adding a pid file option, along with an updated ebuild that uses it... Someone had asked me offlist about using SIGUSR1 instead of SIGINFO for dumping peer status, and as long as I had my fingers in the code I made a patch for that too, bug 493084.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sun, Dec 01, 2013 at 11:28:25PM +0100, Michał Górny wrote: For current OpenRC -- maybe. For systemd and hopefully future OpenRC capable of service supervision, PID file is just useless cruft and foreground option is much more fun. Dunno about the future of openrc, but as far as systemd I'm currently in the meh camp ;), so somebody else can worry about a foreground option :). Although it would be pretty trivial to implement.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Dnia 2013-11-29, o godz. 17:33:18
Paul B. Henson hen...@acm.org napisał(a):
On Fri, Nov 29, 2013 at 09:49:03AM +0100, Lars Wendler wrote:
I think there's some confusion on what the -d option actually does, so
let me cite the relevant parts from man 8 ntpd:
[...]
Now let's discuss if this can be considered as debug mode or not.
Let me cite the relevant code ;) :
ntpd.c:
while ((ch = getopt(argc, argv, df:nsSv)) != -1) {
switch (ch) {
case 'd':
lconf.debug = 1;
The person that wrote the code clearly intended -d to enable debugging. We
can discuss exactly what enabling debugging does, but I really don't think
there's any question as to whether or not -d should be considered debug
mode...
You know, usually it's enough to ping upstream. AFAIR there was
a similar problem in irqbalance, and they have added plain
'--foreground' for us.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Diego Elio Pettenò wrote: Conditionally patching openntpd in the ebuild if a system is using openrc is certainly the way to go. You mean unconditionally here, right? No. Because pid files should be there, full stop. With openrc sure but neither want nor need them with service supervision. You're certainly clever enough to see that pid files are a racy legacy kludge. It's fine to have them for backward compatibility with init systems that need them, but by now there are many different ways that we can avoid them - and that's a really good thing. I too believe that upstream would be happy to include a foreground mode without the debugging. //Peter
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Peter Stuge wrote: Diego Elio Pettenò wrote: Conditionally patching openntpd in the ebuild if a system is using openrc is certainly the way to go. You mean unconditionally here, right? No. Or maybe yes. :) The condition I refered to is that the system is using openrc. Sorry if my weak language skills caused confusion! //Peter
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 1:31 PM, Peter Stuge pe...@stuge.se wrote: Or maybe yes. :) The condition I refered to is that the system is using openrc. Sorry if my weak language skills caused confusion! What I mean is that it would be stupid to have USE=openrc to apply such a patch. Either the patch is done correctly (does not break the daemon), or is not. If the former is true, USE=openrc would be broken; if the latter is true, why not simply apply it to begin with? If you really don't want PID files (and it probably means you have never had to deal with medium-scale deployments, but never mind), you can make it so that `-p` is an optional parameter, and if not passed no pidfile is created. And voilà, you can make an unconditional patch and even send it upstream for other init systems that do rely on pidfiles that are not OpenRC. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 09:14:30AM +0100, Michał Górny wrote: You know, usually it's enough to ping upstream. AFAIR there was a similar problem in irqbalance, and they have added plain '--foreground' for us. I don't know there really is an upstream for portable openntpd right now, there's been forward development in the openbsd tree, but the last official release of the portable version was in 2006 8-/. Unless you consider debian upstream as far as their patches on top of vanilla portable. I'm not sure what all's changed in the openbsd version, but I guess no one's really cared enough to work on making it portable. The last status I see is from 2008: http://marc.info/?l=openbsd-miscm=122731899504602 where someone said it would be nontrivial. I think adding a pid option would be better than adding a foreground option, at least for openrc purposes; although a foreground option that wasn't debugging mode and still logged to syslog would be better than the current gentoo state.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 04:20:09PM +, Diego Elio Pettenò wrote: If you really don't want PID files (and it probably means you have never had to deal with medium-scale deployments, but never mind), you can make it so that `-p` is an optional parameter, and if not passed no pidfile is created. And voilà, you can make an unconditional patch If Christoph says he'd be willing to stop running in debug mode and go back to the original mechanism where openntpd runs normally as a daemon and logs to syslog, I'll put together a patch that adds a -p argument to optionally create a pid file after daemonizing... But I don't really want to spend the time though if there's not a reasonably firm agreement on it. My offer to debug boot delays in excess of 15 seconds upon supply of a reproducible configuration that causes them still stands too...
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Am Thu, 28 Nov 2013 08:55:56 -0700 schrieb Christoph Junghans ott...@gentoo.org: 2013/11/28 Rich Freeman ri...@gentoo.org: On Wed, Nov 27, 2013 at 10:56 PM, Paul B. Henson hen...@acm.org wrote: On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote: Paul B. Henson wrote: In openntpd ebuilds starting with version 20080406-r3, logging was changed from using the default standard syslog to running the daemon in debug mode, logging to stderr, and having start_stop_daemon background the process itself and redirect the output to a log file. I think this is broken. Yes, I think it is really f-ing broken too. Well, looks like it's just you and me in that camp :(, quite disappointing no other devs stepped up with an opinion on this. Guess I'll just fix this in my local overlay and the rest of the users can fend for themselves. Did anybody actually talk to the maintainer about this and ask why this was done? That would probably be a good first step if you want it to change. Having 47 devs agree with you doesn't really accomplish much if none of them care to maintain the package in question. Paul talked to me via the bug tracker, bug 491134, and due to discussion we had there openntpd-20080406-r5 features a use flag to bring back syslog support (for details see the bug). This allows to run openntpd with two different ways of logging, via syslog (like Paul wants) and with a separate log file to avoid boot delays (like djc wants). We could easily make syslog logging the default, like polynomial-c suggested in another thread, but syslog is enabled in most profiles by default anyway. Also, you can always publish your overlay. :) Rich I think I messed something up here. Yesterday I tried to reply on the latest mail being in this discussion thread but added Christoph's email address with a typo so the reply was not sent at all. I then only sent the reply to him and not to the list. So for completeness, here's my reply from yesterday: [Begin of quote] CCing ottxor (he's our openntpd maintainer) so he won't miss further discussion about this. Actually I partially do agree with the complaints that appeared in this thread. If logging once was done via syslog this should not be changed. So rather than making this available via USE flag being disabled by default I'd rather prefer to have the USE flag being enabled by default. I do not agree with Paul's suggestion to remove the -d option from the init script again. Unfortunately openntpd does not create a PIDfile once it gets started. This would not be a problem if openrc would not require a PIDfile to _reliably_ determine if the daemon is still running or not. So I think ottxor did the only right thing here. On the other hand since the daemon's init script starts the daemon with -d I see occasional ntpd crashes on one of my systems. I'm still investigating this and right now won't blame anyone. Fixes for the boot delays have already been mentioned (don't use ntpd's -s option) and other problems I cannot really see. [End of quote] I think there's some confusion on what the -d option actually does, so let me cite the relevant parts from man 8 ntpd: ntpd uses the adjtime(2) system call to correct the local system time without causing time jumps. Adjustments larger than 128ms are logged using syslog(3) with LOG_INFO priority. The threshold value is chosen to avoid having local clock drift thrash the log files. Should ntpd be started with the -d option, all calls to adjtime(2) will be logged. [snip] -d Do not daemonize. If this option is specified, ntpd will run in the foreground and log to stderr. [snip] -v This option allows ntpd to send DEBUG priority messages to syslog. Now let's discuss if this can be considered as debug mode or not. @Christoph: Sorry I messed up your nickname so badly :-/ -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Fri, Nov 29, 2013 at 09:49:03AM +0100, Lars Wendler wrote:
I think there's some confusion on what the -d option actually does, so
let me cite the relevant parts from man 8 ntpd:
[...]
Now let's discuss if this can be considered as debug mode or not.
Let me cite the relevant code ;) :
ntpd.c:
while ((ch = getopt(argc, argv, df:nsSv)) != -1) {
switch (ch) {
case 'd':
lconf.debug = 1;
The person that wrote the code clearly intended -d to enable debugging. We
can discuss exactly what enabling debugging does, but I really don't think
there's any question as to whether or not -d should be considered debug
mode...
If logging once was done via syslog this should not be changed.
So rather than making this available via USE flag being disabled
by default I'd rather prefer to have the USE flag being enabled by
default.
Also, running in debug mode precludes logging to syslog, as in debug mode
it just spews to stderr. Cause, well, it's for debugging, not routine
operation.
If openrc has issues managing services that don't drop pid files, maybe
that should be looked into, or maybe openntpd could be patched to drop
a pid file. But running in debug mode to prevent daemonizing, and then
manually backgrounding it, is simply kludgy and distasteful :(...
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Paul B. Henson wrote: If openrc has issues managing services that don't drop pid files, maybe that should be looked into, or maybe openntpd could be patched to drop a pid file. Conditionally patching openntpd in the ebuild if a system is using openrc is certainly the way to go. But running in debug mode to prevent daemonizing, and then manually backgrounding it, is simply kludgy and distasteful :(... Yes! //Peter
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Sat, Nov 30, 2013 at 1:55 AM, Peter Stuge pe...@stuge.se wrote: Conditionally patching openntpd in the ebuild if a system is using openrc is certainly the way to go. You mean unconditionally here, right? Because pid files should be there, full stop. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Wed, Nov 27, 2013 at 10:56 PM, Paul B. Henson hen...@acm.org wrote: On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote: Paul B. Henson wrote: In openntpd ebuilds starting with version 20080406-r3, logging was changed from using the default standard syslog to running the daemon in debug mode, logging to stderr, and having start_stop_daemon background the process itself and redirect the output to a log file. I think this is broken. Yes, I think it is really f-ing broken too. Well, looks like it's just you and me in that camp :(, quite disappointing no other devs stepped up with an opinion on this. Guess I'll just fix this in my local overlay and the rest of the users can fend for themselves. Did anybody actually talk to the maintainer about this and ask why this was done? That would probably be a good first step if you want it to change. Having 47 devs agree with you doesn't really accomplish much if none of them care to maintain the package in question. Also, you can always publish your overlay. :) Rich
Re: [gentoo-dev] logging in openntpd 20080406-r3+
2013/11/28 Rich Freeman ri...@gentoo.org: On Wed, Nov 27, 2013 at 10:56 PM, Paul B. Henson hen...@acm.org wrote: On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote: Paul B. Henson wrote: In openntpd ebuilds starting with version 20080406-r3, logging was changed from using the default standard syslog to running the daemon in debug mode, logging to stderr, and having start_stop_daemon background the process itself and redirect the output to a log file. I think this is broken. Yes, I think it is really f-ing broken too. Well, looks like it's just you and me in that camp :(, quite disappointing no other devs stepped up with an opinion on this. Guess I'll just fix this in my local overlay and the rest of the users can fend for themselves. Did anybody actually talk to the maintainer about this and ask why this was done? That would probably be a good first step if you want it to change. Having 47 devs agree with you doesn't really accomplish much if none of them care to maintain the package in question. Paul talked to me via the bug tracker, bug 491134, and due to discussion we had there openntpd-20080406-r5 features a use flag to bring back syslog support (for details see the bug). This allows to run openntpd with two different ways of logging, via syslog (like Paul wants) and with a separate log file to avoid boot delays (like djc wants). We could easily make syslog logging the default, like polynomial-c suggested in another thread, but syslog is enabled in most profiles by default anyway. Also, you can always publish your overlay. :) Rich -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Thu, Nov 28, 2013 at 08:55:56AM -0700, Christoph Junghans wrote: run openntpd with two different ways of logging, via syslog (like Paul wants) and with a separate log file to avoid boot delays (like djc wants). We could easily make syslog logging the default, like My point is that running in debug mode to avoid boot delays is broken. As I've explained, the delays come about because the user explicitly requested that openntpd set the time at start up. Don't use the -s option, no boot delay. The option to run in debug mode with a hardcoded log file just shouldn't exist at all. It actually breaks the -s option, as openntpd is backgrounded before it can set the time, and other processes potentially start without a valid time. From my testing, the boot delay is capped at 15 seconds anyway. If people are experiencing longer delays, the solution is to track down the bug that's causing the delay to exceed the 15 second timeout, not to kludge around it. If someone can provide a configuration that reliably reproduces a delay longer than 15 seconds, I've offered to look into it.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Thu, Nov 28, 2013 at 06:48:30AM -0500, Rich Freeman wrote: Having 47 devs agree with you doesn't really accomplish much if none of them care to maintain the package in question. Well, I would kinda hope that if 47 devs told 1 dev they were making a poor design decision, that 1 dev would reconsider their position... So, do you have any opinion on running a daemon in the foreground in debug mode with stderr hardcoded to a specific file then backgrounding it at the service start level to work around a delay issue caused by the user explicitly requesting that the daemon perform an operation prior to backgrounding itself?
Re: [gentoo-dev] logging in openntpd 20080406-r3+
If you pip stdout/stderr to a file, how does that interact with log rotation? -A -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Fri, Nov 22, 2013 at 09:36:38PM +0100, Peter Stuge wrote: Paul B. Henson wrote: In openntpd ebuilds starting with version 20080406-r3, logging was changed from using the default standard syslog to running the daemon in debug mode, logging to stderr, and having start_stop_daemon background the process itself and redirect the output to a log file. I think this is broken. Yes, I think it is really f-ing broken too. Well, looks like it's just you and me in that camp :(, quite disappointing no other devs stepped up with an opinion on this. Guess I'll just fix this in my local overlay and the rest of the users can fend for themselves.
[gentoo-dev] logging in openntpd 20080406-r3+
In openntpd ebuilds starting with version 20080406-r3, logging was changed from using the default standard syslog to running the daemon in debug mode, logging to stderr, and having start_stop_daemon background the process itself and redirect the output to a log file. I think this is broken. First of all, this change was made due to complaints about boot delays. A delay at boot *only* occurs if you have added the -s option to set the time immediately at start up. If and only if the -s option is used, openntpd will delay up to 15 seconds trying to reach a time server in order to initially set the time before daemonizing into the background. If the -s option is not used, openntpd will immediately daemonize with no delay. Note that the -s option is *not* the default when the ebuild is installed. If you explicitly add the -s option, you are requesting that the time be set at start up before any other processes are started. It's kind of stupid for somebody to request that ntpd set the time and then complain that there is a delay while it's trying to do so. If somebody does not want a boot delay, the answer is to tell them to remove the -s option, not to Rube Goldberg the startup script and logging. Second, this change actually *breaks* functionality for people who *do* want the time set at start up before other processes are run. With the original behavior, ntpd would set the time before the startup script would return, and any process starting afterwards would be assured of the correct time (unless there was a network failure or ntp outage). With this implementation, ntpd is forked off into the background and the next startup script immediately run, potentially before ntpd has had a chance to actually set the time. Third, -d is debugging mode, not let's just not background and log to stderr mode. At the very least, -d results in a ton of additional log output that would not normally be generated. Without auditing the code, I don't know what other changes to the normal behavior it might result in, but in general, running a production service in debug mode is not typically a good idea. I opened a bug about these issues (491134), and the latest version does add a new syslog use flag allowing you to use the standard logging rather than running in debug mode (although the implementation is a bit fragile, a hardcoded sed in the ebuild that deletes specific lines from the init script after it is copied in). This version does still unconditionally copy in a logrotate config file that could potentially conflict with somebody's existing configuration. I was unable to come to an agreement with the current maintainer of the ebuild on this design, and would like some general feedback from the larger community of developers on this topic. Thanks much.
Re: [gentoo-dev] logging in openntpd 20080406-r3+
On Fri, Nov 22, 2013 at 9:15 PM, Paul B. Henson hen...@acm.org wrote: I was unable to come to an agreement with the current maintainer of the ebuild on this design, and would like some general feedback from the larger community of developers on this topic. Thank you for your explanation of the issues here, I found it quite interesting. I think I was the original user who complained about the boot delays. I was surprised a few times by openntpd behavior. - Without -s, it can take a *very* long time to get close to an acceptable time error, whereas my initial expectation was that starting my ntpd should fix the time error fairly quickly. But for me this, this is partly about starting ntpd while the machine is online, not just at boot. - Second, with -s, the boot delays can be quite long. I'm pretty sure I've seen delays that are quite a bit longer than 15s, probably in the case where there's no network or maybe where DNS doesn't resolve well; in any case, when you're trying to debug issues in a data center environment, waiting for a bunch of machines to come up is not much fun. (Or when you've had a machine go down and you're waiting to see if it comes up again.) Now, for my use case, it is not all that important that the time error is minimized before resuming the boot process, but I really wanted to minimize boot delays. Also, I'm really not sure how the change to logging to stderr/file and running in debug mode helps with the boot delays. Cheers, Dirkjan
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Paul B. Henson wrote: In openntpd ebuilds starting with version 20080406-r3, logging was changed from using the default standard syslog to running the daemon in debug mode, logging to stderr, and having start_stop_daemon background the process itself and redirect the output to a log file. I think this is broken. Yes, I think it is really f-ing broken too. //Peter
Re: [gentoo-dev] logging in openntpd 20080406-r3+
Dirkjan Ochtman wrote: for my use case, it is not all that important that the time error is minimized before resuming the boot process, but I really wanted to minimize boot delays. Most servers really do need accurate time. But your servers, your call. NTP always takes a long time to adjust your time, it's not a good idea to go breaking OpenNTPD for every single Gentoo user just because you don't care about time on your machines. :( //Peter
RE: [gentoo-dev] logging in openntpd 20080406-r3+
From: Dirkjan Ochtman [mailto:d...@gentoo.org]
Sent: Friday, November 22, 2013 12:30 PM
- Without -s, it can take a *very* long time to get close to an
acceptable time error, whereas my initial expectation was that
starting my ntpd should fix the time error fairly quickly. But for
me this, this is partly about starting ntpd while the machine is
online, not just at boot.
In general, ntpd tries not to violate the presumption that time is
monotonically increasing. Rather, it adjusts the clock rate such that your
system time approaches real time; if your current time is too far behind, the
clock runs faster, and each second takes less than a second, if your time is
too far ahead, each second takes more than a second. However, if your time is
very far off, that will take a considerable amount of time (heh heh) to
synchronize. The -s option makes makes ntpd simply set the time to exactly
whatever the current time is, regardless of what the system clock happens to
say. This could be a huge jump, possibly into the past from the perspective
of the system. Generally, this is only done at boot, typically before other
processes are started that might need the correct time. Depending on what
services your system is running, something might be quite unhappy if suddenly
it is eight minutes earlier than it appeared to be when the process started.
- Second, with -s, the boot delays can be quite long. I'm pretty sure
I've seen delays that are quite a bit longer than 15s, probably in the
case where there's no network or maybe where DNS doesn't resolve well;
I've tested a variety of scenarios, from the network interface being
down/unplugged, providing invalid NTP servers, etc., and I haven't seen a delay
longer than 15 seconds. If you look at the source code in ntpd.c:
while ((ch = getopt(argc, argv, df:nsSv)) != -1) {
[...]
case 's':
lconf.settime = 1;
If you supply the -s option lconf.settime is set, and:
if (!lconf.settime) {
log_init(lconf.debug);
if (!lconf.debug)
if (daemon(1, 0))
fatal(daemon);
} else
timeout = SETTIME_TIMEOUT * 1000;
rather than immediately daemonizing, it sets a 15 second timeout
(SETTIME_TIMEOUT is defined to 15 in ntpd.h).
It then enters the main loop, where if a response is not received within 15
seconds:
if ((nfds = poll(pfd, 1, timeout)) == -1)
if (nfds == 0 lconf.settime) {
lconf.settime = 0;
timeout = INFTIM;
log_init(lconf.debug);
log_debug(no reply received in time, skipping initial
time setting);
if (!lconf.debug)
if (daemon(1, 0))
fatal(daemon);
}
It backgrounds anyway and aborts the initial time set. I'm not saying there
isn't some bug or scenario which would result in a longer delay, but if so,
that is a bug in ntpd, not an issue to be worked around in the startup script.
in any case, when you're trying to debug issues in a data center
environment, waiting for a bunch of machines to come up is not much
fun. (Or when you've had a machine go down and you're waiting to see
if it comes up again.)
In my data center, NTP is considered a critical service and provisioned with
fault tolerance. If a box trying to boot cannot reach an NTP server, that is as
much of a problem as whatever is wrong with the box booting. I don't believe
I've ever seen a boot delay caused by NTP on any of our production systems
ever. If you can provide a reproducible failure mode where ntpd takes longer
than 15 seconds to start I'd be willing to take a look and see what's going on.
Ideally though, this should be reproducible on a system already running, not
something only happening during boot, as it would be more difficult to debug
the process at that state.
Now, for my use case, it is not all that important that the time error
is minimized before resuming the boot process, but I really wanted to
minimize boot delays.
Then I advise you not to use the -s option, in which case there will never be a
delay, no matter what.
Also, I'm really not sure how the change to logging to stderr/file and
running in debug mode helps with the boot delays.
Basically, the new startup script does something like:
/usr/sbin/ntpd -d [-s] 2/var/log/ntpd.log
The process is immediately put into the background and the startup sequence
continues. This eliminates the boot delay, but at the cost of not actually
setting the time before other processes are started (if the -s option is
provided), using really kludgy logging, and always running the process in debug
mode.
Personally, I think it should all be put back to the way it was to begin with,
