Your message dated Thu, 11 Apr 2024 14:25:54 +0200
with message-id <[email protected]>
and subject line Re: Bug#1068796: Acknowledgement (ntpsec-netpdate: starts ntpd
if installed, leading to delayed boot)
has caused the Debian Bug report #1068796,
regarding ntpsec-netpdate: starts ntpd if installed, leading to delayed boot
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1068796: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068796
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: ntpsec-netpdate
Version: 1.2.3+dfsg1-1
Severity: normal
Dear Maintainer,
I observed a 3 minute timeout on boot during "Starting NTP server: ntpd"
This can easily be reproduced on a running system by calling
"invoke-rc.d ntpsec start" again.
On sysvinit systems ifupdown usually runs before the ntpsec daemon gets
started (since ntpsec depends on $network). If it brings up a static
interface, the hook script /etc/network/if-up.d/ntpsec-ntpdate will run
ntpdate and then start the ntpsec deamon regardless whether it was
running or not. Later in the init process, the ntpsec init script is run
again with start. This causes the flock call to wait for 3 minutes,
since the lock is already taken by the demon started from
ntpsec-ntpdate.
Is the flock call in /etc/init.d/ntpsec really needed since
start-stop-daemon already guards the daemon with a pidfile? If it is, 3
minutes seem a long timeout especially during bootup, and when it fails
its return code is ignored and start-stop-daemon is called anyways.
My suggestion would be to remove the flock call in /etc/init.d/ntpsec
and only use start-stop-daemon to guard against multiple starts. Other
options would be:
- in /etc/network/if-up.d/ntpsec-ntpdate test if ntpsec already was
running and only start it again in that case.
- rework /etc/init.d/ntpsec to actually fail in case the lock could not
be acquired, and reduce the timeout to a few seconds, or run the part
of that script in a background shell.
I am not sure about the appropriate serverity, but adding a 3 minute
delay to the boot process (on sysvinit systems with static network
interfaces) feels like a broken boot.
Thanks,
Ingo
-- System Information:
Distributor ID: Devuan
Description: Devuan GNU/Linux 6 (excalibur/ceres)
Release: 6
Codename: excalibur ceres
Architecture: x86_64
Kernel: Linux 6.9.0-rc3-spatz20240410 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
--- End Message ---
--- Begin Message ---
closing this bug with wrong package name, i have refiled it to the
correct package
Ingo
--
const_cast<long double>(Λ)
--- End Message ---
