SUMMARY: How to turn process accounting off...

From: Ken Mayer (ken@visix.com)
Date: Fri Mar 27 1992 - 19:36:02 CST


QUERY

    I am running SunOS 4.1 on a Sun 3/60.

    I have accounting turned on for security reasons. Unfortunately, the
    pacct file is in /var/adm which is on the root partition. Every now
    and again, pacct grows to +2Meg in size. I am running ckpacct every
    hour, but for some reason it isn't keeping pacct small as it should,
    nor is it turning off accounting through turnacct. (I already fixed a
    bug in the script where it thought pacct is in /usr/adm.)

    Question 1: Can I maintain login accounting, line usage, & reboot logs
    without process level accounting? I am guessing that its 'turnacct
    off' but I'd like confirmation.

    Question 2: Is there something wrong with the SunOS 4.1 accounting
    scripts, if so, are there patches to fix it?

    Question 3: Can I get process accounting to dump pacct to the /usr
    partition insteat of root.

    Your help is greatly appreciated.

    Ken

SUMMARY

    - Move /var to another partition (something with more space)

    - There is a symbolic link from /usr/adm to /var/adm, that needs
      to track /var/adm

    - Some programs look for /var/foo, need to create symbolic link for
      /var too

    - Change the file name argument to accton inside the turnacct
      script

    - Run /usr/lib/acct/turnacct off to disable process accounting

    - Fix the bug in ckpacct (see below)

    - Manual pages: acct(8), acctsh(8)

REPLIES

From: jims@sunwgtn.NewZealand.Sun.COM (Jim Shaw - IRD Project)

> -->On Fri, 27 Mar 92 10:24:15 NZS, jims@sunwgtn.NewZealand.Sun.COM (Jim Shaw - IRD Project) said:
>
>
> Jim> In general its a good idea to have /var set up as a sym-link to
> Jim> somewhere with plenty of space as many things write log file to /var/adm
> Jim> with the problems of filling / as a result.
>
> Jim> Accounting is turned on in /etc/rc or /etc/rc.local and can be disabled
> Jim> there ( by commenting out the line /usr/lib/acct/startup ). Accounting
> Jim> will normally stop if its directory gets too full.
>
> Jim> Jim
>
> Isn't that dangerous though? What happens if only the root partition
> gets mounted (i.e. single user mode, something's broken etc.) If the
> /usr partition isn't available, won't programs like syslogd break?
>
> Ken
>

Well in single user mode there is not much going on so very little can break.

The main problem that I have had is when I want to edit files and vi
complains about no /var/tmp and quits.
In fact most things like syslogd are in /usr/etc so if usr is not mounted
they cannot be running anyway.

From: guy@auspex.com (Guy Harris)

> pacct file is in /var/adm which is on the root partition. Every now
> and again, pacct grows to +2Meg in size. I am running ckpacct every
> hour, but for some reason it isn't keeping pacct small as it should,

SunOS already has the BSD hack that turns process accounting off
instantaneously if there's less than 2% free space on the file system on
which the accounting file resides, and turns it back on again when
there's more than 4% free space.

> nor is it turning off accounting through turnacct.

You might want to try running it by hand; it uses "turnacct" both to
"keep it small" (meaning "switch to a brand-new accounting file when it
gets too big") and to turn accounting off when there's not enough disk
space (although its criterion is absolute - 500 free blocks - rather
than relative as is the kernel's criterion).

> (I already fixed a bug in the script where it thought pacct is in
> /usr/adm.)

"/var/adm", actually, if "the script" refers to "ckpacct"; "turnacct"
thinks it's in "/usr/adm". Then again, "/usr/adm" is, as distributed by
Sun, just a symlink to "/var/adm"....

> Question 1: Can I maintain login accounting, line usage, & reboot logs
> without process level accounting? I am guessing that its 'turnacct
> off' but I'd like confirmation.

Actually, it'd just be commenting out the "turnacct on" in
"/usr/lib/acct/startup". In theory, it should work; you might have to
make a zero-length "/var/adm/pacct" file to keep the nightly accounting
glop handy, but if it's zero-length I expect it should just report that
"nothing happened" in the way of commands being run.

> Question 2: Is there something wrong with the SunOS 4.1 accounting
> scripts, if so, are there patches to fix it?

There are probably some things wrong with it - there's probably at least
one bug in every non-trivial piece of software, and the System V
accounting stuff is definitely non-trivial.

One bug in "ckpacct" is that it does a "df" on "/usr", rather than on
".". This means that it *assumes* that "pacct" already *is* on "/usr",
which it probably isn't.

> Question 3: Can I get process accounting to dump pacct to the /usr
> partition insteat of root.

You can get it to dump it to any file system you choose, ultimately.

Many people make "/var" a file system *by itself*; the "/var" directory
was intended to hold stuff that:

        1) wouldn't be shared by many machines (unlike, say, "/usr",
           which has a bunch of binaries that might be shared by many
           diskless clients, and possibly by the clients' server as well,
           if it's running the same OS and has the same instruction set
           as the clients)

and

        2) could take up a lot of disk space, e.g. system message files
           ("/var/adm/messages", "/var/log/syslog"), users' mailboxes
           ("/var/spool/mail"), system crash dumps ("/var/crash"), large
           temporary files ("/var/tmp"), NIS databases ("/var/yp"), and
           accounting files.

If that doesn't appeal to you, you could, for example, make "/usr/adm" a
directory and make "/var/adm" a symbolic link to it, rather than having
"/var/adm" be a directory and "/usr/adm" a symbolic link to it.

Thanks to:

From: jims@sunwgtn.NewZealand.Sun.COM (Jim Shaw - IRD Project)
From: middleto@poincare.ucsd.edu (Tom Middleton )
From: Stephen W. Fulling <fulling@storm.CS.ORST.EDU>
From: guy@auspex.com (Guy Harris)



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:40 CDT