| 2022-04-01 10:02:04 |
Lorenzo Buzzi |
bug |
|
|
added bug |
| 2022-04-05 07:48:47 |
Lorenzo Buzzi |
description |
The apcupsd.service file in Ubuntu 20.04 LTS (amd64) includes the following lines:
Type=forking
PIDFile=/var/run/apcupsd.pid
The systemd documentation (https://www.freedesktop.org/software/systemd/man/systemd.service.html), searching for "Type=forking", reports the following statement:
[...]
... if the process decides to write a traditional PID file, systemd will be able to read the main PID from there. Please set PIDFile= accordingly. Note that the daemon should write that file before finishing with its initialization. Otherwise, systemd might try to read the file before it exists.
[...]
The issue is that, although the daemon is started and works correctly, the "systemctl status apcupsd.service" call always reports the following:
systemd[1]: apcupsd.service: Can't open PID file /run/apcupsd.pid (yet?) after start: Operation not permitted
This glitch is due to the fact that the parent process of the daemon exits before the child has written the PID file.
I proved this statement by recompiling apcupsd from source and inserting a "sleep(1)" before the "exit(0) /* parent exits */" call in apcupsd.c:daemon_start() function.
It fixed the issue by keeping the parent alive for a while, giving the child enough time to call make_pid_file().
I know that sleep(1) is not a bugfix rather a test for verifying the root cause of the issue.
I reported the issue to the apcupsd developers before filling this bug. Anyway although their mailing list is alive and kicking, they do not release a new version since 2016 so I am not so confident that they will fix their source (at least not soon).
So could you please implement and apply a patch to the source that delays the exit of the parent (i.e. waiting for the PID file of the child to be created) in order to make apcupsd 100% compatible with systemd? |
The apcupsd.service file in Ubuntu 20.04 LTS (amd64) includes the following lines:
Type=forking
PIDFile=/var/run/apcupsd.pid
The systemd documentation (https://www.freedesktop.org/software/systemd/man/systemd.service.html), searching for "Type=forking", reports the following statement:
[...]
... if the process decides to write a traditional PID file, systemd will be able to read the main PID from there. Please set PIDFile= accordingly. Note that the daemon should write that file before finishing with its initialization. Otherwise, systemd might try to read the file before it exists.
[...]
The issue is that, although the daemon is started and works correctly, the "systemctl status apcupsd.service" call always reports the following:
systemd[1]: apcupsd.service: Can't open PID file /run/apcupsd.pid (yet?) after start: Operation not permitted
This glitch is due to the fact that the parent process of the daemon exits before the child has written the PID file.
I proved this statement by recompiling apcupsd from source and inserting a "sleep(1)" before the "exit(0) /* parent exits */" call in the daemon_start() function (of apcupsd.c).
It fixed the issue by keeping the parent alive for a while, giving the child enough time to call make_pid_file().
I know that sleep(1) is not a bugfix rather a test for verifying the root cause of the issue.
I reported the issue to the apcupsd developers before filling this bug. Anyway although their mailing list is alive and kicking, they do not release a new version since 2016 so I am not so confident that they will fix their source (at least not soon).
So could you please implement and apply a patch to the source that delays the exit of the parent (i.e. waiting for the PID file of the child to be created) in order to make apcupsd 100% compatible with systemd? |
|
| 2022-04-05 07:49:52 |
Lorenzo Buzzi |
description |
The apcupsd.service file in Ubuntu 20.04 LTS (amd64) includes the following lines:
Type=forking
PIDFile=/var/run/apcupsd.pid
The systemd documentation (https://www.freedesktop.org/software/systemd/man/systemd.service.html), searching for "Type=forking", reports the following statement:
[...]
... if the process decides to write a traditional PID file, systemd will be able to read the main PID from there. Please set PIDFile= accordingly. Note that the daemon should write that file before finishing with its initialization. Otherwise, systemd might try to read the file before it exists.
[...]
The issue is that, although the daemon is started and works correctly, the "systemctl status apcupsd.service" call always reports the following:
systemd[1]: apcupsd.service: Can't open PID file /run/apcupsd.pid (yet?) after start: Operation not permitted
This glitch is due to the fact that the parent process of the daemon exits before the child has written the PID file.
I proved this statement by recompiling apcupsd from source and inserting a "sleep(1)" before the "exit(0) /* parent exits */" call in the daemon_start() function (of apcupsd.c).
It fixed the issue by keeping the parent alive for a while, giving the child enough time to call make_pid_file().
I know that sleep(1) is not a bugfix rather a test for verifying the root cause of the issue.
I reported the issue to the apcupsd developers before filling this bug. Anyway although their mailing list is alive and kicking, they do not release a new version since 2016 so I am not so confident that they will fix their source (at least not soon).
So could you please implement and apply a patch to the source that delays the exit of the parent (i.e. waiting for the PID file of the child to be created) in order to make apcupsd 100% compatible with systemd? |
The apcupsd.service file in Ubuntu 20.04 LTS (amd64) includes the following lines:
Type=forking
PIDFile=/var/run/apcupsd.pid
The systemd documentation (https://www.freedesktop.org/software/systemd/man/systemd.service.html), searching for "Type=forking", reports the following statement:
[...]
... if the process decides to write a traditional PID file, systemd will be able to read the main PID from there. Please set PIDFile= accordingly. Note that the daemon should write that file before finishing with its initialization. Otherwise, systemd might try to read the file before it exists.
[...]
The issue is that, although the daemon is started and works correctly, the "systemctl status apcupsd.service" call always reports the following:
systemd[1]: apcupsd.service: Can't open PID file /run/apcupsd.pid (yet?) after start: Operation not permitted
This glitch is due to the fact that the parent process of the daemon exits before the child has written the PID file.
I proved this statement by recompiling apcupsd from source and inserting a "sleep(1)" before the "exit(0) /* parent exits */" call in the daemon_start() function (of apcupsd.c).
It fixed the issue by keeping the parent alive for a while, giving the child enough time to call make_pid_file().
I know that sleep(1) is not a bugfix rather a test for verifying the root cause of the issue.
I reported the issue to the apcupsd developers before filling this bug. Anyway although their mailing list is alive and kicking, they do not release a new version since 2016 so I am not so confident that they will fix their source (at least not soon).
So could you please implement and apply a patch to the source that delays the exit of the parent (i.e. waiting for the PID file of the child to be created) in order to make apcupsd 100% compliant to what systemd expects? |
|
| 2022-06-06 12:57:54 |
Launchpad Janitor |
apcupsd (Ubuntu): status |
New |
Confirmed |
|
| 2022-06-06 13:01:24 |
reetp |
bug |
|
|
added subscriber reetp |
| 2022-08-07 01:44:18 |
Thomas Deutschmann |
bug |
|
|
added subscriber Thomas Deutschmann |
| 2022-10-02 13:39:10 |
CvB |
bug |
|
|
added subscriber CvB |
