Red Hat Bugzilla – Bug 629740
acpid doesn't fork, but systemd unit file claims otherwise
Last modified: 2014-11-09 17:33:32 EST
The acpid systemd unit file sets "Type=forking". That makes systemd expect acpid to fork on start-up. However, acpid actually has some code in there which bypasses forking when getppid() == 1, i.e. when it is started from the init system, i.e. systemd.
There are two options to fix this:
1) remove the getppid() hack, and make acpid fork even when run from systemd. While forking is ugly in theory, this has the advantage that it is clear that the acpid unix socket is properly installed before systemd continues starting other units that want to be started after acpid.
2) Change the unit file to Type=simple (in which case the option can be dropped entirely, since that is the default). In this case it might make sense to use "-f" on the acpid command like, and not rely on the getppid() hack, because that should be more discoverable by the user. But that's optional, as with or without that flag acpid won't fork when run from systemd, with its current code base.
I prefer option #2.
The service file with Type=forking was delivered through BZ#617317. There is a reference about supporting socket activation in mentioned file. Is it really enough to make changes described above (in description of this bug)?
Socket activation would be great to have but would require some patching in acpid. I think the best fix for now is to comment that getppid() line in the sources.
Can we please have a fix for this ASAP, Jiri? It causes a minimum 60 second boot time for everyone...we should really clear it for the Beta.
For anyone suffering from this who wants a temporary fix, I built a package with the 'simplest' fix - just remove the Type= line and add -f to the acpid command - for the systemd test day. That can be found at http://adamwill.fedorapeople.org/systemd_test_day_20100907/ .
acpid-2.0.5-3.fc14 has been submitted as an update for Fedora 14.
Jiri, please don't manually close the bug, allow the update system to take care of it; the bug should not be closed until the testing process is completed and the update is pushed to dist-f14, because it's not actually in F14 until then.
(In reply to comment #0)
> However, acpid actually has some code in there which
> bypasses forking when getppid() == 1, i.e. when it is started from the init
> system, i.e. systemd.
The daemonize() code in acpid comes from Doug Potter's "How to Daemonize in Linux":
It is surprising that systemd isn't compatible with this, but so be it. If there is a new way to daemonize with systemd, please point me to the page where I can find sample daemonize() code. I will then add a new daemonize function and a --systemd option to enable it. (Unless, of course, you can suggest a clever way for me to auto-detect initd vs. systemd. Then I can do away with the --systemd option altogether.)
You might also want to enlist Doug Potter's help in spreading the word about systemd by having him provide the systemd-compatible sample daemonize() code alongside his initd-compatible version.
(In reply to comment #6)
> (In reply to comment #0)
> > However, acpid actually has some code in there which
> > bypasses forking when getppid() == 1, i.e. when it is started from the init
> > system, i.e. systemd.
> The daemonize() code in acpid comes from Doug Potter's "How to Daemonize in
> It is surprising that systemd isn't compatible with this.
That's a misunderstanding. systemd is compatible with various kinds of daemon startup. But its expectation about the daemon (as described by the "Type=..." option in the daemon's unit file) really must match reality, i.e. it needs to know whether the daemon will or will not fork.
> If there is a new way to daemonize with systemd,
> please point me to the page where I can find sample daemonize() code.
The perfect way to daemonize under systemd is to not daemonize at all. Let systemd handle that for you. See the "Writing daemons" section at http://0pointer.de/blog/projects/systemd.html
But again, it is not necessary to change existing daemons. It is only necessary to describe their behaviour correctly in the unit files. systemd is compatible.
BTW, systemd ships with an elaborate man page on what to do when writing daemons:
And Doug Potter's recommendation are incomplete. A proper daemonization for classic SysV daemons must include a double fork, which he doesn't list. The manpage above is much more complete on this.
I have installed acpid-2.0.5-3.fc14.i686, but acpid shows up as "inactive (dead)" after boot.
acpid.service still says "Type=forking"
A manual "systemctl restart acpid.service" after boot starts acpid without problem.
Is this the same problem or a different (AKA wrong dependencies) one?
acpid-2.0.5-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.