Bug 683456

Summary: Audit daemon hangs up on system shutdown
Product: Red Hat Enterprise Linux 6 Reporter: Michal Kosciowski <michal.kosciowski>
Component: auditAssignee: Steve Grubb <sgrubb>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1CC: ed.ciechanowski, eparis, krzysztof.wojcik
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-28 18:24:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Syslog with error of auditd none

Description Michal Kosciowski 2011-03-09 13:12:53 UTC
Created attachment 483208 [details]
Syslog with error of auditd

Description of problem:Auditd is sleeping forever on system shutdown, or reboot. Hanged up daemon is freezing machine shutdown process.

In syslog there is information:
Feb 10 01:23:33 localhost auditd[1410]: Error receiving audit netlink packet (No buffer space available)
Feb 10 01:23:33 localhost auditd[1410]: Error sending signal_info request (No buffer space available)
Feb 10 01:23:33 localhost auditd[1410]: The audit daemon is exiting.

Version-Release number of selected component (if applicable):
audit-2.0.6-1.el6.x86_64


How reproducible:
Almost always


Steps to Reproduce:
1. Install system
2. switch it off by shutdown -h now, or shutdown -r now, or reboot...
3. Auditd will fail to stop and will freeze shutdown process
  
Actual results: Auditd fails to stop


Expected results: Auditd is stoping properly.


Additional info:

Comment 2 Steve Grubb 2011-03-09 13:23:41 UTC
What audit rules do you have loaded? It sounds like on shutdown lots of events
were created that flooded the audit system.

Comment 3 Michal Kosciowski 2011-03-09 13:39:55 UTC
Nothing special. It was fresh install of Red Hat 6.1 without any changes.

Comment 4 Steve Grubb 2011-03-09 13:54:29 UTC
What kind of events did you get around shutdown? You can run 
aureport --start 08:00:00 
assuming you started shutdown around that time. The same audit package is on Fedora 14 and we have no reports of this issue. The shutdown code is also the same as shipped in RHEL6 GA. So, there is something going on with your system that we need to better understand.

Comment 5 Michal Kosciowski 2011-03-09 14:23:11 UTC
I'll give you answer on friday or monday.

Comment 6 Michal Kosciowski 2011-03-14 11:16:02 UTC
Output from aureport:
Summary Report
======================
Range of time in logs: 03/13/2011 20:07:21.325 - 03/13/2011 20:14:14.138
Selected time for report: 03/13/2011 12:09:00 - 03/13/2011 20:14:14.138
Number of changes in configuration: 2
Number of changes to accounts, groups, or roles: 0
Number of logins: 3
Number of failed logins: 0
Number of authentications: 4
Number of failed authentications: 0
Number of users: 2
Number of terminals: 7
Number of host names: 3
Number of executables: 4
Number of files: 0
Number of AVC's: 0
Number of MAC events: 4
Number of failed syscalls: 0
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 7
Number of keys: 0
Number of process IDs: 11
Number of events: 68314

Comment 7 Steve Grubb 2011-03-14 12:09:30 UTC
That is showing more than 68,000 events in 7 minutes. That is not normal. Maybe try this and see what kind of events are being triggered (you supply the same time range as the above report):

aureport --event --summary -i

Comment 8 Michal Kosciowski 2011-03-14 12:26:37 UTC
I got:
Event Summary Report
======================
total  type
======================
65604  USER_END
5  CRYPTO_KEY_USER
3  USER_START
2  USER_ROLE_CHANGE
2  LOGIN
2  USER_AUTH
2  USER_ACCT
2  CRED_ACQ
2  CRYPTO_SESSION
1  CRED_REFR
1  USER_LOGIN
1  CRED_DISP


So i see that user_end event may cause this issue..
But this is new install, and i was logged into it twice.

Comment 9 Steve Grubb 2011-03-14 12:43:11 UTC
OK, looks like we have a candidate. I want to make sure we know which program is doing this. I would suspect sshd, but we need to check:

ausearch --start <add you time range here> -m user_end --raw | aureport  -x --summary

Comment 10 Michal Kosciowski 2011-03-14 12:51:14 UTC
Yes. It is sshd.

Comment 11 Michal Kosciowski 2011-03-14 12:53:33 UTC
Executable Summary Report
=================================
total  file
=================================
71415  /usr/sbin/sshd
2  /usr/sbin/crond

Comment 12 Steve Grubb 2011-03-14 13:18:21 UTC
This problem seems to be a duplicate of bug 680722. It is supposed to be fixed in version 5.3-41. So, updating to it or later should resolve the problem. Thanks.

Comment 13 Steve Grubb 2011-03-28 18:24:31 UTC

*** This bug has been marked as a duplicate of bug 680722 ***