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

Reply via email to