FS#42106 - [apcupsd] does not auto start after system failure

Attached to Project: Community Packages
Opened by Alexander Meshcheryakov (Self-Perfection) - Wednesday, 24 September 2014, 19:52 GMT
Last edited by Florian Pritz (bluewind) - Friday, 10 October 2014, 23:03 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Florian Pritz (bluewind)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Upon boot after system failure apcupsd unit enters failed state.

Steps to reproduce:
- Enable & start apcupsd.service
- Halt system unproperly (i.e. pull off power cord)
- Upon next boot apcupsd does not start. Example:

$ systemctl status apcupsd
● apcupsd.service - APC UPS Monitor
Loaded: loaded (/usr/lib/systemd/system/apcupsd.service; enabled)
Active: failed (Result: exit-code) since Вт 2014-09-23 15:01:41 MSK; 1 day 1h ago
Process: 490 ExecStart=/usr/bin/apcupsd -b (code=exited, status=1/FAILURE)
Main PID: 490 (code=exited, status=1/FAILURE)

сен 23 15:01:38 Atlantis systemd[1]: Started APC UPS Monitor.
сен 23 15:01:38 Atlantis apcupsd[490]: Valid lock file for pid=489, but not ours pid=490
сен 23 15:01:38 Atlantis apcupsd[490]: apcupsd FATAL ERROR in apcupsd.c at line 283
Unable to create UPS lock file.
If apcupsd or apctest is already running,...
сен 23 15:01:38 Atlantis apcupsd[490]: apcupsd FATAL ERROR in apcupsd.c at line 283
сен 23 15:01:38 Atlantis apcupsd[490]: Unable to create UPS lock file.
сен 23 15:01:38 Atlantis apcupsd[490]: If apcupsd or apctest is already running,
сен 23 15:01:38 Atlantis apcupsd[490]: please stop it and run this program again.
сен 23 15:01:41 Atlantis systemd[1]: apcupsd.service: main process exited, code=exited, status=1/FAILURE
сен 23 15:01:41 Atlantis systemd[1]: Unit apcupsd.service entered failed state.


=================

Looks like apcupsd finds old /var/run/apcupsd.pid file and refuses to start "another instance" (though old instance is gone).

As a solution I propose to add

r /var/run/apcupsd.pid

to /usr/lib/tmpfiles.d/apcupsd.conf
This task depends upon

Closed by  Florian Pritz (bluewind)
Friday, 10 October 2014, 23:03 GMT
Reason for closing:  Fixed
Additional comments about closing:  apcupsd 3.14.12-3
Comment by Doug Newgard (Scimmia) - Thursday, 25 September 2014, 00:04 GMT
By default, /var/run is a symlink to /run, which is volatile storage (tmpfs) and does not survive a reboot. Do you have it set up differently?
Comment by Alexander Meshcheryakov (Self-Perfection) - Thursday, 25 September 2014, 06:23 GMT
Doug, I missed this bit. My setup follows defaults:

$ namei /var/run/apcupsd.pid
f: /var/run/apcupsd.pid
d /
d var
l run -> ../run
d ..
d run
— apcupsd.pid
$ df -hT /run
Filesystem Type Size Used Avail Use% Mounted on
run tmpfs 16G 9,4M 16G 1% /run


I performed additional research and found thread on arch forum which describes the same issue:
https://bbs.archlinux.org/viewtopic.php?id=164934

Apparently I stumbled on the same issue:
$ grep LOCK /etc/apcupsd/apcupsd.conf
# LOCKFILE <path to lockfile>
LOCKFILE /etc/apcupsd
$ cat /etc/apcupsd/LCK..hiddev\[0-9\]
0000000484

(side note: strange name for lock file… but looks like upstream bug).

So here is proposal #2 (update: instead of original):
add following line to /usr/lib/tmpfiles.d/apcupsd.conf
d /run/apcupsd 0755 root root

and change default value of LOCKFILE in /etc/apcupsd/apcupsd.conf to
LOCKFILE /run/apcupsd
Comment by Doug Newgard (Scimmia) - Thursday, 25 September 2014, 14:16 GMT
So you're still proposing your original solution that does nothing? At least the second part has a chance or working.
Comment by Alexander Meshcheryakov (Self-Perfection) - Thursday, 25 September 2014, 14:32 GMT
Doug, your first comment provoked me to do additional research and I discovered, that original solution is useless, disregard it.

Loading...