Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a CentOS OS that became unresponsive this morning to external network traffic. It is a virtual machine. I was able to reboot the VM. After logging back in, I found the following in the /var/log/messages file, repeating over and over, up to the point of the reboot:

Jan 21 06:53:01 PBX kernel: audit: backlog limit exceeded
Jan 21 06:53:01 PBX kernel: audit: audit_backlog=321 > audit_backlog_limit=320
Jan 21 06:54:01 PBX kernel: printk: 8 messages suppressed.
Jan 21 06:54:01 PBX kernel: audit: audit_backlog=321 > audit_backlog_limit=320
Jan 21 06:54:01 PBX kernel: audit: audit_lost=1130 audit_rate_limit=0 audit_backlog_limit=320

I read on another forum that the following command could identify the source of the backlog traffic:

[root@PBX log]# aureport --start today --event --summary -i

Event Summary Report
total  type
485  LOGIN

Can anyone advise me as to what next steps I should take in preventing this issue from happening again? I'm not particularly familiar with the purpose of the backlog or what the output of the event summary report means.

share|improve this question
Can you rule out a storage problem? Logs are not written if the storage is inaccessible, but the kernel remains running - at least for a while. – the-wabbit Jan 23 '12 at 1:22
Storage is local and hasn't showed any signs of trouble. I think it's more likely that useful info is not being logged. – YWCA Hello Jan 26 '12 at 5:24

You can increase the backlog by modifying -b 320 in /etc/audit/audit.rules to something larger and see if it has any effect, but these amounts you show us still very few audit results, so I doubt the audit error has anything much to do with the system freezing in itself. Its probably just a sympthom of something else happening.

Check /var/log/audit/audit.log to see what events have been logged to see if they can be of any use to your debugging.

share|improve this answer
audit.log essentially went quiet about 2 hours before we noticed the problem (this happened in the early morning). Then, messages started up again with the reboot. I'm hoping this isn't another linux freeze scenario where no real answers are found from the logs :/ – YWCA Hello Jan 21 '12 at 19:00
Note that on RHEL7-based system, you need to change the file /etc/audit/rules.d/audit.rules because the /etc/audit/audit.rules gets rewritten at restart of auditd. – Bruno Mairlot Jun 10 '15 at 8:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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