On 2/9/22, Greg Wooledge <g...@wooledge.org> wrote: > On Wed, Feb 09, 2022 at 05:44:25PM +0300, Reco wrote: >> Hi. >> >> On Wed, Feb 09, 2022 at 09:05:51AM -0500, Lee wrote: >> > On 2/8/22, Greg Wooledge <g...@wooledge.org> wrote: >> > > On Tue, Feb 08, 2022 at 02:43:02PM -0500, Lee wrote: >> > >> How to tell systemd to leave the ntpd config alone? >> > > >> > > What makes you think the two are connected in any way? >> > >> > $ grep "Network Time Service" syslog >> > Feb 6 12:06:48 spot systemd[1]: Stopping Network Time Service... >> > Feb 6 12:06:48 spot systemd[1]: Stopped Network Time Service. >> > Feb 6 12:06:48 spot systemd[1]: Starting Network Time Service... >> > Feb 6 12:06:48 spot systemd[1]: Started Network Time Service. >> > Feb 6 12:09:25 spot systemd[1]: Stopping Network Time Service... >> > Feb 6 12:09:25 spot systemd[1]: Stopped Network Time Service. >> > Feb 6 12:09:25 spot systemd[1]: Starting Network Time Service... >> > Feb 6 12:09:25 spot systemd[1]: Started Network Time Service. >> > Feb 6 12:22:53 spot systemd[1]: Stopping Network Time Service... >> > Feb 6 12:22:53 spot systemd[1]: Stopped Network Time Service. >> > Feb 6 12:22:53 spot systemd[1]: Starting Network Time Service... >> > Feb 6 12:22:53 spot systemd[1]: Started Network Time Service. >> > ... etc >> > >> > every time I connect or disconnect from a wifi network. >> >> Or it could mean that dhclient hook merely asks systemd to restart ntpd >> service. See /etc/dhcp/dhclient-exit-hooks.d/ntp. > > What a disaster. The number of moving parts here is just staggering. > > OK, now we know that the real culprit is in fact Debian's concept of > how a DHCP client should behave. Let's try to track down all of the > pieces and figure out what the *best* answers are. > > The first piece, we now know, is the /etc/dhcp/dhclient-exit-hooks.d/ntp > script. We can see that this creates a temporary file, writes a new NTP > configuration into it, moves it to /run/ntp.conf.dhcp and then asks the > system to restart ntpd. > > The second piece is the /etc/init.d/ntp script (SURPRISE! sysv-rc still > lives!). Here we see this bit of conspiracy: > > if [ -e /run/ntp.conf.dhcp ]; then > NTPD_OPTS="$NTPD_OPTS -c /run/ntp.conf.dhcp" > fi > > If /run/ntp.conf.dhcp exists, then it's used preferentially over the > system's *real* ntp.conf file. So, the DHCP hook generates this fake > config file, and then the sysv-rc script sees it and decides to use it. > > AND SOMEONE THOUGHT THIS KLUDGE WAS A GOOD IDEA!!
exactly :( Any idea what the chances are of getting an enhancement request for the dhcp client to add an ignore option; that says not use the option given by the dhcp server? > So, this gives us at least two points of attack. You could edit the DHCP > hook script, and stop it from creating the fake config file. Or, you > could edit the sysv-rc script and stop it from *respecting* the fake > config file. > > The question, I suppose, is which one of these is less likely to be > overwritten if the ntp package is updated. But they are both listed in > /var/lib/dpkg/info/ntp.conffiles so they should both survive a package > update. (You'll be asked whether to keep the existing file, etc.) *sigh* naturally I picked the "move it somewhere else" option that won't prevent an upgrade from re-creating the file. Thanks Lee