Discussion:
Bug#849401: restart silently fails
(too old to reply)
Daniel Pocock
2016-12-26 17:20:02 UTC
Permalink
Raw Message
Package: apcupsd
Version: 3.14.12-1.1
Severity: serious


apcupsd is correctly configured and running on my machine.

I decided to restart it by typing:

$ sudo systemctl restart apcupsd


and the command didn't report any errors.

Looking at the output of the 'ps' command, I couldn't find apcupsd running.

I grepped /var/log/daemon.log and found the message


apcupsd[10324]: A copy of the daemon is still running. If you just
stopped it,
apcupsd[10324]: please wait about 5 seconds for it to shut down.


Maybe the "stop" action should wait for it to really stop? Not
stopping/restart correctly could impact upgrades, so I've marked the bug
serious.

Regards,

Daniel
Francesco Poli
2017-01-03 21:40:02 UTC
Permalink
Raw Message
On Mon, 26 Dec 2016 18:15:20 +0100 Daniel Pocock wrote:

[...]
Post by Daniel Pocock
apcupsd[10324]: A copy of the daemon is still running. If you just
stopped it,
apcupsd[10324]: please wait about 5 seconds for it to shut down.
Maybe the "stop" action should wait for it to really stop? Not
stopping/restart correctly could impact upgrades, so I've marked the bug
serious.
[...]

Hello apcupsd maintainer(s),
this package is scheduled for auto-removal from testing on
January, the 24th, as stated on its tracker page [1].

[1] https://tracker.debian.org/pkg/apcupsd

Please fix this RC bug soon!

If apcupsd is auto-removed from testing, it won't have a chance to
re-enter stretch, due to the soft freeze (which will begin shortly: on
January, the 5th) [2].

[2] https://lists.debian.org/debian-devel-announce/2016/12/msg00000.html

Thanks for your time.
Bye!


P.S.: I am Cc-ing the bug submitter and the author of the last NMUs.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Daniel Pocock
2017-01-06 10:10:01 UTC
Permalink
Raw Message
Post by Francesco Poli
[...]
Post by Daniel Pocock
apcupsd[10324]: A copy of the daemon is still running. If you
just stopped it, apcupsd[10324]: please wait about 5 seconds
for it to shut down.
Maybe the "stop" action should wait for it to really stop?
Not stopping/restart correctly could impact upgrades, so I've
marked the bug serious.
[...]
Post by Francesco Poli
Please fix this RC bug soon!
Hello again, I performed some tests, but I failed to reproduce this
bug.
Is anyone able to reproduce the issue on current Debian testing?
How long does it take for your apcupsd daemon to shutdown?

My UPS uses SNMP signalling, I wonder if that makes the daemon shut
down more slowly.
# service apcupsd restart # service apcupsd status ●
apcupsd.service - LSB: Starts apcupsd daemon Loaded: loaded
man:systemd-sysv-generator(8) Process: 24604
ExecStop=/etc/init.d/apcupsd stop (code=exited, status=0/SUCCES
Process: 24610 ExecStart=/etc/init.d/apcupsd start (code=exited,
/system.slice/apcupsd.service └─24620 /sbin/apcupsd
Jan 05 09:06:28 $HOSTNAME systemd[1]: Starting LSB: Starts apcupsd
daemon... Jan 05 09:06:28 $HOSTNAME apcupsd[24610]: Starting UPS
Started LSB: Starts apcupsd daemon. Jan 05 09:06:28 $HOSTNAME
apcupsd[24620]: apcupsd 3.14.14 (31 May 2016) debian star Jan 05
09:06:28 $HOSTNAME apcupsd[24620]: NIS server startup succeeded
# systemctl restart apcupsd # systemctl status apcupsd ●
apcupsd.service - LSB: Starts apcupsd daemon Loaded: loaded
man:systemd-sysv-generator(8) Process: 25726
ExecStop=/etc/init.d/apcupsd stop (code=exited, status=0/SUCCES
Process: 25733 ExecStart=/etc/init.d/apcupsd start (code=exited,
/system.slice/apcupsd.service └─25740 /sbin/apcupsd
Jan 05 09:50:12 $HOSTNAME systemd[1]: Starting LSB: Starts apcupsd
daemon... Jan 05 09:50:12 $HOSTNAME apcupsd[25733]: Starting UPS
Started LSB: Starts apcupsd daemon. Jan 05 09:50:12 $HOSTNAME
apcupsd[25740]: apcupsd 3.14.14 (31 May 2016) debian star Jan 05
09:50:12 $HOSTNAME apcupsd[25740]: NIS server startup succeeded
Francesco Poli
2017-01-10 22:50:01 UTC
Permalink
Raw Message
[...]
Post by Daniel Pocock
My UPS uses SNMP signalling, I wonder if that makes the daemon shut
down more slowly.
Maybe...
Have you determine how long should the restart action wait between the
stop and the start action?

The command

# systemctl stop apcupsd ; systemctl start apcupsd

should reproduce the misbehavior in your case. Can you confirm?

Does

# systemctl stop apcupsd ; sleep 1 ; sleep 1 ; systemctl start apcupsd

suffice to avoid experiencing the misbehavior?

Or maybe

# systemctl stop apcupsd ; sleep 2 ; sleep 2 ; systemctl start apcupsd

?

Or perhaps

# systemctl stop apcupsd ; sleep 3; sleep 3 ; systemctl start apcupsd

?

Could you please perform some tests?
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Francesco Poli
2017-01-12 23:20:01 UTC
Permalink
Raw Message
[...]
the apcupsd.service file seems to lack any check for the
ISCONFIGURED variable in /etc/default/apcupsd (unlike apcupsd.init,
which aborts whenever that variable is not set to "yes").
Is this intentional?
I think that the check should be implemented somehow...
It's intentional for the test packages. I did not want to spend time
on implementing that if the proposed change doesn't work in the
first place.
Sounds reasonable...
Suggestions on the actual implementation also welcome ;-)
I am no systemd expert, but, after reading a bit of the
systemd.service(5) man page, I would think about adding another
ExecStartPre= (before the already existing one) and using it to run a
script that fails in case ISCONFIGURED is not "yes"...

But of course, I am not sure that making the "service apcupsd restart"
command fail during the configuration of a newly installed apcupsd
package is a good idea...

Oh well, I need advice from people more knowledgeable than me!
(TBH, if I did this package anew today, I'd probably just install
with the service disabled/masked and not do the ISCONFIGURED dance,
but it's not a new package and it's not my package...)
I can understand your point of view...


I hope a NMU can be done soon (provided that Daniel's feedback is
positive) to fix this RC bug.
Thanks a lot for your time and dedication!

Bye.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Francesco Poli
2017-01-13 18:50:02 UTC
Permalink
Raw Message
Post by Francesco Poli
Suggestions on the actual implementation also welcome ;-)
I am no systemd expert, but, after reading a bit of the
systemd.service(5) man page, I would think about adding another
ExecStartPre= (before the already existing one) and using it to run a
script that fails in case ISCONFIGURED is not "yes"...
But of course, I am not sure that making the "service apcupsd restart"
command fail during the configuration of a newly installed apcupsd
package is a good idea...
Exactly.
I think this is basically the "between a rock and a hard place"
situation.
Do it right for new installs and break upgrades or do it right for
upgrades and new installs get the silly treatment.
Mmmmh, that's unfortunate.

In the meanwhile, I performed a super-quick test for your proposed NMU:
it seems to work, although I have to admit I hadn't had the time to
test everything... :-(

Obviously, the important feedback is Daniel's one: Daniel, please test
thoroughly and let us know.
Thanks for your time!
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Daniel Pocock
2017-01-15 17:20:01 UTC
Permalink
Raw Message
[...]
https://people.debian.org/~zeha/apcupsd/
Please report back if those work for you and if the restart
issue is fixed. Note that successful testing also needs to
include a powerfail test really.
systemctl start apcupsd && while ps -C apcupsd ; do systemctl
stop apcupsd ; sleep 0 ; systemctl start apcupsd ; ps -C apcupsd
|| echo FAILED ; done
For about 3 minutes, it appears to restart correctly every time.
I haven't done a full powerfail test so far.
Hello Daniel, thanks for your feedback.
I hope that Christian may soon finalize the NMU in order to have
this bug fixed once and for all.
Christian, have you decided which strategy should be adopted for
the ISCONFIGURED handling?
One other aspect of this issue remains: if apcupsd doesn't start for
any reason (whether it is because of a rapid restart or some other
fault), we need to verify that the init script or systemd realizes
that the process failed to start. I think that for daemon processes,
systemd may be more capable of detecting the case where the daemon
fails after forking.

Regards,

Daniel
Francesco Poli
2017-01-06 10:10:02 UTC
Permalink
Raw Message
Post by Francesco Poli
[...]
Post by Daniel Pocock
apcupsd[10324]: A copy of the daemon is still running. If you just
stopped it,
apcupsd[10324]: please wait about 5 seconds for it to shut down.
Maybe the "stop" action should wait for it to really stop? Not
stopping/restart correctly could impact upgrades, so I've marked the bug
serious.
[...]
Post by Francesco Poli
Please fix this RC bug soon!
Hello again,
I performed some tests, but I failed to reproduce this bug.

Is anyone able to reproduce the issue on current Debian testing?


# service apcupsd restart
# service apcupsd status
● apcupsd.service - LSB: Starts apcupsd daemon
Loaded: loaded (/etc/init.d/apcupsd; generated; vendor preset: enabled)
Active: active (running) since Thu 2017-01-05 09:06:28 CET; 8s ago
Docs: man:systemd-sysv-generator(8)
Process: 24604 ExecStop=/etc/init.d/apcupsd stop (code=exited, status=0/SUCCES
Process: 24610 ExecStart=/etc/init.d/apcupsd start (code=exited, status=0/SUCC
Tasks: 3 (limit: 4915)
CGroup: /system.slice/apcupsd.service
└─24620 /sbin/apcupsd

Jan 05 09:06:28 $HOSTNAME systemd[1]: Starting LSB: Starts apcupsd daemon...
Jan 05 09:06:28 $HOSTNAME apcupsd[24610]: Starting UPS power management: apcupsd.
Jan 05 09:06:28 $HOSTNAME systemd[1]: Started LSB: Starts apcupsd daemon.
Jan 05 09:06:28 $HOSTNAME apcupsd[24620]: apcupsd 3.14.14 (31 May 2016) debian star
Jan 05 09:06:28 $HOSTNAME apcupsd[24620]: NIS server startup succeeded

# systemctl restart apcupsd
# systemctl status apcupsd
● apcupsd.service - LSB: Starts apcupsd daemon
Loaded: loaded (/etc/init.d/apcupsd; generated; vendor preset: enabled)
Active: active (running) since Thu 2017-01-05 09:50:12 CET; 9s ago
Docs: man:systemd-sysv-generator(8)
Process: 25726 ExecStop=/etc/init.d/apcupsd stop (code=exited, status=0/SUCCES
Process: 25733 ExecStart=/etc/init.d/apcupsd start (code=exited, status=0/SUCC
Tasks: 3 (limit: 4915)
CGroup: /system.slice/apcupsd.service
└─25740 /sbin/apcupsd

Jan 05 09:50:12 $HOSTNAME systemd[1]: Starting LSB: Starts apcupsd daemon...
Jan 05 09:50:12 $HOSTNAME apcupsd[25733]: Starting UPS power management: apcupsd.
Jan 05 09:50:12 $HOSTNAME systemd[1]: Started LSB: Starts apcupsd daemon.
Jan 05 09:50:12 $HOSTNAME apcupsd[25740]: apcupsd 3.14.14 (31 May 2016) debian star
Jan 05 09:50:12 $HOSTNAME apcupsd[25740]: NIS server startup succeeded
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Debian Bug Tracking System
2017-01-17 01:00:02 UTC
Permalink
Raw Message
Your message dated Tue, 17 Jan 2017 00:48:27 +0000
with message-id <E1cTHwp-000I0E-***@fasolo.debian.org>
and subject line Bug#849401: fixed in apcupsd 3.14.14-0.3
has caused the Debian Bug report #849401,
regarding restart silently fails
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 ***@bugs.debian.org
immediately.)
--
849401: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849401
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Loading...