Bug 267464

If /var/account is empty it doesn't happen. Which means once accounting is enabled you can't stop it unless you go and clear /var/account which of course is not documented anywhere as it is a unexpected behavior.

I was able to replicate this bug on my system.  I think a simple fix is to check if the accounting system process is running in the periodic script. If not, exit the periodic script indicating the service is not running instead of attempting to rotate the logs.  onerotate_log turns accounting back on regardless of what accounting_enable is set to.

I tested this patch on my local system and the periodic log rotate exits and doesn't restart the accounting service if the [accounting] process is not running.

diff --git a/usr.sbin/periodic/etc/daily/310.accounting b/usr.sbin/periodic/etc/daily/310.accounting
index b0dd786447eb..6a47690a0a6a 100755
--- a/usr.sbin/periodic/etc/daily/310.accounting
+++ b/usr.sbin/periodic/etc/daily/310.accounting
@@ -18,6 +18,10 @@ case "$daily_accounting_enable" in
            echo '$daily_accounting_enable is set but /var/account/acct' \
                "doesn't exist"
            rc=2
+       elif ! pgrep -qS accounting
+       then
+           echo 'accounting service is not active'
+           rc=2
        elif [ -z "$daily_accounting_save" ]
        then
            echo '$daily_accounting_enable is set but ' \

Ignore the last patch, it's too hacky.  Grepping for the system process is problematic due to the possibility of a process other than accounting returning true for the grep.

This patch uses the kern.acct_configured sysctl to determine if accounting is active instead.

diff --git a/usr.sbin/periodic/etc/daily/310.accounting b/usr.sbin/periodic/etc/daily/310.accounting
index b0dd786447eb..8eeed16f0516 100755
--- a/usr.sbin/periodic/etc/daily/310.accounting
+++ b/usr.sbin/periodic/etc/daily/310.accounting
@@ -18,6 +18,11 @@ case "$daily_accounting_enable" in
            echo '$daily_accounting_enable is set but /var/account/acct' \
                "doesn't exist"
            rc=2
+       elif [ $(sysctl -n kern.acct_configured) -eq 0 ]
+       then
+           echo '$daily_accounting_enable is set but' \
+           'process accounting is not active'
+           rc=2
        elif [ -z "$daily_accounting_save" ]
        then
            echo '$daily_accounting_enable is set but ' \

(In reply to John Grafton from comment #3)
Checking if the accounting is configured/running is a great idea! That way even if it is enabled by hand it will still rotate the logs.

Phabriactor review: https://reviews.freebsd.org/D37434

Comment 6 commit-hook 2023-02-28 17:00:43 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=9ab40bc40d4a07e1a9f3622a7779312ca2466b55

commit 9ab40bc40d4a07e1a9f3622a7779312ca2466b55
Author:     John Grafton <john.grafton@runbox.com>
AuthorDate: 2023-02-28 16:49:40 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2023-02-28 16:59:34 +0000

    310.accounting: Verify process accounting is active before log rotation.

    This corrects a bug in which the daily periodic script '310.accounting'
    attempts to rotate logs via /etc/rc.d/accounting by calling
    onerotate_logs function. The rotate logs function turns accounting back
    on regardless of what acccounting_enable is set to in /etc/rc.conf. This
    is due to checkyesno always returning YES since rotate logs is called
    with the 'one' prefix.

    In effect, accounting will always be turned back on once a day even if
    it is disabled and stopped by hand. The fix was simple, just check if
    accounting is before rotating logs and if it is, don't attempt the
    rotate.

    PR: 267464
    Reviewed by: imp, hps (lgtm, not approval), Mina Galić
    Pull Request: https://github.com/freebsd/freebsd-src/pull/648
    Differential Revision: https://reviews.freebsd.org/D37434

 usr.sbin/periodic/etc/daily/310.accounting | 5 +++++
 1 file changed, 5 insertions(+)