Bonjour à tous, aujourd’hui je voulais vous partager une erreur que j’ai rencontrée récemment avec une infra Splunk, plus exactement avec la couche de collecte Rsyslog (vous savez celle que je recommande dans mon podcast sur les 10 commandements du SIEM). Cette erreur qu’on a fini par identifier dans les journaux avec le message suivant « rsyslog too many open files » et plus précisément la ligne suivante :
May 06 05:47:13 myserver rsyslogd[6896]: file '/splunk-inputs/PROXY/myproxyhost/2022-05-06T03+02-PROD-PROXY.log': open error: Too many open files [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2433 ]
Le log d’erreur arrive dans /var/log/message à priori. Néanmoins, de mon côté on ne l’a vu que depuis la commande journalctl, quelques exemples qui m’ont permis de la mettre en avant :
journalctl --no-pager | tail -f journalctl -u rsyslog journalctl --no-pager > /tmp/rsyslogtmp.log
Par défaut, la limite pour rsyslog était à 1024 fichiers ouverts simultanément sur notre système. Pas bien clair sur le pourquoi car les limites systèmes (cf. fichier /etc/security/limits.conf) été bien à 64000 :
ulimit -Sn
64000
Pour autant notre processus rsyslog plafonné à 1024 fichiers. Ce qui causait une erreur bien zarb où on perdait 15min de log au début de chaque heure. Du coup, avec l’aide de cette fiche rsyslog, j’ai du modifier le fichier du service rsyslog et ajouter la ligne suivante :
[Service]LimitNOFILE=64000
Suivi d’un petit reload/restart du démon :
systemctl daemon-reload systemctl restart rsyslog
A partir de la, rsyslog a bien voulu dépasser les 1024 fichier ouverts. Pour ceux qui ont besoin de surveiller le nombre de fichier accédés par le processus vous pouvez utiliser la commande suivante :
watch "ls /proc/$PIDRSYSLOG/fd | wc -l
La commande watch vous rafraichira l’affichage du résultat de la commande toutes les 2s (par défaut). Bien pratique quand vous venez de finir une manip et que vous voulez surveiller un élément.
Voilà, c’est tout pour moi avec cette erreur « rsyslog too many open files » pour aujourd’hui. C »était juste l’astuce, si jamais votre rsyslog se met à faire n’importe quoi. L’autre conseil que je peux vous donner c’est de mettre en place un restart du service une fois par mois au cas où comme moi le service se mettait à faire nawak… En effet, notre service a en moyenne entre 100 et 200 fichiers ouvert mais n’aurais jamais du dépasser 1024. Et pour le coup, le restart du service à fait disparaitre l’erreur avant que l’on change la limite ci-dessus. La « cause racine » de cette erreur n’a pas pu être identifiée, si quelqu’un à une idée, on prend !
Bref, A minima ça m’aura appris un truc et c’était l’occasion de vous partager quelques commandes utiles sous Linux. Geekez bien !
