Ce matin, je me suis aperçu que le serveur était un peu moins réactif que d’habitude.
Ni une, ni deux, je lance le terminal et commence par vérifier les fichiers log. Un message attire alors mon attention :
tail: inotify cannot be used, reverting to polling: Too many open files
Code language: HTTP (http)
C’est bien étrange puisque très peu de services sont censés lancer des tail
. Nous allons donc lancer quelques commandes pour savoir qui est responsable de cet état.
Hotfix : à la recherche des anon_inode:inotify
1. Première méthode pour avoir un aperçu de tout ce qui tourne en ce moment sur le serveur :
ps -ef
La liste est très exhaustive (plusieurs pages chez moi) et ne permet pas vraiment de voir ce qui se passe, étant donné que rien n’est trié.
2. Changeons notre fusil d’épaule et trouvons la liste des processus qui font appel à inotify
:
for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr
Résultat:
8 /proc/25634/fd/anon_inode:inotify
1 /proc/715/fd/anon_inode:inotify
1 /proc/6146/fd/anon_inode:inotify
1 /proc/330/fd/anon_inode:inotify
1 /proc/32148/fd/anon_inode:inotify
1 /proc/31695/fd/anon_inode:inotify
1 /proc/31262/fd/anon_inode:inotify
1 /proc/3067/fd/anon_inode:inotify
1 /proc/3066/fd/anon_inode:inotify
1 /proc/3065/fd/anon_inode:inotify
1 /proc/3064/fd/anon_inode:inotify
1 /proc/3063/fd/anon_inode:inotify
1 /proc/3062/fd/anon_inode:inotify
1 /proc/21853/fd/anon_inode:inotify
1 /proc/2063/fd/anon_inode:inotify
1 /proc/1924/fd/anon_inode:inotify
1 /proc/1563/fd/anon_inode:inotify
1 /proc/1196/fd/anon_inode:inotify
3. Maintenant, nous allons chercher dans cette liste de processus les commandes qui font appel à anon_inode:inotify
:
ps -p $(find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -print 2> /dev/null | sed -e 's/^\/proc\/\([0-9]*\)\/.*/\1/')
Code language: JavaScript (javascript)
Résultat:
PID TTY STAT TIME COMMAND
330 ? Ss 0:00 /lib/systemd/systemd-udevd --daemon
715 ? S 0:00 tail -f /tmp/bm-tarball.log.7lZV2O
1196 ? S 0:00 tail -f /tmp/bm-tarball.log.B1I64h
1563 ? S 0:00 tail -f /tmp/bm-tarball.log.hhDVas
1924 ? S 0:00 tail -f /tmp/bm-tarball.log.Ztuk8T
2063 ? Ss 0:06 /usr/bin/dbus-daemon --system
3062 tty1 Ss+ 0:00 /sbin/getty 38400 tty1
3063 tty2 Ss+ 0:00 /sbin/getty 38400 tty2
3064 tty3 Ss+ 0:00 /sbin/getty 38400 tty3
3065 tty4 Ss+ 0:00 /sbin/getty 38400 tty4
3066 tty5 Ss+ 0:00 /sbin/getty 38400 tty5
3067 tty6 Ss+ 0:00 /sbin/getty 38400 tty6
6146 ? Ss 0:00 gpg-agent --homedir /root/.gnupg --use-standard-socket --daemon
25634 ? Sl 0:21 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -
31262 ? S 0:00 tail -f /tmp/bm-tarball.log.82bIqR
31695 ? S 0:00 tail -f /tmp/bm-tarball.log.6Hqw69
32148 ? S 0:00 tail -f /tmp/bm-tarball.log.UMpkfi
Code language: JavaScript (javascript)
Ah on y arrive, c’est déjà beaucoup plus clair. Le service qui pose problème est donc backup-manager
(voir le tutoriel Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde), qui semble laisser ouvert tous ses fichiers de logs !