After a log rotate for psacct, processes are logged in /var/account/pacct for a few processes, after which nothing is logged. After the next log rotate, a few processes are logged again and then again stop. This happens in Fedora 38 and 37 log rotation works properly in RHEL 8 The configuration file /etc/logrotate.d/psacct is identical across RHEL8 and Fedora 37,38 When the logging has stopped "systemctl restart psacct.service" will restart the logging correctly until the next log rotation. Reproducible: Always Steps to Reproduce: 1. dnf install psacct logrotate 2. systemctl enable --now psacct.service logrotate.service 3. After midnight observe the output of lastcomm Actual Results: After a log rotate (after midnight): # lastcomm logrotate S root __ 0.04 secs Wed May 10 00:01 logrotate S root __ 0.04 secs Wed May 10 00:01 sh root __ 0.00 secs Wed May 10 00:01 grep root __ 0.00 secs Wed May 10 00:01 cat root __ 0.00 secs Wed May 10 00:01 accton S root __ 0.00 secs Wed May 10 00:01 # Expected Results: lastcomm should still be logging processes. systemctl restart psacct.service will make psacct restart logging until the next rotation. Fedora 38: rpm -q logrotate psacct logrotate-3.21.0-2.fc38.x86_64 psacct-6.6.4-15.fc38.2.x86_64 and on a Fedora 37: rpm -q logrotate psacct logrotate-3.20.1-3.fc37.x86_64 psacct-6.6.4-14.fc37.x86_64
logrotate just executes the `postrotate` script embedded in /etc/logrotate.d/psacct. Both /usr/sbin/accton and /etc/logrotate.d/psacct are owned by psacct.
An observation. I modified /etc/logrotate.d/psacct in the postrotate stanza to do a sleep and another accton: /var/account/pacct { compress delaycompress notifempty daily rotate 31 create 0600 root root postrotate if /usr/bin/systemctl --quiet is-active psacct.service ; then /usr/sbin/accton /var/account/pacct | /usr/bin/grep -v "Turning on process accounting, file set to '/var/account/pacct'." | /usr/bin/cat sleep 120 /usr/sbin/accton /var/account/pacct | /usr/bin/grep -v "Turning on process accounting, file set to '/var/account/pacct'." | /usr/bin/cat fi endscript } The result was that psacct stopped again after logrotate finished. This is the output of lastcomm many hours after the logrotate: # lastcomm logrotate S root __ 0.05 secs Tue May 16 00:01 logrotate S root __ 0.05 secs Tue May 16 00:01 sh root __ 0.00 secs Tue May 16 00:01 cat root __ 0.00 secs Tue May 16 00:03 grep root __ 0.00 secs Tue May 16 00:03 accton S root __ 0.00 secs Tue May 16 00:03 accton root __ 0.00 secs Tue May 16 00:03 sleep root __ 0.00 secs Tue May 16 00:01 ThreadPoolForeg F X ngaywood __ 0.01 secs Tue May 16 00:02 chrome F X ngaywood __ 0.22 secs Mon May 15 23:56 chrome F X ngaywood __ 0.08 secs Tue May 16 00:01 systemd-userwor S root __ 0.00 secs Mon May 15 23:57 systemd-userwor S root __ 0.01 secs Mon May 15 23:57 kworker/dying F root __ 0.00 secs Mon May 15 23:51 systemd-userwor S root __ 0.00 secs Mon May 15 23:56 ThreadPoolForeg F X ngaywood __ 0.05 secs Tue May 16 00:00 grep root __ 0.00 secs Tue May 16 00:01 cat root __ 0.00 secs Tue May 16 00:01 accton S root __ 0.00 secs Tue May 16 00:01 #
I work around this problem with the following crontab entry: 10 0 * * * /opt/sbin/restart-psacct The /opt/sbin/restart-psacct script is: #!/usr/bin/bash # Something is wrong with the interaction of logrotate and psaact # psacct stops after the logrotate # https://bugzilla.redhat.com/show_bug.cgi?id=2196754 # Run this a few minutes after logrotate that happens at midnight if /usr/bin/systemctl --quiet is-active psacct.service then /usr/sbin/accton /var/account/pacct | /usr/bin/grep -v "Turning on process accounting, file set to '/var/account/pacct'." | /usr/bin/cat fi
This looks like the same bug: https://github.com/amazonlinux/amazon-linux-2023/issues/197
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
This problem remains the same in Fedora 40
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This is still an issue in Fedora 42 I suspect that this issue is a timing problem in the kernel along the lines of: https://access.redhat.com/solutions/3363651 So not really a problem with logrotate. I guess not enough people care enough about this to investigate? My "solution" is to run "/usr/sbin/accton /var/account/pacct" once an hour from cron.
Fedora Linux 40 entered end-of-life (EOL) status on 2025-05-13. Fedora Linux 40 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.