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



## tbyte (Oct 31, 2022)

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.


----------



## mer (Oct 31, 2022)

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


----------



## tbyte (Oct 31, 2022)

mer said:


> 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.


----------



## Alain De Vos (Oct 31, 2022)

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

```
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.


----------



## mer (Oct 31, 2022)

tbyte said:


> 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.


```
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.


----------



## CuatroTorres (Oct 31, 2022)

periodic.conf
					






					www.freebsd.org
				





> _daily___accounting___enable_
> (_bool_) Set    to "YES" if you    want to    rotate your daily accounting
> files.  No    rotations are necessary    unless _accounting___enable_ is
> enabled in    rc.conf(5).


Not necessary but not ignored? Confusing behavior.


----------



## tbyte (Oct 31, 2022)

mer said:


> 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.


mer said:


> 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.


----------



## mer (Oct 31, 2022)

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.


tbyte said:


> 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.


----------



## CuatroTorres (Oct 31, 2022)

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.


----------



## tbyte (Oct 31, 2022)

mer said:


> 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.
> ...


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.


----------



## gpw928 (Nov 1, 2022)

I can't reproduce the problem:
	
	



```
[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.


----------



## tbyte (Nov 1, 2022)

gpw928 said:


> 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
> ...


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
> ...


----------

