Plik / dev / null stał się plikiem zwykłym

W naszym serwerze produkcyjnym nagle /dev/nullstał się zwykłym plikiem i z powodu tej usługi sshd został zatrzymany i nie mógł się zalogować do serwera. A także próbowaliśmy wykonać poniższe kroki, aby skonfigurować plik urządzenia znakowego,

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

Gdy tylko uruchomimy, rmpolecenie /dev/nullzostanie ponownie utworzone jako zwykły plik, zanim będzie mknodmożna je uruchomić. Nie możemy ustalić, jak to się dzieje i który składnik tworzy ten plik. Więc dopóki nie rozwiążemy tego problemu, nie możemy utworzyć /dev/nullpliku urządzenia postaci.

Kiedy usuniesz (rm) / dev / null, wszystkie programy / skrypty, które są uruchomione i wymagają „> / dev / null” lub odpowiednika, ponownie utworzą nowy (zwykły) plik o tej nazwie. A te mogą się odradzać w dowolnym momencie (a niektórzy mogą też ciągle do niego pisać)

Aby je pokonać:

tworzysz nowy plik specjalny / dev / null (pod inną nazwą)

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

i przenosisz go (jako root) do ciągle tworzonych:

mv -f /dev/newnull /dev/null

I tylko wtedy możesz zrestartować komputer (nie uruchamiaj go ponownie bez właściwego pliku / dev / null ... zwykle nie jest to łatwe) [Zapomniałem tego kroku, który jest oczywiście konieczny. Dzięki @ Random832 za przypomnienie!]

W końcu musisz zrestartować komputer, aby pozbyć się istniejącego programu, który nadal będzie miał otwarte „/ dev / null” i nadal będzie zapisywać w systemie plików, nawet jeśli później go zastąpiłeś, stopniowo wypełniając ten system plików (Rzeczywiście , podobnie jak podczas usuwania pliku, każdy program, który nadal ma otwarty deskryptor pliku, będzie mógł nadal zapisywać na byłym i-węzle, nawet jeśli nazwa pliku wskazuje teraz na nowy)

Możesz uruchomić lsof /dev/nulli sprawdzić, czy istnieje proces, który ma go otworzyć, ale nie pokazałby Ci, co dzieje się w czasie rzeczywistym.

Inną opcją byłoby wykonanie urządzenia i przeniesienie go na miejsce.

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

Chciałbym jednak wiedzieć, co najpierw psuje system. Czy ostatnio zmieniłeś coś, co może to powodować?

Powodem, dla którego nie można odtworzyć, /dev/nulljest prawdopodobne, że coś ciągle do tego pisze:

echo "foo" > /dev/null

Analiza zawartości pliku powie ci, jaki to może być proces.

Aby na razie naprawić system, wykonaj następujące instrukcje:

1. zamknij system
2. boot z init=/bin/bash
3. podłącz / zapisuj
4. utwórz urządzenie char
5. restart

Zdecydowanie sugeruję przeprowadzenie dokładnej analizy systemu w celu ustalenia, w jaki sposób usunięto / dev / null. Upewnij się, że system nie jest zagrożony, dokładnie sprawdź dziennik systemu.

Znalazłem przyczynę i poprawkę w moim systemie archlinux.

Jeśli używasz bash, a HISTFILE = / dev / null jest w środowisku, nie powinieneś wykonywać więcej poleceń niż $ HISTFILESIZE lub $ HISTSIZE. Jeśli wykonałeś więcej poleceń niż $ HISTFILESIZE podczas bash, gdy HISTFILE to / dev / null i opuściłeś bash, bash przenosi / dev / null gdzie indziej i odtwarza / dev / null jako zwykły plik z uprawnieniem 600.

Jeśli używasz trampa na emacsie 24.4, tramp-sh.el ustawia HISTFILE na / dev / null. Tak więc, jeśli bash jest powłoką dla roota i jeśli wykonujesz wiele operacji rootowania za pomocą trampa na emacs 24.4, to kiedy zabijasz emacsa, tramp powoduje, że bash usuwa / dev / null.

Sprawdź, czy HISTFILE jest ustawiony na / dev / null w .bashrc lub w programach takich jak emacs 24.4.

W moim przypadku zmiana powłoki na zsh działa w ten sposób, że tramp sprawia, że ​​bash delete / dev / null na emacs 24.4.