Bug 1318043 - auditd.service: main process exited, code=exited, status=6/NOTCONFIGURED
Summary: auditd.service: main process exited, code=exited, status=6/NOTCONFIGURED
Alias: None
Product: Fedora
Classification: Fedora
Component: audit
Version: 22
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Steve Grubb
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-03-15 20:18 UTC by Flo H.
Modified: 2016-03-18 15:38 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1151794
Last Closed: 2016-03-18 15:38:41 UTC
Type: Bug

Attachments (Terms of Use)
auditd.conf (702 bytes, text/plain)
2016-03-16 14:07 UTC, Flo H.
no flags Details

Description Flo H. 2016-03-15 20:18:46 UTC
This is on up-to-date Fedora22 (Gnome), kernel 4.4.4-200.fc22.x86_64.

$ systemctl status auditd.service
● auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2016-03-15 14:35:20 EDT; 33min ago
  Process: 1076 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS)
  Process: 1075 ExecStart=/sbin/auditd -n (code=exited, status=6)
 Main PID: 1075 (code=exited, status=6)

systemd[1]: Starting Security Auditing Service...
auditctl[1076]: No rules
systemd[1]: Started Security Auditing Service.
auditd[1075]: Could not open dir /var/log/audit (No such file or directory)
auditd[1075]: The audit daemon is exiting.
systemd[1]: auditd.service: main process exited, code=exited, status=6/NOTCONFIGURED
systemd[1]: Unit auditd.service entered failed state.

$ sudo /sbin/auditd -f
Config file /etc/audit/auditd.conf opened for parsing
log_file_parser called with: /var/log/audit/audit.log
Could not open dir /var/log/audit (No such file or directory)
The audit daemon is exiting.

$ sudo cat /etc/audit/audit.rules #(removed all comments):
-a task, never

Comment 1 Flo H. 2016-03-15 20:19:44 UTC
Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1151794

Comment 2 Steve Grubb 2016-03-15 21:39:06 UTC
The issue is that the logging directory is not available. This can't be an audit bug. Audit is packaged owning the directory so rpm should create it during installation. Can you confirm that the directory is missing when you log in?

Comment 3 Flo H. 2016-03-16 01:37:15 UTC
Oh yea, forgot to mention it:

 /var/log/audit does not exist.

Should I just create it? Who should be the owner? Root?

Comment 4 Flo H. 2016-03-16 01:41:02 UTC
If I do so (su -c "mkdir /var/log/audit"), it seems that auditd performs well. See output below.

$ sudo /sbin/auditd -f
Config file /etc/audit/auditd.conf opened for parsing
log_file_parser called with: /var/log/audit/audit.log
log_format_parser called with: RAW
log_group_parser called with: root
priority_boost_parser called with: 4
flush_parser called with: INCREMENTAL
freq_parser called with: 20
num_logs_parser called with: 5
qos_parser called with: lossy
dispatch_parser called with: /sbin/audispd
name_format_parser called with: NONE
max_log_size_parser called with: 6
max_log_size_action_parser called with: ROTATE
space_left_parser called with: 75
space_action_parser called with: SYSLOG
action_mail_acct_parser called with: root
admin_space_left_parser called with: 50
admin_space_left_action_parser called with: SUSPEND
disk_full_action_parser called with: SUSPEND
disk_error_action_parser called with: SUSPEND
tcp_listen_queue_parser called with: 5
tcp_max_per_addr_parser called with: 1
tcp_client_max_idle_parser called with: 0
enable_krb5_parser called with: no
krb5_principal_parser called with: auditd
Started dispatcher: /sbin/audispd pid: 5086
type=DAEMON_START msg=audit(1458092291.687:8262): auditd start, ver=2.4.5 format=raw kernel=4.4.4-200.fc22.x86_64 auid=1000 pid=5084 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=success
config_manager init complete
Init complete, auditd 2.4.5 listening for events (startup state enable)
type=SERVICE_STOP msg=audit(1458092320.634:688): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Comment 5 Flo H. 2016-03-16 13:57:21 UTC
OK, I created  /var/log/audit and I can see an (empty) audit.log in there.

The service still fails - I am afraid I didnt' set the rights correctly. Both directory audit and file audit.log are owned by root (group root).

What would be the correct setting?

Comment 6 Flo H. 2016-03-16 14:07:53 UTC
Created attachment 1137055 [details]

Comment 7 Steve Grubb 2016-03-16 14:11:45 UTC
The audit package has the directory packaged up. It knows the permissions:

$ rpm -qvl audit | grep var
drwxr-x---    2 root    root                  0 Mar 14 12:24 /var/log/audit

Hth...no idea why the directory winds up missing.

Comment 8 Flo H. 2016-03-16 14:33:56 UTC
Thanks for your quick reply.
Does it make sense trying a dnf reinstall audit and see if that would fix the problem?

Comment 9 Steve Grubb 2016-03-16 14:38:02 UTC
Sure, you can try that. But chmod 750 and chown root:root should fix it.

Comment 10 Flo H. 2016-03-16 15:23:39 UTC
Adjusted directory permissions but still getting an error. audit.log can't be created.

● auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mi 2016-03-16 11:13:27 EDT; 1min 8s ago
  Process: 1080 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS)
  Process: 1079 ExecStart=/sbin/auditd -n (code=exited, status=6)
 Main PID: 1079 (code=exited, status=6)

auditd[1079]: Unable to create /var/log/audit/audit.log (Permission denied)

$ ls-l
drwxr-x---. 2 root   root       4096 16. Mär 10:45 audit

Comment 11 Flo H. 2016-03-16 15:30:40 UTC
I ran 
dnf reinstall audit
and suddenly I do have an audit.log with content.

systemctl status auditd.service reports "active (running)" and 
aureport outputs a nice summary. 

Permissions of /var/log/audit are the same as before. Everything seems to be fine now but I don't understand what happened.

Comment 12 Steve Grubb 2016-03-16 15:35:14 UTC
It might have needed a restorecon /var/log/audit/

Comment 13 Neil 2016-03-16 16:37:00 UTC
Some tutorials, or even software to clean up, can remove every log in /var/log/*.
I remember having this bug because of that.

I'll let this comment just in case somebody is experimenting with bleachbit, or doing some rm -rf /anything without knowing and having this bug as result.

Comment 14 Steve Grubb 2016-03-18 15:38:41 UTC
Closing this bug report...reopen if necessary,

Note You need to log in before you can comment on or make changes to this bug.