/ 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" і все одно буде писати у файлову систему, навіть якщо ви потім її замінили, поповнюючи цю файлову систему потроху) (Дійсно , як, наприклад, при видаленні файлу, будь-яка програма, у якої все ще відкритий дескриптор файлу, все ще зможе записати в колишній inode, навіть якщо ім'я файлу тепер вказує на новий)

Ви можете запустити 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 delete / dev / null на emacs 24.4.