Блокировка сервера, / var / log / messages сообщает «Превышен лимит задержек»

9

У нас есть ОС CentOS, которая сегодня утром перестала отвечать на внешний сетевой трафик. Это виртуальная машина. Я смог перезагрузить ВМ. После входа в систему я обнаружил следующее в файле / var / log / messages, повторяя снова и снова вплоть до момента перезагрузки:

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

Я читал на другом форуме, что следующая команда может определить источник трафика невыполненной работы:

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

Event Summary Report
======================
total  type
======================
486  USER_ACCT
486  CRED_ACQ
486  USER_START
485  LOGIN
477  CRED_DISP
477  USER_END
6  USER_LOGIN
3  USER_AUTH
2  CONFIG_CHANGE
2  CRED_REFR
1  DAEMON_START

Может ли кто-нибудь посоветовать мне, какие дальнейшие шаги я должен предпринять для предотвращения повторения этой проблемы? Я не особенно знаком с целью отставания или что означает вывод итогового отчета о событиях.

— YWCA Привет
источник

Можете ли вы исключить проблему хранения? Журналы не записываются, если хранилище недоступно, но ядро продолжает работать - по крайней мере, некоторое время.

— the-wabbit

Хранение является локальным и не показало никаких признаков проблем. Я думаю, что более вероятно, что полезная информация не регистрируется.

— YWCA Привет

5

Вы можете увеличить отставание изменения -b 320в /etc/audit/audit.rulesчем - то большим и посмотреть , если это имеет какой - либо эффект, но эти суммы вы показать нам еще очень мало результатов аудита, поэтому я сомневаюсь , что ошибка аудита имеет ничего особенного делать с системой замораживания сам по себе. Это, вероятно, просто симптом чего-то еще происходящего.

Проверьте, /var/log/audit/audit.logкакие события были зарегистрированы, чтобы увидеть, могут ли они быть полезны для вашей отладки.

— Маттиас Анберг
источник

audit.logпо сути, замолчал около 2 часов, прежде чем мы заметили проблему (это произошло рано утром). Затем сообщения запускались снова с перезагрузкой. Я надеюсь, что это не еще один сценарий замораживания Linux, когда в журналах не найдено никаких реальных ответов: /

— YWCA Здравствуйте,

Обратите внимание, что в системе на основе RHEL7 вам необходимо изменить файл /etc/audit/rules.d/audit.rules, поскольку /etc/audit/audit.rules перезаписывается при перезапуске audd.

— Бруно Майрло

2

Существует несколько решений:

Чтобы удлинить очередь, добавьте или отредактируйте /etc/audit/audit.rules, добавив или отредактировав «-b 320» в «-b 8192».
измените приоритет, отредактировав priority_boost от 3 до 4 или 5 в /etc/audit/auditd.conf.

Чтобы выяснить, какая проблема вызывает эту проблему, запустите aureport --start today или aureport --start today --event --summary -i

— Эсмаил МИРЗАЕЕ
источник