Bug#849401: restart silently fails
On Tue, 17 Jan 2017 01:38:42 +0100 Christian Hofstaedtler wrote: > * Francesco Poli [170115 17:39]: > > Christian, have you decided which strategy should be adopted for the > > ISCONFIGURED handling? > > I'm going to set the default UPSTYPE to usb, so there will be no > activity on /dev/ttyS0 caused by the default configuration, and then > ignoring ISCONFIGURED under systemd should be okay. Christian, I would like to thank you for doing this NMU. It's much appreciated! :-) 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 pgpTKTu2eP2zR.pgp Description: PGP signature
Bug#849401: restart silently fails
* Francesco Poli [170115 17:39]: > Christian, have you decided which strategy should be adopted for the > ISCONFIGURED handling? I'm going to set the default UPSTYPE to usb, so there will be no activity on /dev/ttyS0 caused by the default configuration, and then ignoring ISCONFIGURED under systemd should be okay. -- christian hofstaedtler
Bug#849401: restart silently fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/01/17 17:34, Francesco Poli wrote: > On Sun, 15 Jan 2017 10:28:40 +0100 Daniel Pocock wrote: > >> >> >> On 10/01/17 23:49, Christian Hofstaedtler wrote: > [...] >>> here are some test packages with a systemd service file: >>> >>> 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. >>> >> >> >> I installed that and tested with this loop: >> >> 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYe61HAAoJEGxlgOd711bEbhoP/3It2UA8/TCmo5aT57Wdo2QL Vd1lt56zMq/snw+OOkDcQCYPhOuAsk9Ijz2qtX3f1Ou4/CKSsQaz3WTXDY/xJzMu 7o6qCPM80EuI5/txig1+d2asalkzztRv9b5H/LkbQcSOHtxmP2sylnQpzc7QnauP 8FYXunVkieNicbs4zTvFkJYH7PxUqmM5rLgA5d2gJZiNi/FKf8px+l+0WVDFk9nh gg4a1WpHVpm/mcABjXZRPicwa90oKw8dvxxJ/JiHo0BgdjwxjcLNr/wwSjdFjTAe +BVuVERkgVthsFPQfSJQL56zwWg/WMHhYRkUpaaMGrsgigVrge2AixvWZU9zSVXO gqui1dJLGQ7nRCEtdbUABOmpvH4+XZJZeqaq/spIJz9Y05nrTBFO9DRQpPu291+V BdQNry9lqJJBxwln9XkXA9Dn2RLjaKm/FBq+hsQsUz3OCC4vigA+iPoVhzjRlGI+ Q971lP1wEKGQnT6ZRJax6cZFrOQFOQyfxShQh9BlKfPkt5oMzShkNEsXUf2z0arY pf4K1vpMi8fODHs/angpxkxlHxMHt0FQ2OK5Gtl7++VMWt6x4cjgeWT6QvWOYMPE t5nbiGGNEiJ0aLbBb0mxXgYLY7uEjzZfmCQQwM4OusITYBXTe/yv2KQpMJ0Nyrb1 0ZWeezgxYUVHJ4qYVXWJ =j1i0 -END PGP SIGNATURE-
Bug#849401: restart silently fails
On Sun, 15 Jan 2017 10:28:40 +0100 Daniel Pocock wrote: > > > On 10/01/17 23:49, Christian Hofstaedtler wrote: [...] > > here are some test packages with a systemd service > > file: > > > > 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. > > > > > I installed that and tested with this loop: > > 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? -- 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 pgpiq4vUSlv9U.pgp Description: PGP signature
Bug#849401: restart silently fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/01/17 23:39, Francesco Poli wrote: > On Fri, 6 Jan 2017 11:40:20 +0100 Francesco Poli wrote: > >> On Fri, 6 Jan 2017 11:05:50 +0100 Daniel Pocock wrote: > [...] >>> 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? > I tried that on both a jessie and stretch system. The bug doesn't happen every time, although within 5 attempts in quick succession I do get the bug > Does > > # systemctl stop apcupsd ; sleep 1 ; sleep 1 ; systemctl start > apcupsd > > suffice to avoid experiencing the misbehavior? I tried this: systemctl start apcupsd && while ps -C apcupsd ; do systemctl stop apcupsd ; sleep $DELAY ; systemctl start apcupsd ; ps -C apcupsd || echo FAILED ; done for a few minutes with various $DELAY values If $DELAY == 1 the problem occurs relatively quickly. With $DELAY == 2, I did not see the problem in 2 minutes of looping. > > 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? > Based on the above testing, I suspect a 2-3 second sleep in the init script stop operation may be sufficient to work around the problem. Even better than sleep, it could use the "--retry" (waiting 7 seconds for the PID to exit): stop) echo -n "Stopping $DESC: " start-stop-daemon --stop --oknodo --pidfile /var/run/apcupsd.pid --retry 7 || echo "Not Running." wait `cat /var/run/apcupsd.pid` rm -f /var/run/apcupsd.pid echo "$NAME." ;; or "wait": stop) echo -n "Stopping $DESC: " APCUPSD_PID=`cat /var/run/apcupsd.pid` start-stop-daemon --stop --oknodo --pidfile /var/run/apcupsd.pid || echo "Not Running." wait $APCUPSD_PID rm -f /var/run/apcupsd.pid echo "$NAME." ;; or the service file proposed by Christian (I'll reply about that separately) Regards, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYe0C+AAoJEGxlgOd711bE58oP/2iD76HNouCFaP5QKuT3tRfv nP9qcNHYaf9n8FpZwYmBLTFmK6O0n2dqVeEVHQPqY0U1wfHa8eO2YAYcZ4fIXvOz T11e+JiuzIA5Sdsat+kFcvLZD447njluOVouGq+UZAhRKSMH3alrI2ug5Z0btiRn URfoUybpMYe5ojmA0np/2cHsicrSaS+OSjvUVQhageJ505YOMK+LU3gM3BresK1B ceMGo9NQPxNjngT2KEanIkUrufunh17YeKyeBui6zdAazIBgRz1PkZ/ZLSQClc1M hwzEJEYkKGKMb3LrE5mWFQk+Tw5QPWIC/3C9Uc4vBWtqX0IpVcrHyfAUkfkgjABv 14ESREtWPcPrlTVcQmLbKsUcbvAbGFx5Y5t3s7pNI5OvCJT8bXDEPCk5FH0F+82+ dDhlj39GDDsXnGiyoA23U8KX0qhU1RgkJPCFKzsEKKBYpdLBosLhJl71nPg/0pCx 5M7rIEPsq8/eX63HFcz+Z5etH1fpjEg+bN/rE8mOMY+7oZ3i4rvpmRvGWy15t1yT 6AUU49h219em2LmOkAHHjZO3oAVr4bHiLMxuwSCyB4vlbZkZRYNW7Dj/QTlt1Isb 9IodU9HLT0wP3t6Zf4gp76Qb23oCf6qtWUeSGwzydl5/ke8/0W9diLnJCEzavFrG Ug3sTUDiv9FGqRiOm1Dr =P94o -END PGP SIGNATURE-
Bug#849401: restart silently fails
On 10/01/17 23:49, Christian Hofstaedtler wrote: > Hi, > > * Daniel Pocock [170106 11:06]: >>> 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. > > Likely. > > I can't test this (my UPS is broken and it'd be a serial one > anyway), but here are some test packages with a systemd service > file: > > 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. > I installed that and tested with this loop: 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. Regards, Daniel
Bug#849401: restart silently fails
On Fri, 13 Jan 2017 00:17:16 +0100 Christian Hofstaedtler wrote: > * Francesco Poli [170113 00:15]: > > On Wed, 11 Jan 2017 23:17:47 +0100 Christian Hofstaedtler wrote: > > > 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 pgpggwgiaGcrh.pgp Description: PGP signature
Bug#849401: restart silently fails
* Francesco Poli [170113 00:15]: > On Wed, 11 Jan 2017 23:17:47 +0100 Christian Hofstaedtler wrote: > > 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. -ch
Bug#849401: restart silently fails
On Wed, 11 Jan 2017 23:17:47 +0100 Christian Hofstaedtler wrote: > * Francesco Poli [170111 22:51]: [...] > > 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 pgpof7lrpMgF1.pgp Description: PGP signature
Bug#849401: restart silently fails
* Francesco Poli [170111 22:51]: > However, I glanced over the diff between > apcupsd_3.14.14-0.2.debian.tar.xz and the proposed > apcupsd_3.14.14-0.3.debian.tar.xz: the only thing that looks suspicious > is that 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. Suggestions on the actual implementation also welcome ;-) (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...) -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `-
Bug#849401: restart silently fails
On Tue, 10 Jan 2017 23:49:43 +0100 Christian Hofstaedtler wrote: > Hi, Hello Christian! :-) First off, many thanks for stepping in. I really appreciate that you're proposing a longer term solution than what I was thinking about (I was planning to propose a little patch for the apcupsd.init file, but writing a dedicated apcupsd.service file is clearly cleaner and better). > > * Daniel Pocock [170106 11:06]: > > > 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. > > Likely. > > I can't test this (my UPS is broken and it'd be a serial one > anyway), but here are some test packages with a systemd service > file: > > https://people.debian.org/~zeha/apcupsd/ > > Please report back if those work for you and if the restart issue > is fixed. I haven't had a chance to actually test the package, but, as far as tests are concerned, let's primarily wait for Daniel's feedback (that will hopefully arrive real soon now!). However, I glanced over the diff between apcupsd_3.14.14-0.2.debian.tar.xz and the proposed apcupsd_3.14.14-0.3.debian.tar.xz: the only thing that looks suspicious is that 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... Please let me know. Thanks a lot 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 pgpy9LOwBrLPQ.pgp Description: PGP signature
Bug#849401: restart silently fails
Hi, * Daniel Pocock [170106 11:06]: > > 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. Likely. I can't test this (my UPS is broken and it'd be a serial one anyway), but here are some test packages with a systemd service file: 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. -ch
Bug#849401: restart silently fails
On Fri, 6 Jan 2017 11:40:20 +0100 Francesco Poli wrote: > On Fri, 6 Jan 2017 11:05:50 +0100 Daniel Pocock wrote: [...] > > 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 pgp2wVSZIEGw4.pgp Description: PGP signature
Bug#849401: restart silently fails
On Fri, 6 Jan 2017 11:05:50 +0100 Daniel Pocock wrote: > > > On 06/01/17 11:03, Francesco Poli wrote: > > On Tue, 3 Jan 2017 22:33:53 +0100 Francesco Poli wrote: > > > >> On Mon, 26 Dec 2016 18:15:20 +0100 Daniel Pocock wrote: > >> > >> [...] > >>> 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. > > [...] > >> 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? A fairly short time, actually: # time service apcupsd restart real0m0.089s user0m0.004s sys 0m0.012s > > My UPS uses SNMP signalling, I wonder if that makes the daemon shut > down more slowly. Maybe... I use a USB UPS, instead: $ grep '^[^#].*usb' /etc/apcupsd/apcupsd.conf UPSCABLE usb UPSTYPE usb -- 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 pgpxkQk9viKOc.pgp Description: PGP signature
Bug#849401: restart silently fails
On 06/01/17 11:03, Francesco Poli wrote: > On Tue, 3 Jan 2017 22:33:53 +0100 Francesco Poli wrote: > >> On Mon, 26 Dec 2016 18:15:20 +0100 Daniel Pocock wrote: >> >> [...] >>> 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. > [...] >> 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 > (/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 > > >
Bug#849401: restart silently fails
On Tue, 3 Jan 2017 22:33:53 +0100 Francesco Poli wrote: > On Mon, 26 Dec 2016 18:15:20 +0100 Daniel Pocock wrote: > > [...] > > 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. [...] > 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 pgpoZmjcN4j3s.pgp Description: PGP signature
Bug#849401: restart silently fails
On Mon, 26 Dec 2016 18:15:20 +0100 Daniel Pocock wrote: [...] > 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/msg0.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 pgpAw_3nPSS7L.pgp Description: PGP signature
Bug#849401: restart silently fails
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
