Re: systemd/dhcp v. ntpd
On 2/9/22, Greg Wooledge <greg@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 <greg@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 to: