Comment 0 for bug 1967490

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?