Bug#849401: restart silently fails

2017-01-26 Thread Francesco Poli 
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


pgp2Sw3S5R29z.pgp
Description: PGP signature

Bug#849401: restart silently fails

2017-01-16 Thread Christian Hofstaedtler 
* 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

2017-01-15 Thread Daniel Pocock 
-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

2017-01-15 Thread Francesco Poli 
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


pgpAoHppmOveq.pgp
Description: PGP signature

Bug#849401: restart silently fails

2017-01-15 Thread Daniel Pocock 


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

2017-01-15 Thread Daniel Pocock 
-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

2017-01-13 Thread Francesco Poli 
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


pgpBDQ0iAkAV4.pgp
Description: PGP signature

Bug#849401: restart silently fails

2017-01-12 Thread Christian Hofstaedtler 
* 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

2017-01-12 Thread Francesco Poli 
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


pgpjY5wCxZ2Gk.pgp
Description: PGP signature

Bug#849401: restart silently fails

2017-01-11 Thread Christian Hofstaedtler 
* 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

2017-01-11 Thread Francesco Poli 
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


pgp3PiWHryNrL.pgp
Description: PGP signature

Bug#849401: restart silently fails

2017-01-10 Thread Christian Hofstaedtler 
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

2017-01-10 Thread Francesco Poli 
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


pgp2HbBug_36V.pgp
Description: PGP signature

Bug#849401: restart silently fails

2017-01-06 Thread Francesco Poli 
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


pgpRFWwrSJlqR.pgp
Description: PGP signature

Bug#849401: restart silently fails

2017-01-06 Thread Daniel Pocock 


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

2017-01-06 Thread Francesco Poli 
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


pgpxmmgxV2ntO.pgp
Description: PGP signature

Bug#849401: restart silently fails

2017-01-03 Thread Francesco Poli 
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


pgp2LWIneCEyw.pgp
Description: PGP signature

Bug#849401: restart silently fails

2016-12-26 Thread Daniel Pocock 
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