I am at a loss in explaining how this could have happened. As you show above, the init script says to be on in runlevels 2345. The initscript is identical to the initscript used in Fedora and no one has reported this problems there. The spec file only adds or deletes the initscript and does not mess with an individual run level. So...I don't know how this would happen.

I installed Scientific Linux 6.1 some days ago and hit this bug.
I try to reproduce it with kvm.

I create a new kvm virtual host with virt-manager (here with Scientific Linux 6.1) and keep all the default values except :
- Memory (RAM) : 1024 MB (this trigger a graphical installation)
- OS type : Linux
- Version : Red Hat Enterprise Linux 6
- Use ISO image : http://mirrors.ircam.fr/pub/scientificlinux/scientific/6.1/x86_64/os/images/boot.iso

Install and keep all the default values as much as possible.
When the installation method is request, enter :
- URL
- URL containing the installation image : http://mirrors.ircam.fr/pub/scientificlinux/scientific/6.1/x86_64/os

By any chance, do you have the readahead service enabled? It disables the audit system so it can see file access on startup.

Created attachment 518398 [details]
/var/lib/readahead/custom.early at the first boot

/var/lib/readahead/custom.early at the first boot (network install, Desktop installation).

Created attachment 518399 [details]
/var/lib/readahead/early.sorted at the first boot

/var/lib/readahead/early.sorted at the first boot (network install, Desktop installation).

Hope it's what you want, see attachements 518398 ans 518399.

After the installation and before the first boot, auditd is enabled at run level 5. At the end of the first boot this is not more the case.

I tested the installation "minimal" and "web server", auditd is enabled.

If you have readahead installed and you care about auditing, remove the readahead package. You won't be able to get bootup events with it installed and working properly, and you might have audit disabled if it doesn't work properly.

I confirm that readahead was installed.
Thank you, Steve.

(In reply to comment #8)
> If you have readahead installed and you care about auditing, remove the
> readahead package. You won't be able to get bootup events with it installed and
> working properly, and you might have audit disabled if it doesn't work
> properly.

Ok, I check the package readahead, it temporally disable auditd if /.readahead-collect exist. It's not a "brilliant" job (but I am not a developer and I don't understand all the subtleties of Linux.).

If firstboot is launched and you reboot the computer without filling firstboot (switch to other console for example and "reboot" because you are waiting for some informations), auditd is deactivated for the current run level. If there is a power failure during the boot sequence and readahead-collector is doing its job, auditd is deactivated, and so on. normal ? Why providing readahead and auditd in the *defaut* installation (activated by default) if they can't work together ? Readahead can deactivate auditd, setroubleshoot should deactivate readahead if you install it (setroubleshoot depend on auditd).

For me readahead should not change the configuration if he is not able to restore the configuration in case of failure. But it's the (flaw) design of readahead. Bug or not ? Not a bug of audit anyway.



Ignore my tests with a virtual host because I was checking the configuration of auditd with firstboot running.

Transferring this to readahead component to see if this could be made more robust. I almost think audit and readahead should conflict, but I suppose it all depends on what the chkconfig settings are.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

(In reply to comment #11)
> Transferring this to readahead component to see if this could be made more
> robust. I almost think audit and readahead should conflict, but I suppose it
> all depends on what the chkconfig settings are.

right, if readahead is enabled and the collect job is running, it delays auditd startup by temporarily disabling auditd, and enabling and starting it afterwards.

In Fedora, readahead is obsoleted by systemd-readahead, which uses the new fanotify mechanism.

I will look into making it more robust against power failures and such.

(In reply to comment #15)
> I will look into making it more robust against power failures and such.

A proposal.
Change also the init scripts of auditd and don't touch /etc/rc.d/ symbolic links.
Don't forget I am not a developer !


readahead-collector
star :
  touch /var/lock/subsys/readahead-auditd
stop :
  rm /var/lock/subsys/readahead-auditd


auditd
star :
  if /var/lock/subsys/auditd then exit
  touch /var/lock/subsys/auditd
  if /var/lock/subsys/readahead-auditd exist then
    call wait_for_readahead_background()
    exit
  endif
  as usual

stop :
  as usual (rm /var/lock/subsys/auditd)

status :
  if /var/lock/subsys/readahead-auditd then
    echo "waiting for readahead"
  else
    as usual
  endif

wait_for_readahead_in_background() {
  wait_for /var/lock/subsys/readahead-auditd
  if not /var/lock/subsys/auditd then exit
  rm /var/lock/subsys/auditd
  /sbin/service auditd start
}


Not perfect, but this should support a power failure and this doesn't touch de configuration.

Same problem here, but in runlevel 3 (my default). This sums it up:

Good:

Jul 27 15:56:37 trinity kernel: readahead-collector: starting
Jul 27 15:56:37 trinity kernel: readahead-disable-service: delaying service auditd
Jul 27 15:59:39 trinity kernel: readahead-collector: starting delayed service auditd 3
Jul 27 15:59:40 trinity kernel: readahead-collector: sorting
Jul 27 15:59:43 trinity kernel: readahead-collector: finished

Bad:

Jul 27 05:53:47 trinity kernel: readahead-collector: starting
Jul 27 05:53:47 trinity kernel: readahead-disable-service: delaying service auditd
Jul 27 05:54:26 trinity kernel: readahead-collector: sorting
Jul 27 05:54:27 trinity kernel: readahead-collector: finished

This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6, and will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.