310.accounting enables accounting even if it is disabled in rc.conf

Even when accounting_enable="NO" in /etc/rc.conf the periodic /etc/periodic/daily/310.accounting enables it every day at 3:00. The service /etc/rc.d/accounting checks for if checkyesno accounting_enable but it is useless because in 310.accouting is used /etc/rc.d/accounting onerotate_log and "one" forces accounting_enable="YES"
What is the purpose of forcing the accounting with the "one" ? And is there a way of fixing that other than pulling in /etc/defaults/rc.conf and checking for accounting_enable ?

Currently a temporary workaround should be setting daily_accounting_enable="NO" in /etc/periodic.conf but that bug should be fixed.
 
My opinion is it's acting as designed.
periodic scripts may utilize rc scripts but serve a different purpose.
If you do not want the periodic accounting job to run the proper thing is to disable it in /etc/periodic.conf
 
My opinion is it's acting as designed.
periodic scripts may utilize rc scripts but serve a different purpose.
If you do not want the periodic accounting job to run the proper thing is to disable it in /etc/periodic.conf
I knew that somebody will come up with that excuse sooner than later. But it is wrong and a bug.
When I say that I don't want accounting in rc.conf I don't want random script to enable it in 3:00 in the morning. There is no logic in that and it makes no sense what's so ever. It makes the accounting_enable="NO" absolutely useless so what's the point of having it at all ?
And btw daily_accounting_enable="YES" should rotate the logs and NOT enable the accounting frivolously.
 
I agree with mer. rc.conf is for services in /etc/rc.d & /usr/local/etc/rc.d.
It's not a substitute for /etc/periodic.conf
I don't care about security, my periodic.conf
Code:
daily_queuerun_enable="NO"              # Run mail queue
daily_status_include_submit_mailq="NO"          # Also submit queue
daily_status_security_enable="NO"           # Security check
daily_submit_queuerun="NO"              # Also submit queue
monthly_status_security_enable="NO"         # Security check
security_status_logincheck_enable="NO"
weekly_status_security_enable="NO"          # Security check
Offcourse these lines in rc.conf will not work.
Unless there is a specific script in /etc/rc.d or /usr/local/etc/rc.d.
 
I knew that somebody will come up with that excuse sooner than later. But it is wrong and a bug.
Excuse? Hardly. Please note that I said "My Opinion". Means based on my understanding of the system (which by the way dates from about the same timeframe as what you stated in another thread) rc.conf has it's purpose, periodic.conf has it's own different purpose.

Does having periodic call accounting oneshot actually LEAVE accounting enabled or does it simply "run it once?"

Unless I've lost my ability to understand sh script, this section is what is called by that invocation in periodic, it's not actually enabling accounting, it's simply rotating the file if it exists and is actually checking for accounting_enable before it actually tries to create a new one. Ergo, "functioning as designed". Based on this and your setting of the variables, I'd guess that accounting is not running, you merely have the periodic script running to rotate the log every day. If you don't want that you disable it in periodic.conf.

Bash:
accounting_rotate_log()
{
        # Note that this function must handle being called as "onerotate_log"
        # (by the periodic scripts) when accounting is disabled, and handle
        # being called multiple times (by an admin making mistakes) without
        # anything having actually rotated the old .0 file out of the way.

        if [ -e "${accounting_file}.0" ]; then
                err 1 "Cannot rotate accounting log, ${accounting_file}.0 already exists."
        fi

        if [ ! -e "${accounting_file}" ]; then
                err 1 "Cannot rotate accounting log, ${accounting_file} does not exist."
        fi
 
        mv ${accounting_file} ${accounting_file}.0

        if checkyesno accounting_enable; then
                create_accounting_file
                ${accounting_command} "${accounting_file}"
        fi
}

For the record, /etc/defaults/rc.conf has
rc.conf:accounting_enable="NO" # Turn on process accounting (or NO).
and
/etc/defaults/periodic.conf has:
periodic.conf:daily_accounting_enable="YES" # Rotate acct files

I've never set either on my systems, I have never had an accounting log file show up.

I'm not going to argue with you over it, you think it's a bug, well the best thing to do is file a bug report and let the developers figure it out. Arguing with people here about it, doesn't move anything forward.
 
Excuse? Hardly. Please note that I said "My Opinion". Means based on my understanding of the system (which by the way dates from about the same timeframe as what you stated in another thread) rc.conf has it's purpose, periodic.conf has it's own different purpose.

Does having periodic call accounting oneshot actually LEAVE accounting enabled or does it simply "run it once?"
Yes it leaves it enabled. That's how I found out.
Unless I've lost my ability to understand sh script, this section is what is called by that invocation in periodic, it's not actually enabling accounting, it's simply rotating the file if it exists and is actually checking for accounting_enable before it actually tries to create a new one. Ergo, "functioning as designed". Based on this and your setting of the variables, I'd guess that accounting is not running, you merely have the periodic script running to rotate the log every day. If you don't want that you disable it in periodic.conf.
I think you missed the "one" in 310.accouting when it invokes /etc/rc.d/accounting onerotate_log. Which forces accounting_enable to "YES" hence enabling the accounting in the kernel hence slowing the server down in 3:00 in the morning. So it doesn't just try to rotate the logs but does unexpected things. And I don't think people like their servers to do unexpected things in the middle of the night.
 
Show me the code in /etc/rc.d/accounting where onerotate_log does what you say.
The code in 13.1-RELEASE-p2 does not do that. It CHECKS if accounting_enable is set to YES/TRUE but I do not see where it modifies /etc/rc.conf to leave it permanently enabled.

The "one" on any rc service command is "run this one time regardless of what the setting for the variable is" It does not and never had MODIFIED the state of the variable permanently.
And I don't think people like their servers to do unexpected things in the middle of the night.
I will agree to this statement but I don't believe you have provided proof that this is happening.

If you think you have run across a bug, then go file a bug report and argue with the developers of that specific section.

I'm done trying to have an actual discussion with you because you don't seem to be actually reading and understanding what I'm saying. You are invested in your position that "this is wrong this is a bug" and ignoring anything I'm saying. So, go file a bug.
 
It looks like rc.conf does not modify downstream. If you consider it wrong, you would present it on the mailing lists before sending a bug, that's where the developers are. Check the operation in the handbook or wait for clearer explanations.
Just my opinion.
 
Show me the code in /etc/rc.d/accounting where onerotate_log does what you say.
The code in 13.1-RELEASE-p2 does not do that. It CHECKS if accounting_enable is set to YES/TRUE but I do not see where it modifies /etc/rc.conf to leave it permanently enabled.

The "one" on any rc service command is "run this one time regardless of what the setting for the variable is" It does not and never had MODIFIED the state of the variable permanently.

I will agree to this statement but I don't believe you have provided proof that this is happening.

If you think you have run across a bug, then go file a bug report and argue with the developers of that specific section.
1. It looks like you don't really understand the code or how the RC system works. /etc/rc.d/accounting won't set anything. The functions in the rc.subr will.
2. It seem like you don't understand how "accounting" works either. By "permanent" I mean that "accounting" is enabled permanently in the kernel until reboot and then it is enabled AGAIN in 3:00 in the morning after the reboot no mater how you set the accounting_enable variable in rc.conf.
3. You can test what I say yourself. It takes literally 10 seconds.

And this is the log. The "disable" is when i disabled it by hand:
Oct 30 03:01:01 TiTaN kernel: Accounting enabled
Oct 30 03:44:46 TiTaN kernel: Accounting disabled
Oct 31 03:01:01 TiTaN kernel: Accounting enabled
Oct 31 04:05:10 TiTaN kernel: Accounting disabled
To check if accounting is in use sysctl kern.acct_configured where 0 is off 1 is on.
Use accton without parameters to disable it.

PS: I already filed a PR.
 
I can't reproduce the problem:
Code:
[strand.129] # uname -a
FreeBSD strand.my.domain 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC amd64
[strand.130] # grep -i accounting /etc/rc.conf
[strand.131] # sysctl kern.acct_configured
kern.acct_configured: 0
[strand.132] # cat /etc/periodic.conf
cat: /etc/periodic.conf: No such file or directory
[strand.133] # cat /etc/periodic.conf.local
cat: /etc/periodic.conf.local: No such file or directory
[strand.134] # cd /var/log
[strand.135] # grep "periodic daily" /var/log/cron | tail -2
Oct 31 03:01:00 strand /usr/sbin/cron[4693]: (root) CMD (periodic daily)
Nov  1 03:01:00 strand /usr/sbin/cron[8218]: (root) CMD (periodic daily)
[strand.136] # grep -i accounting * 2>/dev/null
[strand.137]
My system is configured in the default way, and kernel accounting never runs.
 
  • Like
Reactions: mer
I can't reproduce the problem:
...
My system is configured in the default way, and kernel accounting never runs.

#:> grep acc /etc/rc.conf
accounting_enable="NO"
root@TiTaN:/etc on 1
#:> sysctl kern.acct_configured
kern.acct_configured: 0
root@TiTaN:/etc on 1
#:> /etc/periodic/daily/310.accounting

Rotating accounting logs and gathering statistics:
root@TiTaN:/etc on 1
#:> sysctl kern.acct_configured
kern.acct_configured: 1
What I think is happening (just guessing here) is that you have to had it enabled at least once for this to happen. I'm guessing your /var/account/ is empty ? Can you try to enable the accounting with 'onestart' for example then 'onestop' and then redo the test ?

PS: Yes I was right. If /var/account is empty it doesn't happen. Which means once 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.
root@TiTaN:/var/account on 1
#:> /etc/periodic/daily/310.accounting
$daily_accounting_enable is set but /var/account/acct doesn't exist
root@TiTaN:/var/account on 1
#:> ls
root@TiTaN:/var/account on 1
#:>
 
Back
Top