# service auditd start
Starting auditd:                                           [FAILED]


# /etc/init.d/auditd start
Starting auditd:                                           [FAILED]

And frustatingly - works:

# bash /etc/init.d/auditd start
Starting auditd:                                           [  OK  ]

I've added something like echo 1 echo 2 in various place in bash /etc/init.d/auditd, so see what path the script takes, to no avail.

The command that is eventually run, and fails is

env -i PATH=/sbin:/usr/sbin:/bin:/usr/bin TERM=xterm /etc/init.d/auditd start

Why does adding bash make it work? Looking for troubleshooting ideas.

Based on Michaels suggestion to use run_init, I could get some meaningful debug out of bash:

# run_init bash -x /etc/init.d/auditd start
+ /bin/bash -c 'ulimit -S -c 0 >/dev/null 2>&1 ; auditd '
+ '[' 6 -eq 0 ']'
+ failure 'auditd startup'

In /var/log/messages I have

Dec  8 14:54:06 aws-sonar-01 kernel: type=1100 audit(1418050446.762:250): user pid=7196 uid=0 auid=500 ses=6 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="user" exe="/usr/sbin/run_init" hostname=? addr=? terminal=pts/0 res=success'
Dec  8 14:54:06 aws-sonar-01 kernel: type=1101 audit(1418050446.777:251): user pid=7196 uid=0 auid=500 ses=6 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="user" exe="/usr/sbin/run_init" hostname=? addr=? terminal=pts/0 res=success'
Dec  8 14:54:06 aws-sonar-01 kernel: type=1400 audit(1418050446.795:252): avc:  denied  { read } for  pid=7200 comm="auditd" name="audit" dev=xvda1 ino=393285 scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=lnk_file
Dec  8 14:54:06 aws-sonar-01 kernel: type=1300 audit(1418050446.795:252): arch=c000003e syscall=2 success=no exit=-13 a0=7fa0660a42a0 a1=90800 a2=4000 a3=19 items=0 ppid=7196 pid=7200 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=6 comm="auditd" exe="/sbin/auditd" subj=system_u:system_r:auditd_t:s0 key=(null)
Dec  8 14:54:06 aws-sonar-01 auditd: Could not open dir /var/log/audit (Permission denied)
Dec  8 14:54:06 aws-sonar-01 auditd: The audit daemon is exiting.

I've tried to generate a policy using above as input

cat messages_above | grep awc | audit2allow -M audit
semodule -i audit.pp

Had a go at selinux policy creation - is this correct? Or missing anything?

semanage permissive -a auditd_t
service auditd start
tail -n 20 messages  |grep auditd | audit2allow -M auditd
semodule -i auditd.pp
semanage permissive -d auditd_t

Still same problem

  • Two questions. Is root's shell bash? And, what does the shebang at the head of the auditd init script look like? – JasonAzze Dec 5 '14 at 12:11
  • top of auditd is #!/bin/bash. root's shell is bash. It turned out to be selinux. I ran this semanage permissive -a auditd_t and now auditd starts. Have I opened up anything I might regret later? – Jepper Dec 5 '14 at 12:26
  • You've probably messed up the context under which auditd runs, or the context of the log files it writes. – Michael Hampton Dec 5 '14 at 16:03
  • Did you really update your system and run restorecon as I previously advised you? It appears that you have not. – Michael Hampton Dec 8 '14 at 15:33
  • Yes. I've rebuilt the instance, but without the puppet module that configured auditd earlier. It's using an AMI that is yum update'd today, but I yum update'd again to be sure. Only two packages were updated. I also ran restorecon -r -v / , rebooted, and it still fails. – Jepper Dec 8 '14 at 16:13

On EL (prior to 7) start services on an SELinux-enabled system with run_init to ensure that SELinux contexts and domain transitions are correct.

run_init service auditd start

Or just enable them to start at boot time, which is preferred.

Your log entries indicate that /var/log/audit has the wrong security context. To resolve this:

  1. Update your system. There are new SELinux policy packages which contain many fixes, as well as other updates you are behind on.
  2. Run restorecon -r -v /var/log/audit to fix the security contexts, or better, restorecon -r -v / to relabel the entire system (which fixes a lot of other potential issues as well).
  • That doesn't work. It's enabled auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off but it doesn't run at boot time. – Jepper Dec 8 '14 at 11:57
  • 1
    @Jepper You've probably messed up some security contexts, as I mentioned before. First, update your system. Then fix the labels for everything: restorecon -r -v / Then reboot. – Michael Hampton Dec 8 '14 at 11:59
  • Ok done that. It gets weirder. I've sudu -i then, - [root@system01 ~]# run_init service auditd start \n Authenticating myuser. \n Password: – Jepper Dec 8 '14 at 12:17
  • Well, you could always just authenticate. – Michael Hampton Dec 8 '14 at 12:30
  • I'm root when I run run_init. Regardless, if I tap in my password for myuser, Starting auditd: [FAILED] – Jepper Dec 8 '14 at 12:56
  • invalid options in /etc/init.d/auditd.conf will cause it to fail
  • type ausearch -m DEAMON_END to get which line is in error
  • That should be DAEMON_END, probably. Regardless, running /sbin/ausearch ... solved my problem without finding any auditd.conf issues: it reported right away that "audit.log is not writable by owner". Sure enough, auditd was refusing to start because /var/log/audit/audit.log was read-only. – Urhixidur Nov 23 '17 at 20:11

Check the permissions of the /var/log/audit directory. On some distributions they look to be as follows:

0 drw-------.  2 root root     29 Apr 21 13:19 audit

Notice the directory is not executable! A simple

sudo chmod u+x /var/log/audit

Fixed this issue for me

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.