A.P. Lawrence

Best of the Newsgroups: dlvr_audit processes cron

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@sco.com>
Subject: Re: My cron is crazy
Date: Tue, 4 May 2004 20:55:41 GMT Message-ID: <20040504205541.GD10272@sco.com> References: <4097C3BE.9060504@cricsa.com>

MichelK wrote:

> Compaq box Proliant 1600 +Openserver 5.05 +EFS5.21 +rs505a since end 
> 1998, no physical change.
> 2 month ago I realized cron was "out". especialy nomore backup 
> (shellscript using cpio in cron)
> there was a lot of /etc/cron processes running when I typed "ps -elf"
> futhermore I noticed many dlvr_audit foreach cron process.
> 
> I never activated audit subsystem.
> I didn't find any special thing in /usr/adm/messages nor /usr/adm/syslog
> 
> then I have installed:
> oss459b
> oss497c
> oss600a
> oss642a
> oss644b
> 
> And rebooted the SCO.
> 
> Manually cpio works fine, and during first month cron was OK, backup too.
> 
> Today I am surprised finding the same cron process multiplication in ps 
> output.(a total of 326 processes when adding /etc/cron and dlvr_audit).
> 
> What can I do ?

This problem is caused by the file /tcb/files/audit/audit_dmninfo.  This
file is automatically created at boot time.  It should only exist if you
are using kernel auditing (which you say you are not), but some systems
mistakenly create it anyway.

When the file is absent, `dlvr_audit` exits early without doing much of
anything.  When it is present, it attempts to write auditing messages
down a message queue.  Nothing is reading that message queue, which is
why your system is full of stuck `dlvr_audit` processes.

To repair the system without rebooting again: first remove the file
/tcb/files/audit/audit_dmninfo; second, kill all processes running
`dlvr_audit`.

Before you do this, however, there is a consequence that you should be
aware of.  Your system is filled with `cron` children which have been
forked to run various tasks, but got stuck waiting for `dlvr_audit` to
complete.  If you kill the `dlvr_audit` processes, each of those `cron`
processes will wake up and continue with what it was originally trying
to do.  In effect, you will have a sudden "storm" of old cron jobs all
waking up and doing their tasks.

You know better than we do what sort of cron jobs you're running.  It
may be that there would be no problem.  It may be that it would cause a
huge mess.  (You mention backups -- if the backup script does not have a
mechanism for preventing itself from doing two backups at once, that
would be a huge mess...)

A `proctree -a cron` on your system probably looks something like this:

  UID        PID TTY  ARGS
  root         1 ?    /etc/init -a
  \>root       214 ?    /etc/cron
    }>root      6344 ?    /etc/cron
    | \>root      6345 ?    dlvr_audit
    }>root      6456 ?    /etc/cron
    | \>root      6457 ?    dlvr_audit
    .
    .
    .
    \>root      9998 ?    /etc/cron
      \>root      9999 ?    dlvr_audit

(ftp://ftp.armory.com/pub/scripts/proctree)

If you killed processes 6345, 6457 and 9999, then the cron jobs under
processes 6344, 6456 and 9998 would continue.  You may not want to do
that.  You may want to _first_ kill the child `cron` processes 6344,
6456 and 9998; _then_ kill the child `dlvr_audit` processes 6345, 6457
and 9999.

Alternatively, you could reboot.  After rebooting, verify that
/tcb/files/audit/audit_dmninfo has not reappeared; delete it if it has.

>Bela<