Verrouillage du serveur, / var / log / messages signale «dépassement de la limite de backlog»

9

Nous avons un OS CentOS qui ne répond plus ce matin au trafic réseau externe. C'est une machine virtuelle. J'ai pu redémarrer la machine virtuelle. Après m'être reconnecté, j'ai trouvé ce qui suit dans le fichier / var / log / messages, se répétant encore et encore, jusqu'au point de redémarrage:

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

J'ai lu sur un autre forum que la commande suivante pouvait identifier la source du trafic de backlog:

[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

Quelqu'un peut-il me conseiller sur les prochaines étapes à suivre pour éviter que ce problème ne se reproduise? Je ne connais pas particulièrement le but de l'arriéré ni ce que signifie la sortie du rapport de synthèse d'événement.

linux centos windows-event-log audit Bonjour YWCA
la source
Pouvez-vous exclure un problème de stockage? Les journaux ne sont pas écrits si le stockage est inaccessible, mais le noyau continue de fonctionner - au moins pendant un certain temps.
the-wabbit
Le stockage est local et n'a montré aucun signe de problème. Je pense qu'il est plus probable que les informations utiles ne soient pas enregistrées.
YWCA Bonjour

Réponses:

5

Vous pouvez augmenter l'arriéré en modifiant -b 320dans /etc/audit/audit.rulesquelque chose plus grand et voir si elle a un effet, mais ceux - ci les montants que vous nous montrer encore très peu de résultats d'audit, donc je doute l'erreur de vérification a grand chose à voir avec le système de congélation en lui - même. C'est probablement juste le symptôme de quelque chose d'autre qui se passe.

Vérifiez /var/log/audit/audit.logquels événements ont été enregistrés pour voir s'ils peuvent être utiles à votre débogage.

Mattias Ahnberg
la source
audit.logs'est essentiellement calmé environ 2 heures avant de remarquer le problème (cela s'est produit tôt le matin). Ensuite, les messages ont redémarré avec le redémarrage. J'espère que ce n'est pas un autre scénario de gel de Linux où aucune vraie réponse n'est trouvée dans les journaux: /
YWCA Bonjour
Notez que sur un système basé sur RHEL7, vous devez modifier le fichier /etc/audit/rules.d/audit.rules car le /etc/audit/audit.rules est réécrit au redémarrage de auditd.
Bruno Mairlot
2

Il existe plusieurs solutions:

  1. Pour allonger l'arriéré, ajoutez ou modifiez /etc/audit/audit.rulesen ajoutant ou en modifiant "-b 320" à "-b 8192".
  2. changez la priorité en éditant priority_boost de 3 à 4 ou 5 pouces /etc/audit/auditd.conf.

Pour savoir quel problème est à l'origine de ce problème, exécutez aureport --start today ou aureport --start today --event --summary -i

Esmaeil MIRZAEE
la source