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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org