Re: accton(8) requires a reboot after being enabled
I don't think we should do that. Alexander Bluhm wrote: > On Fri, Oct 30, 2020 at 09:59:09AM -0600, Theo de Raadt wrote: > > 1 - historically it requires a file to be pre-created. In the rc scripts, > > this is a touch. That grabs the umask and ownership of root's run of > > /etc/rc. > > 2 - could we do better, in some way? > > We could do the same as we do with other logfiles. Create them > during installation like syslog log files. User can simply enable > accounting. Nothing changes for existing installations. > > bluhm > > Index: distrib/sets/lists/etc/mi > === > RCS file: /data/mirror/openbsd/cvs/src/distrib/sets/lists/etc/mi,v > retrieving revision 1.218 > diff -u -p -r1.218 mi > --- distrib/sets/lists/etc/mi 2 Dec 2019 02:45:18 - 1.218 > +++ distrib/sets/lists/etc/mi 3 Nov 2020 16:55:31 - > @@ -50,6 +50,7 @@ > ./root/.login > ./root/.profile > ./root/.ssh/authorized_keys > +./var/account/acct > ./var/crash/minfree > ./var/cron/at.deny > ./var/cron/cron.deny >
Re: accton(8) requires a reboot after being enabled
On Fri, Oct 30, 2020 at 09:59:09AM -0600, Theo de Raadt wrote: > 1 - historically it requires a file to be pre-created. In the rc scripts, > this is a touch. That grabs the umask and ownership of root's run of > /etc/rc. > 2 - could we do better, in some way? We could do the same as we do with other logfiles. Create them during installation like syslog log files. User can simply enable accounting. Nothing changes for existing installations. bluhm Index: distrib/sets/lists/etc/mi === RCS file: /data/mirror/openbsd/cvs/src/distrib/sets/lists/etc/mi,v retrieving revision 1.218 diff -u -p -r1.218 mi --- distrib/sets/lists/etc/mi 2 Dec 2019 02:45:18 - 1.218 +++ distrib/sets/lists/etc/mi 3 Nov 2020 16:55:31 - @@ -50,6 +50,7 @@ ./root/.login ./root/.profile ./root/.ssh/authorized_keys +./var/account/acct ./var/crash/minfree ./var/cron/at.deny ./var/cron/cron.deny
Re: accton(8) requires a reboot after being enabled
Hi Jason, Jason McIntyre wrote on Mon, Nov 02, 2020 at 05:29:37PM +: > - adding EXIT STATUS makes sense. i agree. So i added just the .Sh and .Ex lines. All the rest (both regarding "file" and "install") seems controversial and hardly worth have a long discussion, so i dropped all the rest. Yours, Ingo
Re: accton(8) requires a reboot after being enabled
Ingo Schwarze wrote: > Hi Theo, > > Theo de Raadt wrote on Fri, Oct 30, 2020 at 12:10:41PM -0600: > > > Yes, that diff is a whole bunch of TOCTUO. > > > > If this was going to be changed, it should be in the kernel. > > > > But I don't know if it should be changed yet, which is why I asked > > a bunch of questions. > > > > Stepping back to the man page change, we could decide that accton > > should continue to behave how it does, and this conversation started > > because the man page fell into the trap of documenting the rc scripts > > RATHER than documenting accton. > > Given that nobody seems in a rush to patch the kernel, i suggest to > improve the accton(8) manual page for now. In particular, that > manual page lacks the required EXIT STATUS section, which happens > to be a natural place for mentioning what happens if the file does > not exist. I guess so. > As usual, an EXAMPLES section is not strictly required, but in this > case, it seems useful to me, to save people from having to inspect there are only two ways to use this command. I don't think making one of them an example helps anymore. You have to be really dumb to misuse the command. I think this conversation came from a misguided origin. I think the man page documents accton correctly. The error occurs when it tries to document rc. But even that text is correct, it says: To have accton enabled at boot time Well if you don't reboot, it isn't enabled NOW, or it would have said "to enable and start accounting". I think this is making a mountain out of a mole hill.
Re: accton(8) requires a reboot after being enabled
On Mon, Nov 02, 2020 at 03:27:58PM +0100, Ingo Schwarze wrote: > Hi Theo, > > Theo de Raadt wrote on Fri, Oct 30, 2020 at 12:10:41PM -0600: > > > Yes, that diff is a whole bunch of TOCTUO. > > > > If this was going to be changed, it should be in the kernel. > > > > But I don't know if it should be changed yet, which is why I asked > > a bunch of questions. > > > > Stepping back to the man page change, we could decide that accton > > should continue to behave how it does, and this conversation started > > because the man page fell into the trap of documenting the rc scripts > > RATHER than documenting accton. > > Given that nobody seems in a rush to patch the kernel, i suggest to > improve the accton(8) manual page for now. In particular, that agreed > manual page lacks the required EXIT STATUS section, which happens > to be a natural place for mentioning what happens if the file does > not exist. > > As usual, an EXAMPLES section is not strictly required, but in this > case, it seems useful to me, to save people from having to inspect > /etc/mtree/special for the recommended file permissions. > > OK? > Ingo > i'm less sure here. first off the issue was about whether accton was documenting things it shouldn;t (rcctl etc.). as far as that issue is concerned, our man pages pretty much all got converted to the format accton is currently in. ntpd(8) is an exception. the fact that i prefer the wording in ntpd(8) is not really relevant - unless we agree that the approach is wrong and aim to change all relevant pages, i think the text in accton(8) should stay. as to your diff: - adding EXIT STATUS makes sense. i agree. but i don;t think it should discuss "file". firstly it'd be in isolation, so confuse people (what file?). secondly the logical place would surely be when we discuss the file argument. - adding EXAMPLES seems flawed. it's not an example of how to use it. if anything it belongs in the main body. but i don;t think it makes sense at all. so the only part i'm happy with is adding EXIT STATUS i don;t plan to take any action on the page as-is, for reasons explained above. jmc > > Index: accton.8 > === > RCS file: /cvs/src/usr.sbin/accton/accton.8,v > retrieving revision 1.12 > diff -u -r1.12 accton.8 > --- accton.8 2 Nov 2020 13:58:44 - 1.12 > +++ accton.8 2 Nov 2020 14:19:43 - > @@ -64,6 +64,17 @@ > .It Pa /var/account/acct > default accounting file > .El > +.Sh EXIT STATUS > +.Ex -std > +For example, it is an error if the > +.Ar file > +does not exist. > +.Sh EXAMPLES > +The following commands enable accounting if it was never used before: > +.Bd -literal -offset 4n > +# install -o root -g wheel -m 0644 /dev/null /var/account/acct > +# accton /var/account/acct > +.Ed > .Sh SEE ALSO > .Xr lastcomm 1 , > .Xr acct 2 , >
Re: accton(8) requires a reboot after being enabled
Hi Theo, Theo de Raadt wrote on Fri, Oct 30, 2020 at 12:10:41PM -0600: > Yes, that diff is a whole bunch of TOCTUO. > > If this was going to be changed, it should be in the kernel. > > But I don't know if it should be changed yet, which is why I asked > a bunch of questions. > > Stepping back to the man page change, we could decide that accton > should continue to behave how it does, and this conversation started > because the man page fell into the trap of documenting the rc scripts > RATHER than documenting accton. Given that nobody seems in a rush to patch the kernel, i suggest to improve the accton(8) manual page for now. In particular, that manual page lacks the required EXIT STATUS section, which happens to be a natural place for mentioning what happens if the file does not exist. As usual, an EXAMPLES section is not strictly required, but in this case, it seems useful to me, to save people from having to inspect /etc/mtree/special for the recommended file permissions. OK? Ingo Index: accton.8 === RCS file: /cvs/src/usr.sbin/accton/accton.8,v retrieving revision 1.12 diff -u -r1.12 accton.8 --- accton.82 Nov 2020 13:58:44 - 1.12 +++ accton.82 Nov 2020 14:19:43 - @@ -64,6 +64,17 @@ .It Pa /var/account/acct default accounting file .El +.Sh EXIT STATUS +.Ex -std +For example, it is an error if the +.Ar file +does not exist. +.Sh EXAMPLES +The following commands enable accounting if it was never used before: +.Bd -literal -offset 4n +# install -o root -g wheel -m 0644 /dev/null /var/account/acct +# accton /var/account/acct +.Ed .Sh SEE ALSO .Xr lastcomm 1 , .Xr acct 2 ,
Re: accton(8) requires a reboot after being enabled
Following diff changes accton(8) behavior.
If the file given as parameter doesn't exists, accton will create it.
Then it will check the ownership and will make it root:wheel if
it's different.
I added a check to be sure it's run as root because it's has no use if
not run as root.
I don't often write C, if the logic is good but the C implementation
wrong I'm open to critic.
The -f test and touch in /etc/rc won't be needed anymore with this
change.
Index: accton.8
===
RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v
retrieving revision 1.11
diff -u -p -r1.11 accton.8
--- accton.810 Nov 2019 20:51:53 - 1.11
+++ accton.830 Oct 2020 17:27:36 -
@@ -36,7 +36,7 @@
.Nm accton
.Op Ar file
.Sh DESCRIPTION
-With an argument naming an existing
+With an argument naming a
.Ar file ,
.Nm
causes system accounting information for every process executed
Index: accton.c
===
RCS file: /home/reposync/src/usr.sbin/accton/accton.c,v
retrieving revision 1.8
diff -u -p -r1.8 accton.c
--- accton.c27 Oct 2009 23:59:50 - 1.8
+++ accton.c30 Oct 2020 17:26:31 -
@@ -27,6 +27,7 @@
* SUCH DAMAGE.
*/
+#include
#include
#include
#include
@@ -47,6 +48,10 @@ int
main(int argc, char *argv[])
{
int ch;
+ struct stat info_file;
+
+ if(getuid() != 0)
+ err(1, "need root privileges");
while ((ch = getopt(argc, argv, "")) != -1)
switch(ch) {
@@ -63,6 +68,15 @@ main(int argc, char *argv[])
err(1, NULL);
break;
case 1:
+ if(stat(*argv,_file) != 0)
+ if(fopen(*argv,"w"))
+ if(stat(*argv,_file))
+ err(1, "file %s couldn't be created",
*argv);
+
+ if (info_file.st_uid != 0 || info_file.st_gid != 0)
+ if(chown(*argv, 0, 0) != 0)
+ err(1, "Impossible to fix %s ownership", *argv);
+
if (acct(*argv))
err(1, "%s", *argv);
break;
Re: accton(8) requires a reboot after being enabled
Yes, that diff is a whole bunch of TOCTUO. If this was going to be changed, it should be in the kernel. But I don't know if it should be changed yet, which is why I asked a bunch of questions. Stepping back to the man page change, we could decide that accton should continue to behave how it does, and this conversation started because the man page fell into the trap of documenting the rc scripts RATHER than documenting accton.
Re: accton(8) requires a reboot after being enabled
Hi Solene,
Solene Rapenne wrote on Fri, Oct 30, 2020 at 06:34:09PM +0100:
> Following diff changes accton(8) behavior.
>
> If the file given as parameter doesn't exists, accton will create it.
> Then it will check the ownership and will make it root:wheel if
> it's different.
>
> I added a check to be sure it's run as root because it's has no use if
> not run as root.
If it naturally runs into privileged system calls anyway and the
error message is comprehensible, that is not necessarily needed.
Currently, the error message seems OK to me:
$ accton
accton: Operation not permitted
> I don't often write C, if the logic is good but the C implementation
> wrong I'm open to critic.
>
> The -f test and touch in /etc/rc won't be needed anymore with this
> change.
>
>
> Index: accton.8
> ===
> RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v
> retrieving revision 1.11
> diff -u -p -r1.11 accton.8
> --- accton.8 10 Nov 2019 20:51:53 - 1.11
> +++ accton.8 30 Oct 2020 17:27:36 -
> @@ -36,7 +36,7 @@
> .Nm accton
> .Op Ar file
> .Sh DESCRIPTION
> -With an argument naming an existing
> +With an argument naming a
> .Ar file ,
> .Nm
> causes system accounting information for every process executed
*If* we change accton(8) to create the file if it does not exist,
the manual should probably be more explicit and say that an
existing file is appended to, but that it is created if it does
not exist.
Maybe it should even say something like
Unlike other implementations, this version of
.Nm
creates the
.Ar file
if it does not exist.
in order to not set a trap for experienced users.
> Index: accton.c
> ===
> RCS file: /home/reposync/src/usr.sbin/accton/accton.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 accton.c
> --- accton.c 27 Oct 2009 23:59:50 - 1.8
> +++ accton.c 30 Oct 2020 17:26:31 -
> @@ -27,6 +27,7 @@
> * SUCH DAMAGE.
> */
>
> +#include
> #include
> #include
> #include
> @@ -47,6 +48,10 @@ int
> main(int argc, char *argv[])
> {
> int ch;
> + struct stat info_file;
> +
> + if(getuid() != 0)
> + err(1, "need root privileges");
>
> while ((ch = getopt(argc, argv, "")) != -1)
> switch(ch) {
> @@ -63,6 +68,15 @@ main(int argc, char *argv[])
> err(1, NULL);
> break;
> case 1:
> + if(stat(*argv,_file) != 0)
> + if(fopen(*argv,"w"))
Uh oh, that looks like a TOCTOU race condition to me.
> + if(stat(*argv,_file))
And that looks like another TOCTOU race condition.
Checking the return value of fopen(3) might be better.
Leaking a file descriptor from open(2) is also unusual.
Arguably, it may not be a problem here because the program
promptly exits anyway, but is is not nice for auditors.
Finally, what do you need fopen(3) for?
Wouldn't open(2) be sufficient?
> + err(1, "file %s couldn't be created",
> *argv);
> +
> + if (info_file.st_uid != 0 || info_file.st_gid != 0)
> + if(chown(*argv, 0, 0) != 0)
> + err(1, "Impossible to fix %s ownership", *argv);
> +
Isn't that yet another TOCTOU race condition?
I guess using fchown(2) might be more appropriate?
Also, fchmod(2) seems to be lacking, or even better, couldn't that
be covered by the third argument to open(2)?
> if (acct(*argv))
> err(1, "%s", *argv);
Arguably, there might also be a race condition between userland and
the kernel, but i'm not so sure about kernel land. Given how system
calls like open(2) work - taking a path, returning an int to avoid
race conditions - wouldn't it be more natural to have the acct(2)
system call create the file on the kernel side if necessary?
Yours,
Ingo
Re: accton(8) requires a reboot after being enabled
Hi Theo, Theo de Raadt wrote on Fri, Oct 30, 2020 at 09:59:09AM -0600: > With a careful reading of the current manual page, everything is there > and it is accurate. > > With an argument naming an existing file > > > Ok so let's create it with touch. Probably has wrong permissions. > But now accton to that file works. Or enable it and reboot, and now > disable it and reboot, and the file still exists, so now accton works > because it is an existing file (with the right permissions I guess). > > So it *IS* working as documented. It is just a bit weird, because the > accton command (and system call) do not create the file. > > > My problem with these changes is this is the man page for the accton(8) > command, it documents *the binary*. The manpage has already been subverted > talk about rcctl, and about how /etc/rc runs the command. But the man > page should first and foremost be about the command, not about /etc/rc > and rcctl, am i not right? You are right. The paragraph about rc.conf.local(8) is short (one sentence, one line and three half lines) and near the end of the DESCRIPTION, which is appropriate IMHO. It feels more prominent than it should only because the accton(8) command itself is so simple and straightforward that it can be described exhaustively in three lines of text. > For instance, the ntpd manual page has a tiny section about rc.conf. That paragraph has more or less the same length as the one in accton(8). > So in conclusion, I think both of you are writing text about the startup > subsystem, into the wrong manual page. I think both proposals are skewed. > > So questions. > > 1 - historically it requires a file to be pre-created. In the rc scripts, > this is a touch. That grabs the umask and ownership of root's run of > /etc/rc. > 2 - could we do better, in some way? > 3 - accton system call does not have a umask, is that where this design came > from? > 4 - could we improve upon this? > 5 - could accton always (attempt to) create the file, without harming > existing use cases, with proper owner and chmod flags? Maybe. It would change behaviour, though. Somebody might rely on the fact that accton(8) is a NOOP when the file given as an argument does not exist. I'm not saying that is necessarily a good idea, but someone might have done it, for example because they have to maintain a herd of similar machines, want accounting on some but not on others, deploy the same /etc/rc.conf.local to all and create or delete the file as desired. Having the kernel or accton(8) create the file if it does not exist would make the tool slightly easier to use for most users. Is that worth asking users doing soemthing like the above to change their deployment? Maybe, but i'm not sure. The advantages feel small either way. > 6 - or should that be tied to a flag, making it easier to document? I somewhat dislike that. Either we regard creating the file as part of the job. Then accton(8) ought to do it without a flag, and people who don't want accounting should not call it with an argument in the first place. Or we regard creating and deleting the file as a separate decision, like we do it now. Then accton(8) should not meddle with it, not even as a matter of a flag. Besides, creating a root:wheel 0644 file is not rocket science requiring an additional option in some specialized program to be accomplished. For that purpose, several adequate and flexible tools already exist, including install(1). Triggered by looking at this manual page: Let's trim the ridiculous HISTORY section. No, it didn't exist forever. No, the manual page isn't new. A predecessor "gacct(8)" may have existed briefly in v4, but i'm not wholly convinced. There is only a skeleton manual page https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/manx/gacct.8 not even containing a DESCRIPTION. I found no code, and it seems it probably wasn't contained in v5 nor in v6. So it seems best to not mention it. OK? Ingo Index: accton.8 === RCS file: /cvs/src/usr.sbin/accton/accton.8,v retrieving revision 1.11 diff -u -p -r1.11 accton.8 --- accton.810 Nov 2019 20:51:53 - 1.11 +++ accton.830 Oct 2020 16:43:55 - @@ -73,4 +73,5 @@ default accounting file .Sh HISTORY The .Nm -command has existed nearly forever, but this man page is new. +command first appeared in +.At v7 .
Re: accton(8) requires a reboot after being enabled
On Fri, Oct 30, 2020 at 09:59:09AM -0600, Theo de Raadt wrote: > Jason McIntyre wrote: > > > On Fri, Oct 30, 2020 at 04:24:43PM +0100, Solene Rapenne wrote: > > > reading accton(8) it's not clear that if you > > > enable it you need to restart the system for > > > accounting to be effective. > > > > > > Here is a change to add the explanation, but > > > I'm not sure if the wording is correct. > > > > > > > hi. i think the text that follows is really trying to say the same thing > > (you enable it at boot, so until you boot it isn;t enabled). we could > > just try to make that one bit of text a bit clearer: > > > > .Nm > > should be enabled at boot time, either by running > > .Dq rcctl enable accounting > > or by setting > > .Dq accounting=YES > > in > > .Xr rc.conf.local 8 . > > With a careful reading of the current manual page, everything is there > and it is accurate. > > With an argument naming an existing file > > correct. i missed that accton could be started this way, and concentrated on how to start it at boot (which i guess is nromally the way it'll be run). > Ok so let's create it with touch. Probably has wrong permissions. > But now accton to that file works. Or enable it and reboot, and now > disable it and reboot, and the file still exists, so now accton works > because it is an existing file (with the right permissions I guess). > > So it *IS* working as documented. It is just a bit weird, because the > accton command (and system call) do not create the file. > yes, it works as advertised. and all the bits are there - i just thought solene's notes were a repetition on the current boot notes. > > My problem with these changes is this is the man page for the accton(8) > command, it documents *the binary*. The manpage has already been subverted > talk about rcctl, and about how /etc/rc runs the command. But the man > page should first and foremost be about the command, not about /etc/rc > and rcctl, am i not right? For instance, the ntpd manual page has a tiny > section about rc.conf. > the main text body is so slim that the boot notes look bigger in relation. ntpd has more to say. but rerading ntpd(8), i think it discusses the startup process in a better way. maybe we should move to a text more similar to that one/ i think it's still fair game to say how to start a process in its man page. if we don;t want such information, we have a lot of undoing to er, do. > So in conclusion, I think both of you are writing text about the startup > subsystem, into the wrong manual page. I think both proposals are skewed. > > So questions. > > 1 - historically it requires a file to be pre-created. In the rc scripts, > this is a touch. That grabs the umask and ownership of root's run of > /etc/rc. > 2 - could we do better, in some way? > 3 - accton system call does not have a umask, is that where this design came > from? > 4 - could we improve upon this? > 5 - could accton always (attempt to) create the file, without harming existing > use cases, with proper owner and chmod flags? > 6 - or should that be tied to a flag, making it easier to document? > i can;t answer these points. except with more questions: - is it fair game for a process to document how it fits into the startup process? right now, we broadly do that. i think it's fine. - somewhere we switched to telling people how to use rcctl. i never like this system, but it was broadly agreed. so now there are two ways to do things. should the pages describe both? it's hard to see we'd do one without the other. i note that ntpd(8) does not discuss rcctl(8)... jmc > > sth like that? > > jmc > > > > > Index: accton.8 > > > === > > > RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v > > > retrieving revision 1.11 > > > diff -u -p -r1.11 accton.8 > > > --- accton.8 10 Nov 2019 20:51:53 - 1.11 > > > +++ accton.8 30 Oct 2020 15:22:14 - > > > @@ -43,6 +43,10 @@ causes system accounting information for > > > to be placed at the end of the file. > > > If no argument is given, accounting is turned off. > > > .Pp > > > +Accounting is done if it was enabled when system booted. > > > +If you activate accounting, a reboot is required for it to become > > > +effective. > > > +.Pp > > > To have > > > .Nm > > > enabled at boot time, use > > > > > >
Re: accton(8) requires a reboot after being enabled
Jason McIntyre wrote: > On Fri, Oct 30, 2020 at 04:24:43PM +0100, Solene Rapenne wrote: > > reading accton(8) it's not clear that if you > > enable it you need to restart the system for > > accounting to be effective. > > > > Here is a change to add the explanation, but > > I'm not sure if the wording is correct. > > > > hi. i think the text that follows is really trying to say the same thing > (you enable it at boot, so until you boot it isn;t enabled). we could > just try to make that one bit of text a bit clearer: > > .Nm > should be enabled at boot time, either by running > .Dq rcctl enable accounting > or by setting > .Dq accounting=YES > in > .Xr rc.conf.local 8 . With a careful reading of the current manual page, everything is there and it is accurate. With an argument naming an existing file Ok so let's create it with touch. Probably has wrong permissions. But now accton to that file works. Or enable it and reboot, and now disable it and reboot, and the file still exists, so now accton works because it is an existing file (with the right permissions I guess). So it *IS* working as documented. It is just a bit weird, because the accton command (and system call) do not create the file. My problem with these changes is this is the man page for the accton(8) command, it documents *the binary*. The manpage has already been subverted talk about rcctl, and about how /etc/rc runs the command. But the man page should first and foremost be about the command, not about /etc/rc and rcctl, am i not right? For instance, the ntpd manual page has a tiny section about rc.conf. So in conclusion, I think both of you are writing text about the startup subsystem, into the wrong manual page. I think both proposals are skewed. So questions. 1 - historically it requires a file to be pre-created. In the rc scripts, this is a touch. That grabs the umask and ownership of root's run of /etc/rc. 2 - could we do better, in some way? 3 - accton system call does not have a umask, is that where this design came from? 4 - could we improve upon this? 5 - could accton always (attempt to) create the file, without harming existing use cases, with proper owner and chmod flags? 6 - or should that be tied to a flag, making it easier to document? > sth like that? > jmc > > > Index: accton.8 > > === > > RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v > > retrieving revision 1.11 > > diff -u -p -r1.11 accton.8 > > --- accton.810 Nov 2019 20:51:53 - 1.11 > > +++ accton.830 Oct 2020 15:22:14 - > > @@ -43,6 +43,10 @@ causes system accounting information for > > to be placed at the end of the file. > > If no argument is given, accounting is turned off. > > .Pp > > +Accounting is done if it was enabled when system booted. > > +If you activate accounting, a reboot is required for it to become > > +effective. > > +.Pp > > To have > > .Nm > > enabled at boot time, use > > >
Re: accton(8) requires a reboot after being enabled
On Fri, Oct 30, 2020 at 04:24:43PM +0100, Solene Rapenne wrote: > reading accton(8) it's not clear that if you > enable it you need to restart the system for > accounting to be effective. > > Here is a change to add the explanation, but > I'm not sure if the wording is correct. > hi. i think the text that follows is really trying to say the same thing (you enable it at boot, so until you boot it isn;t enabled). we could just try to make that one bit of text a bit clearer: .Nm should be enabled at boot time, either by running .Dq rcctl enable accounting or by setting .Dq accounting=YES in .Xr rc.conf.local 8 . sth like that? jmc > Index: accton.8 > === > RCS file: /home/reposync/src/usr.sbin/accton/accton.8,v > retrieving revision 1.11 > diff -u -p -r1.11 accton.8 > --- accton.8 10 Nov 2019 20:51:53 - 1.11 > +++ accton.8 30 Oct 2020 15:22:14 - > @@ -43,6 +43,10 @@ causes system accounting information for > to be placed at the end of the file. > If no argument is given, accounting is turned off. > .Pp > +Accounting is done if it was enabled when system booted. > +If you activate accounting, a reboot is required for it to become > +effective. > +.Pp > To have > .Nm > enabled at boot time, use >
