'std :: bad_alloc' depois de trocar por engano / usr / permissions

1

Estou trabalhando em uma máquina Linux rodando o Ubuntu Bionic Beaver, release 18.04.

Outro dia, por engano, alterei o diretório /usr/ para ser de propriedade de um usuário, em vez de raiz. Infelizmente, eu fiz isso de forma recursiva, e isso atrapalhou bastante o sistema, porque também alterou as permissões suid em alguns dos comandos (por exemplo, passwd , sudo ). Nós realmente não podemos reinstalar (bem, podemos, mas vai custar!), Então eu inicializei a partir de um LiveUSB e mudei manualmente todas as permissões / grupos / usuários corretos para cada arquivo que eu poderia identificar se não fosse Root:Root Grupo de usuários. Eu fiz isso comparando a saída de outro computador Ubuntu de ls -lha /usr/ .

Parece ser mais fixo, mas agora estou correndo para o erro 'std :: bad_alloc' depois de executar alguns scripts python bastante padrão. A parte estranha sobre isso é que só surge algumas vezes. Por exemplo, se eu abrir o python a partir da linha de comando e copiar e colar o código, o código será executado sem erros. No entanto, se eu executar o script inteiro a partir da linha de comando (por exemplo, python script.py ), recebo esse erro. A mensagem de erro completa é:

terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped)

Mas para adicionar outro toque - às vezes eu posso executar o mesmo script python a partir da linha de comando sem nenhum problema, e outros eu recebo este erro como acima.

Se alguém tiver ideias de onde procurar especificamente para consertar isso, seria ótimo! Eu vou tentar fazer a mesma coisa que antes, mas com a saída ls -lha /usr/ de uma versão 18.04, já que eu tinha apenas 16 saídas de lançamento na mão.

    
por user3389288 25.05.2018 / 03:01

1 resposta

1

Reinstale todos os pacotes Debian que envolvem /usr

Execute este comando para informar apt para reinstalar todos os pacotes que colocam arquivos em /usr :

dpkg-query -S '/usr/' |
  sed 's/: .*$//' |
  tr -d ',' |
  xargs apt install -y --reinstall

Aviso: a reinstalação acontece sem um aviso de confirmação.

Se você receber uma mensagem como

Package PACKAGE-NAME is not available, but is referred to by another package.

onde PACKAGE-NAME é um pacote inatingível, você pode excluir o pacote para reinstalação da seguinte forma:

dpkg-query -S '/usr/' |
  sed 's/: .*$//' |
  tr -d ',' |
  tr ' ' '\n' |
  grep -v 'PACKAGE-NAME' |
  xargs apt install -y reinstall

Você pode encadear quantos comandos grep -v forem necessários.

Explicação

É possível que o sistema Ubuntu com o qual você comparou não tenha os mesmos pacotes instalados, o que significaria que poderia haver mais arquivos com as permissões erradas dentro de /usr .

Por ter apt reinstalar os pacotes, você pode ter certeza de que todos os arquivos em /usr instalados pelo sistema operacional têm as permissões pretendidas.

Reinstalar todos os pacotes pip

Esta seção assume que você instalou pacotes do Python com pip como root.

Execute este comando para reinstalar todos os pacotes pip:

sudo pip freeze --local | xargs sudo pip install --upgrade --force-reinstall

Execute este comando para remover arquivos de bytecode do Python:

sudo find /usr/ -name '*.pyc' -delete

Explicação

Como seu problema envolve o Python, imagino que você tenha instalado pacotes Python em todo o sistema em caminhos como /usr/local/lib/python2.7/dist-packages e /usr/local/lib/python3/dist-packages .

Quando o interpretador Python é executado, ele também cria arquivos de bytecode ( *.pyc ), que também podem ter suas permissões afetadas quando você recursivamente bagunçou suas permissões de pasta /usr . A exclusão dos arquivos .pyc garante que o Python os gere novamente na próxima vez que seus scripts forem executados.

Reinstalar todos os pacotes Debian

Se a reinstalação apenas dos pacotes envolvendo um diretório não resolveu o problema, existe essa opção mais extrema.

Execute este comando para informar apt para reinstalar todos os pacotes no sistema:

dpkg --get-selections |
  awk '{if($2=="install"){print $1}}' |
  xargs sudo apt install -y --reinstall

Aviso: a reinstalação acontece sem um aviso de confirmação.

Explicação

Talvez algo fora da sua pasta /usr tenha quebrado.

Foi o que descobri em 07 de fevereiro de 2018 quando descobri que um hipervisor de produção Debian (jessie) havia caído. O nó não ficou online depois de uma reinicialização.

Quando eu carreguei uma imagem de resgate do Ubuntu, eu não pude nem mesmo chroot no hipervisor quebrado porque /bin/bash me deu uma falha de segmentação (tipo o seu script Python abortado). Na verdade, a maioria dos arquivos do sistema estava de alguma forma corrompida.

Havia uma máquina virtual de produção nesse hipervisor que precisaria de um pouco de esforço para se reimplantar em outro lugar devido ao estado quebrado do hypervisor, então pensei em tentar um reparo.

Copiei arquivos binários e de biblioteca do Debian 8 para a máquina até conseguir chroot e executar apt e dpkg . A partir daqui, eu poderia instruir apt para reinstalar todo o sistema.

Depois de lidar com algumas peculiaridades de pacotes, cada pacote conseguiu ser reinstalado. Depois que eu reiniciei, o servidor voltou como se nunca estivesse corrompido.

Eu tive que reimplantar os pacotes Python do servidor separadamente porque eles estavam bizarramente corrompidos também, mas pelo menos a máquina virtual de produção estava ilesa.

É possível consertar um sistema mal quebrado, reinstalando o que você pode. Para o futuro, recomendo que seu servidor seja o mais reproduzível possível para que, se o software obtiver acidificado De qualquer forma, você pode facilmente reprovisionar o sistema com pouco esforço.

    
por 27.07.2018 / 13:43