[Tumbleweed] ntpd cannot be stopped cleanly

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Tumbleweed] ntpd cannot be stopped cleanly

Achim Gratz

Somewhere between the holidays and the beginning of the new year I
noticed that stopping the NTP server daemon via systemctl takes roughly
a minute to complete.  I've noticed this because it also stops the
powerdown process.  The ntpd itself is terminated quickly, so things
must be hitting some timeout elsewhere.  This might be the same issue as
mentioned in bug#1057637, but it seems that no action has been taken
yet.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Tumbleweed] ntpd cannot be stopped cleanly

Andrei Borzenkov
14.01.2018 15:45, Achim Gratz пишет:
>
> Somewhere between the holidays and the beginning of the new year I
> noticed that stopping the NTP server daemon via systemctl takes roughly
> a minute to complete.  I've noticed this because it also stops the
> powerdown process.  The ntpd itself is terminated quickly, so things
> must be hitting some timeout elsewhere.

How do you know this?

>  This might be the same issue as
> mentioned in bug#1057637, but it seems that no action has been taken
> yet.
>

Well, I cannot reproduce it on up to date TW (just dup'ed) so there must
be some configuration difference. In the above bug ntpd apparently is
not terminated by SIGTERM or systemd does not notice it. You say ntpd is
terminated - do you have any logs?
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Tumbleweed] ntpd cannot be stopped cleanly

Achim Gratz
Andrei Borzenkov writes:
>> Somewhere between the holidays and the beginning of the new year I
>> noticed that stopping the NTP server daemon via systemctl takes roughly
>> a minute to complete.  I've noticed this because it also stops the
>> powerdown process.  The ntpd itself is terminated quickly, so things
>> must be hitting some timeout elsewhere.
>
> How do you know this?

Monitoring with ntpq stops and the process list doesn't show it either.

>>  This might be the same issue as
>> mentioned in bug#1057637, but it seems that no action has been taken
>> yet.
>>
>
> Well, I cannot reproduce it on up to date TW (just dup'ed) so there must
> be some configuration difference. In the above bug ntpd apparently is
> not terminated by SIGTERM or systemd does not notice it. You say ntpd is
> terminated - do you have any logs?

There is _nothing_ in the logs for the entire minute systemd thinks it's
stopping it (this is from a restart today):

Jan 14 13:19:24 Gertrud systemd[1]: Stopping NTP Server Daemon...
Jan 14 13:20:19 Gertrud systemd[1]: Stopped NTP Server Daemon.
Jan 14 13:20:19 Gertrud systemd[1]: Starting NTP Server Daemon...

Here's the same timeframe in /var/log/ntp:

14 Jan 13:19:24 ntpd[1867]: ntpd exiting on signal 15 (Terminated)
14 Jan 13:19:24 ntpd[1867]: 127.127.20.0 local addr 127.0.0.1 -> <null>
14 Jan 13:19:25 ntpd[1867]: 192.168.168.1 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 192.168.178.20 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 192.168.178.29 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 192.168.178.32 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 192.53.103.108 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 192.53.103.104 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 192.168.178.1 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 192.53.103.103 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 194.25.134.196 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 85.214.194.162 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 78.46.204.247 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 188.68.36.203 local addr 192.168.178.24 -> <null>
14 Jan 13:19:25 ntpd[1867]: 178.238.237.15 local addr 192.168.178.24 -> <null>
14 Jan 13:20:19 ntp_intres[1885]: blocking_getaddrinfo can not queue response

BTW, the apparmor profile for ntpd is missing a permisssion for
/var/log/ntpstats/clockstats* which is needed when there is a refclock
configured and the statistics turned on.  Fixing that… and it seems that
the restart now happens as it should:

Jan 14 17:10:17 Gertrud systemd[1]: Stopping NTP Server Daemon...
Jan 14 17:10:17 Gertrud systemd[1]: Stopped NTP Server Daemon.
Jan 14 17:10:17 Gertrud systemd[1]: Starting NTP Server Daemon...

I'll keep an eye on it, but it would seem that at least in my case it
was apparmor that produced the delay.  Now, why is apparmor configured
so that it doesn't log this anywhere (/var/log/apparmor is empty)?


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Tumbleweed] ntpd cannot be stopped cleanly

Christian Boltz-5
Hello,

Am Sonntag, 14. Januar 2018, 17:14:23 CET schrieb Achim Gratz:

> BTW, the apparmor profile for ntpd is missing a permisssion for
> /var/log/ntpstats/clockstats* which is needed when there is a refclock
> configured and the statistics turned on.  Fixing that… and it seems
> that the restart now happens as it should:

I never had issues with those clockstat files.

Is /var/log/ntpstats/clockstats* the default path for them, or at least
a commonly used path? If yes, tell me which rules you had to add.
It should be possible to add them to the official profile ;-)

> I'll keep an eye on it, but it would seem that at least in my case it
> was apparmor that produced the delay.  Now, why is apparmor configured
> so that it doesn't log this anywhere (/var/log/apparmor is empty)?

AppArmor profile violations are logged to
- /var/log/audit/audit.log if you have auditd running (recommended)
- dmesg
- /var/log/messages or journal, whatever you use

/var/log/apparmor/ is only used if you run the aa-* tools in debug mode.


Regards,

Christian Boltz
--
Ein Experte ist ein Mensch, den man in letzter Minute hinzuzieht,
um einen Mitschuldigen zu haben.



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Tumbleweed] ntpd cannot be stopped cleanly

Achim Gratz
Christian Boltz writes:
> AppArmor profile violations are logged to
> - /var/log/audit/audit.log if you have auditd running (recommended)

Yes, it was in there.

> - dmesg

No.

> - /var/log/messages or journal, whatever you use

No again.

The ntp.log file had complaints by ntpd about it not having permission
to create the file, but not why.  I had been bitten by apparmor before
so I went looking directly and there it was.  :-)

> I never had issues with those clockstat files.

Well, you have to have a refclock / stratum-0 and you need to enable
logging for it.

> Is /var/log/ntpstats/clockstats* the default path for them, or at least
> a commonly used path? If yes, tell me which rules you had to add.
> It should be possible to add them to the official profile ;-)

Thanks.  I've opened bug#1076247 so you can track things.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]