/ dev / null file tornou-se um arquivo regular

Question

Em nosso servidor de produção, de repente, /dev/null tornou-se um arquivo regular e, devido a esse serviço sshd, parou e não conseguiu efetuar login no servidor. E também tentamos as etapas abaixo para configurar o arquivo de dispositivo de caractere,

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

Assim que executarmos o rm command /dev/null está sendo recriado como um arquivo regular antes que mknod possa ser executado. Não podemos descobrir como isso está acontecendo e qual componente está criando esse arquivo. Então, até resolvermos esse problema, não poderemos criar /dev/null como arquivo de dispositivo de caractere.

    

Answer 1

Quando você exclui (rm) / dev / null, qualquer programa / script que esteja em execução e que precise "> / dev / null" ou equivalente irá recriar um novo arquivo (regular) com esse nome. E aqueles que podem gerar a qualquer momento (e alguns podem também escrever continuamente)

Para vencê-los:

você cria um novo arquivo especial / dev / null (com um nome diferente)

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

e você move (como root) os criados continuamente:

mv -f /dev/newnull /dev/null

E só então você pode reinicializar (não reinicialize sem um arquivo / dev / null correto no lugar ... geralmente não é fácil) [Esqueci desse passo, o que é obviamente necessário. Obrigado @ Random832 pelo lembrete!]

Você precisa reiniciar no final, para se livrar do programa existente que ainda terá um "/ dev / null" aberto e ainda irá gravar no sistema de arquivos mesmo que você o tenha substituído depois, preenchendo o sistema de arquivos pouco a pouco ) (De fato, como ao deletar um arquivo, qualquer programa que ainda tenha esse descritor de arquivo aberto ainda poderá escrever para o antigo inode, mesmo que o nome do arquivo esteja apontando para o novo inode)

    

Answer 2

O motivo pelo qual você não pode recriar /dev/null é provável que algo esteja gravemente escrito assim:

echo "foo" > /dev/null

Examinar o conteúdo do arquivo informará o processo.

Para corrigir seu sistema por enquanto, siga estas instruções:

1. desligar o sistema
2. inicializar com init=/bin/bash
3. remontar / gravável
4. crie o dispositivo char
5. reinicializar

Eu sugiro strongmente fazer um exame intenso do sistema para determinar como / dev / null foi deletado. Verifique se o seu sistema não está comprometido, verifique o log do seu sistema completamente.

    

Answer 3

Você pode executar lsof /dev/null e ver se há um processo aberto, mas não mostra o que está acontecendo em tempo real.

Outra opção seria fazer o dispositivo e movê-lo no lugar.

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

Mas eu gostaria de saber o que está quebrando o sistema primeiro. Você mudou alguma coisa recentemente que possa estar causando isso?

    

Answer 4

Eu encontrei a causa e a correção no meu sistema archlinux.

Se você usar bash e HISTFILE = / dev / null estiver no ambiente, não deverá executar mais comandos do que $ HISTFILESIZE ou $ HISTSIZE. Se você executou mais comandos do que $ HISTFILESIZE no bash enquanto HISTFILE é / dev / null e você saiu do bash, o bash move / dev / null para outro lugar e recria o / dev / null como um arquivo regular com permissão 600.

Se você usar o tramp no emacs 24.4, o tramp-sh.el definirá HISTFILE como / dev / null. Assim, se o bash é o shell para o root e se você faz um monte de operações root com o tramp no emacs 24.4, quando você mata o emacs, o tramp faz o bash delete / dev / null.

Por favor, verifique se o HISTFILE está definido como / dev / null em .bashrc ou em programas como o emacs 24.4.

No meu caso, mudar o shell para zsh funciona em torno do fato de que o tramp faz o bash delete / dev / null no emacs 24.4.