ALTERAR SENHA ROOT PODE DAR CACA? - INICIANTE

paulo1205
(usa Ubuntu)

Enviado em 22/02/2017 - 11:59h

Você já deu algum reboot nessa máquina recentemente?

Da saída do comando, você pode ver que não tem quase nada ocupando espaço na raiz: o total da partição é 148228kiB (cerca de 145MiB), com o maior diretório, /lib, ocupando apenas cerca de 128MiB.

Onde estão os outros 9,2GiB, então?

Eles podem estar em:

1) Algum (ou talvez mais de um) arquivo que foi removido do diretório (com rm ou unlink), mas que permanece em uso por algum processo, logo não foi removido definitivamente do disco. Se esse for o caso, quando o processo que está retendo o arquivo for encerrado, o espaço automaticamente se tornará disponível novamente.

2) Alguma outra partição foi montada por cima de um diretório que não estava vazio, escondendo o conteúdo original de acesso pelo sistema. Por exemplo, imagine que o /var originalmente não estivesse numa partição separada, e que ele estivesse enchendo perigosamente. Aí, o outro administrador criou uma partição para acomodar o conteúdo do /var, mas montou a nova partição por cima da antiga antes de esvaziar seu conteúdo. Quando a nova partição foi montada, o conteúdo antigo fica inacessível, mas continua presente, e voltará a ser visível se a partição for desmontada.

3) Uma combinação das duas coisas. Por exemplo, um processo já estava com um arquivo aberto dentro do /var original (residente na raiz), e permaneceu com esse arquivo aberto na hora em que a nova partição foi montada por cima do /var. Esse processo pode continuar escrevendo e lendo no arquivo, eventualmente consumindo espaço da partição raiz, não do volume que foi montado depois. No entanto, nenhum outro processo vai conseguir ver esse arquivo enquanto ele estiver encoberto pelo outro volume.


Para diagnosticar isso, você teria de parar todos os serviços da máquina, desmontar todos os sistemas de arquivo fora da raiz, e então repetir a investigação que eu sugeri anteriormente.

xandao89
(usa Debian)

Enviado em 22/02/2017 - 12:54h

Boa tarde!

Com relação ao reboot, sim, fiz isso ontem (21/02/2017) inclusive por achar que talvez pudesse resolver o problema e nada, continua na mesma.
Fiz uma vasculhação de arquivos com o comando

lsof +L1 

no qual matei 4 processos do samba que estavam como arquivos deletados mas que também não surtiram nenhum tipo de efeito (foi uma dica de um professor meu da faculdade).

Com relação à sobreposição de partições como vc citou acredito que isso dificilmente tenha acontecido pois o técnico antigo foi quem montou todo o sistema dessa empresa desde o 0 e como eu assumi agora a pouco tempo também não fiz nenhuma alteração de grande porte e acredito que o técnico anterior não iria cometer um erro dessa amplitude sendo que ele próprio criou todo o cenário e sabia o que estava fazendo.

Ouvi/li também um boato que pudesse ser um erro crônico da distribuição e que resolveria formatando... Estou começando a achar que estou ficando sem saídas. Meu medo de formatar é reinstalar tudo com novas distros atualizadas assim como postgres atualizado, samba, etc e isso dê conflito com o cenário atual da empresa e com o software que usa a base de dados. Enfim, um dilema grande a ser estudado creio eu.

paulo1205
(usa Ubuntu)

Enviado em 22/02/2017 - 15:58h

Essa conversa de reformatar e reinstalar é tolice. Você só teria de reinstalar alguma coisa se suspeitasse de invasão do servidor com comprometimento de conteúdo e da segurança do sistema -- e mesmo assim, ainda seria possível recuperar um sistema desses sem reformatar.

Antes de fazer essas coisas radicais, faça o que eu disse. Tire os serviços do ar, entrando em modo single user, e desmonte todas as partições fora da raiz, e rode o du de novo. É quase certo que você vai consegui fazer o “culpado” aparecer.