[opensuse-factory] [Tumbleweed] ntpd cannot be stopped cleanly
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Achim Gratz -
Andrei Borzenkov -
Christian Boltz