[ntp:questions] Handle ntp conf modification when ntp is already running

Jochen Bern Jochen.Bern at LINworks.de
Thu Apr 10 20:17:11 UTC 2014


On 10.04.2014 14:00, questions-request at lists.ntp.org digested:
> From: Terje Mathisen <terje.mathisen at tmsw.no>
> 
> Rob wrote:
>> > OF COURSE ntpd should simply listen for SIGHUP and when it is received
>> > re-read the config file.  Like almost all Unix daemons do.
> 
> Here's the crux of the matter:
> ntpd is _not_ a "Unix daemon", or at least not just that: The same code 
> runs on many different operating systems, some of which don't implement 
> SIGHUP at all, or at least not in a compatible manner.

Now this sounds dangerously close to "ntpd cannot possibly use a config
file, because it is supposed to be running on various OSes with
incompatible character and end-of-line encodings" ...

> From: Harlan Stenn <stenn at ntp.org>
> 
> Amongst the many reasons why we did not let SIGHUP restart the daemon
> was that back in the old days we used modem drivers a lot more often.
> The HUP signal was generic - it was not really associated with any
> specific device.

I wouldn't be surprised if spurious SIGHUPs were still occuring (and
possibly reaching unrelated daemon processes) today - just think of how
many DSL routers happen to have a unixoid OS and are actually running a
pppd (whose manpage mentions HUPs a lot). Point is, for daemons *other*
than ntpd, "rereading the config" that nobody did edit will likely have
no noticeable effect at all. For ntpd, with the round robin DNS pools
yielding different servers every time you resolve, and possibly losing
status even for those servers that did *not* change ... things might
look different.

Then again, it's not like there are no established unixoid methods
*other* than HUP - from USR1 (no example whose name I'd remember off the
top of my head) to polling the config file's stat() periodically (a la
/etc/crontab) to a simple CLI via local special files (a la Nagios
command pipe, or even "echo 1 > /proc/sys/foo/bar") to opaque IPC hidden
behind a dedicated util's command line options (a la apachectl, or
fetchmail --quit). At the end of the day, lots of people - and the most
important clustering solutions - won't care to look past the OS'
meta-command, be it "service mumblefoo reload" or "svcadm restart
mumblefoo", as long as that *works*. :-}

Regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel


More information about the questions mailing list