На нашем производственном сервере внезапно /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
и вы перемещаете его (как root) над постоянно создаваемыми:
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
Изучив содержимое файла, вы узнаете, что это может быть за процесс.
Чтобы исправить вашу систему, следуйте этим инструкциям:
init=/bin/bashЯ настоятельно рекомендую провести тщательное исследование системы, чтобы определить, как был удален / dev / null. Убедитесь, что ваша система не скомпрометирована, тщательно проверьте системный журнал.
Я нашел причину и исправление в своей системе Archlinux.
Если вы используете bash и HISTFILE = / dev / null находится в среде, вам не следует выполнять больше команд, чем $ HISTFILESIZE или $ HISTSIZE. Если вы выполнили на bash больше команд, чем $ HISTFILESIZE, а HISTFILE - / dev / null и вы вышли из bash, bash перемещает / dev / null в другое место и воссоздает / dev / null как обычный файл с разрешением 600.
Если вы используете tramp в emacs 24.4, tramp-sh.el устанавливает HISTFILE в / dev / null. Таким образом, если bash является оболочкой для root и если вы выполняете много операций root с tramp на emacs 24.4, когда вы убиваете emacs, tramp заставляет bash удалить / dev / null.
Пожалуйста, проверьте, установлен ли HISTFILE на / dev / null в .bashrc или в таких программах, как emacs 24.4.
В моем случае изменение оболочки на zsh работает вокруг того факта, что tramp заставляет bash удалить / dev / null на emacs 24.4.