Bug 974716 - psacct.service fails to start if accounting file already exists
psacct.service fails to start if accounting file already exists
Product: Fedora
Classification: Fedora
Component: psacct (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Jaromír Cápík
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-06-14 19:52 EDT by Alexander Demenshin
Modified: 2016-01-31 20:58 EST (History)
3 users (show)

See Also:
Fixed In Version: psacct-6.6.1-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-06-29 14:48:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexander Demenshin 2013-06-14 19:52:22 EDT
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):


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:

[ ! -r $ACCTFILE ] && touch $ACCTFILE && chmod 600 $ACCTFILE

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.
Comment 1 Jaromír Cápík 2013-06-17 08:44:42 EDT
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.

Comment 2 Jaromír Cápík 2013-06-17 08:57:42 EDT
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.
Comment 3 Fedora Update System 2013-06-17 09:28:08 EDT
psacct-6.6.1-3.fc19 has been submitted as an update for Fedora 19.
Comment 4 Fedora Update System 2013-06-17 13:02:16 EDT
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:
then log in and leave karma (feedback).
Comment 5 Fedora Update System 2013-06-29 14:48:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.