/ dev / null файл стал обычным файлом

На нашем производственном сервере внезапно /dev/nullпоявился обычный файл, и из-за этого служба sshd остановилась и не смогла войти на сервер. А также мы попытались выполнить следующие шаги, чтобы настроить обратно в символьный файл устройства,

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

Как только мы запустим, rmкоманда /dev/nullбудет заново создана как обычный файл, прежде чем mknodсможет ее запустить. Мы не можем понять, как это происходит и какой компонент создает этот файл. Поэтому, пока мы не решим эту проблему, мы не сможем создать /dev/nullкак файл символьного устройства.

Когда вы удаляете (rm) / dev / null, любые программы / скрипты, которые работают и которым требуется "> / dev / null" или эквивалент, воссоздают новый (обычный) файл с этим именем. И те могут появиться в любое время (и некоторые могут также постоянно писать в него)

Чтобы победить их:

вы создаете новый / dev / null специальный файл (под другим именем)

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

и вы перемещаете его (как корень) в непрерывно созданные:

mv -f /dev/newnull /dev/null

И только тогда вы можете перезагрузиться (не перезагружаться без надлежащего файла / dev / null ... это обычно непросто) [Я забыл этот шаг, который, конечно, необходим. Спасибо @ Random832 за напоминание!]

В конце вам необходимо перезагрузиться, чтобы избавиться от существующей программы, у которой по-прежнему будет открыт файл «/ dev / null», и он все равно будет писать в файловую систему, даже если вы впоследствии заменили ее, постепенно заполняя эту файловую систему) Как и при удалении файла, любая программа, у которой все еще открыт этот дескриптор файла, все равно сможет писать в прежний индекс, даже если имя файла теперь указывает на новый)

Вы можете запустить lsof /dev/nullи посмотреть, есть ли процесс, у которого он открыт, но он не покажет вам, что происходит в режиме реального времени.

Другим вариантом будет сделать устройство и переместить его на место.

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

Но я бы хотел знать, что ломает систему в первую очередь. Вы изменили что-нибудь в последнее время, что может быть причиной этого?

Причина, по которой вы не можете воссоздать, /dev/null- это то, что что-то непрерывно записывается в него так:

echo "foo" > /dev/null

Изучение содержимого файла скажет вам, каким процессом это может быть.

Чтобы исправить вашу систему сейчас, следуйте этим инструкциям:

1. выключить систему
2. загружаться с init=/bin/bash
3. перемонтировать / записать
4. создать устройство char
5. перезагрузка

Я настоятельно рекомендую провести тщательное исследование системы, чтобы определить, как / dev / null был удален. Убедитесь, что ваша система не скомпрометирована, тщательно проверьте журнал вашей системы.

Я нашел причину и исправление в моей системе archlinux.

Если вы используете bash и HISTFILE = / dev / null в среде, вы не должны выполнять больше команд, чем $ HISTFILESIZE или $ HISTSIZE. Если вы выполнили больше команд, чем $ HISTFILESIZE для bash, когда HISTFILE равен / dev / null, и вы вышли из bash, bash перемещает / dev / null куда-то еще и воссоздает / dev / null как обычный файл с разрешением 600.

Если вы используете tramp в emacs 24.4, tramp-sh.el устанавливает HISTFILE в значение / dev / null. Таким образом, если bash - это оболочка для root, и если вы выполняете много корневых операций с tramp на emacs 24.4, когда вы убиваете emacs, tramp делает bash delete / dev / null.

Пожалуйста, проверьте, установлен ли HISTFILE на / dev / null в .bashrc или в таких программах, как emacs 24.4.

В моем случае изменение оболочки на zsh работает вокруг того факта, что tramp заставляет bash удалить / dev / null в emacs 24.4.