O arquivo / dev / null se tornou um arquivo regular

Em nosso servidor de produção, de repente /dev/nullse tornou um arquivo regular e, devido a esse serviço sshd, foi interrompido e não foi possível fazer o login no servidor. E também tentamos as etapas abaixo para configurar novamente o arquivo do dispositivo de caracteres,

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

Assim que executamos, o rmcomando /dev/nullestá sendo recriado como um arquivo regular antes que mknodpossa ser executado. Não podemos descobrir como isso está acontecendo e qual componente está criando esse arquivo. Portanto, até resolvermos esse problema, não podemos criar /dev/nullcomo arquivo de dispositivo de caractere.

Quando você exclui (rm) / dev / null, todos os programas / scripts em execução e que precisam "> / dev / null" ou equivalente recriam um novo arquivo (regular) com esse nome. E esses podem aparecer a qualquer momento (e alguns também podem 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 continuamente criados:

mv -f /dev/newnull /dev/null

E só então você pode reiniciar (não reinicie sem um arquivo / dev / null adequado ... geralmente não é fácil) [Esqueci essa etapa, que é obviamente necessária. Obrigado @ Random832 pelo lembrete!]

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

Você pode executar lsof /dev/nulle ver se existe um processo que o abra, mas ele não mostra o que está acontecendo em tempo real.

Outra opção seria fabricar 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?

A razão pela qual você não pode recriar /dev/nullé provável que algo esteja sendo gravado continuamente assim:

echo "foo" > /dev/null

Examinar o conteúdo do arquivo informará qual processo pode ser.

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

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

Eu sugiro fortemente que faça um exame intenso do sistema para determinar como / dev / null foi excluído. Verifique se o seu sistema não está comprometido, verifique cuidadosamente o log do sistema.

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 que $ HISTFILESIZE ou $ HISTSIZE. Se você executou mais comandos que $ HISTFILESIZE no bash enquanto HISTFILE é / dev / null e você saiu do bash, o bash move / dev / null para outro lugar e recria / dev / null como um arquivo regular com permissão 600.

Se você usa o tramp no emacs 24.4, o tramp-sh.el define HISTFILE como / dev / null. Portanto, se o bash é o shell do root e se você realiza muitas operações raiz com o tramp no emacs 24.4, quando você mata o emacs, o tramp faz com que o bash delete / dev / null.

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

No meu caso, alterar o shell para zsh contorna o fato de o tramp tornar o bash delete / dev / null no emacs 24.4.