Le fichier / dev / null est devenu un fichier normal

Dans notre serveur de production est soudainement /dev/nulldevenu un fichier normal et en raison de ce service sshd s'est arrêté et n'a pas pu se connecter au serveur. Et nous avons également essayé les étapes ci-dessous pour reconfigurer le fichier de périphérique de caractères,

rm -rf /dev/null
mknod /dev/null c 1 3

Dès que nous exécutons la rmcommande /dev/nullest recréée en tant que fichier normal avant de mknodpouvoir s'exécuter. Nous ne pouvons pas comprendre comment cela se produit et quel composant crée ce fichier. Donc, jusqu'à ce que nous résolvions ce problème, nous ne pouvons pas créer /dev/nullde fichier de périphérique de caractères.

Lorsque vous supprimez (rm) / dev / null, tous les programmes / scripts qui s'exécutent et qui doivent "> / dev / null" ou équivalent recréeront un nouveau fichier (normal) avec ce nom. Et ceux-ci peuvent apparaître à tout moment (et certains peuvent également y écrire en continu)

Pour les battre:

vous créez un nouveau fichier spécial / dev / null (sous un nom différent)

mknod /dev/newnull c 1 3
chmod 777 /dev/newnull

et vous le déplacez sur (en tant que root) ceux créés en continu:

mv -f /dev/newnull /dev/null

Et seulement alors vous pouvez redémarrer (ne redémarrez pas sans un fichier / dev / null correct en place ... ce n'est généralement pas facile) [J'ai oublié cette étape, qui est bien sûr nécessaire. Merci @ Random832 pour le rappel!]

Vous devez redémarrer à la fin, pour vous débarrasser du programme existant qui aura toujours un "/ dev / null" ouvert et qui écrira toujours sur le système de fichiers même si vous l'avez remplacé par la suite, remplissant ce système de fichiers petit à petit) (En effet , comme lors de la suppression d'un fichier, tout programme qui a toujours ce descripteur de fichier ouvert pourra toujours écrire dans l'ancien inode, même si le nom de fichier pointe maintenant vers le nouveau)

Vous pouvez exécuter lsof /dev/nullet voir s'il existe un processus qui l'ouvre, mais il ne vous montrera pas ce qui se passe en temps réel.

Une autre option serait de fabriquer l'appareil et de le déplacer en place.

mknod /dev/null.tmp c 1 3 && mv /dev/null.tmp /dev/null

Mais je voudrais d'abord savoir ce qui brise le système. Avez-vous récemment changé quelque chose qui pourrait être à l'origine de cela?

La raison pour laquelle vous ne pouvez pas recréer /dev/nullest probablement que quelque chose y écrit continuellement comme ceci:

echo "foo" > /dev/null

L'examen du contenu du fichier vous dira de quel processus il pourrait s'agir.

Pour réparer votre système pour l'instant, suivez ces instructions:

1. arrêter le système
2. démarrer avec init=/bin/bash
3. remonter / inscriptible
4. créer le périphérique char
5. redémarrer

Je suggère fortement de faire un examen approfondi du système pour déterminer comment / dev / null a été supprimé. Assurez-vous que votre système n'est pas compromis, consultez attentivement le journal de votre système.

J'ai trouvé la cause et le correctif sur mon système archlinux.

Si vous utilisez bash et HISTFILE = / dev / null est dans l'environnement, vous ne devez pas exécuter plus de commandes que $ HISTFILESIZE ou $ HISTSIZE. Si vous avez exécuté plus de commandes que $ HISTFILESIZE sur bash alors que HISTFILE est / dev / null et que vous avez quitté bash, bash déplace / dev / null ailleurs et recrée / dev / null en tant que fichier normal avec l'autorisation 600.

Si vous utilisez tramp sur emacs 24.4, tramp-sh.el définit HISTFILE sur / dev / null. Ainsi, si bash est le shell de root et si vous faites beaucoup d'opérations root avec tramp sur emacs 24.4, lorsque vous tuez emacs, tramp fait bash supprimer / dev / null.

Veuillez vérifier si HISTFILE est défini sur / dev / null dans .bashrc ou dans des programmes comme emacs 24.4.

Dans mon cas, changer le shell en zsh contourne le fait que tramp rend bash delete / dev / null sur emacs 24.4.