Red Hat Bugzilla – Bug 974716
psacct.service fails to start if accounting file already exists
Last modified: 2016-01-31 20:58:37 EST
Description of problem: Service psacct.service fails to start if accounting file already exists (= after it was started at least once). Version-Release number of selected component (if applicable): psacct-6.6.1-2.fc19.x86_64 How reproducible: Always after first successful run. Steps to Reproduce: 1. run "systemctl start psacct" 2. if it is started (it should when run first time after installation), stop it and try to start again 3. check the result Actual results: Job for psacct.service failed. See 'systemctl status psacct.service' and 'journalctl -xn' for details. And from systemctl status: # systemctl status psacct.service psacct.service - Kernel process accounting Loaded: loaded (/usr/lib/systemd/system/psacct.service; enabled) Active: failed (Result: exit-code) since Sat 2013-06-15 01:32:57 CEST; 6s ago Process: 1664 ExecStop=/usr/sbin/accton off (code=exited, status=0/SUCCESS) Process: 1654 ExecStart=/usr/sbin/accton /var/account/pacct (code=exited, status=0/SUCCESS) Process: 1669 ExecStartPre=/usr/libexec/psacct/accton-create (code=exited, status=1/FAILURE) Jun 15 01:32:57 localhost.localdomain systemd[1]: psacct.service: control process exited, code=exited status=1 Jun 15 01:32:57 localhost.localdomain systemd[1]: Failed to start Kernel process accounting. Jun 15 01:32:57 localhost.localdomain systemd[1]: Unit psacct.service entered failed state. Expected results: Process accounting is started. Additional info: It seems that the problem is in /usr/libexec/psacct/accton-create script: --snip-- #!/bin/sh ACCTFILE=/var/account/pacct [ ! -r $ACCTFILE ] && touch $ACCTFILE && chmod 600 $ACCTFILE --snip-- Obviously, when accounting file already exists, the script will exit with non-zero status, which is propagated to systemd, thus reporting (incorrectly) failure. Actually, "[ ! -r $ACCTFILE ] && " is not needed at all, as touch will try to create file if it doesn't exist, and chmod won't hurt in any case.
Hello Alexander. You're right. I blindly copied the line from the psacct initscript. The condition is mandatory, since we don't want to overwrite possibly customized permissions each time the service is started. There are two solutions for the issue: 1.) add 'exit 0' at the end 2.) use the 'if then fi' style condition I'm gonna decide and fix that. Thanks for the report. Regards, Jaromir.
The second option seems to be more correct. It returns failure when the creation or the permission change fails. In that case it's reasonable to return non-zero. The change is committed, pushed and the package is going to be rebuilt in few minutes.
psacct-6.6.1-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/psacct-6.6.1-3.fc19
Package psacct-6.6.1-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing psacct-6.6.1-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11051/psacct-6.6.1-3.fc19 then log in and leave karma (feedback).
psacct-6.6.1-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.