No Ubuntu recebo: “-bash: ./flume Nenhum tal arquivo ou diretório” MAS o flume está lá e é executável. O mesmo binário OK no RHEL

3

Isso já está postado no serverfault - e pode ser mais apropriado lá. Retrabalhado um pouco da postagem original.

Temos um produto baseado no Linux do CentOS 4 de 32 bits que é executado sem modificações no CentOS / RHEL 4 e 5 e no SLES 10. de 32 e 64 bits. Ele também é executado sem modificações no SLES 9 de 64 bits. [O SLES 9 de 32 bits requer um libstdc ++ diferente.]

O nome do executável binário principal é 'flume'

Ontem tentamos colocar isso no Ubuntu 10 de 64 bits e, mesmo que o arquivo esteja lá e com o tamanho certo, nós temos:

-bash: ./flume: não existe esse arquivo ou diretório

'file flume' mostra que é um ELF de 32 bits (não se lembra da saída exata e o sistema está em uma rede isolada)

Se colocar em / usr / local / bin, então 'which flume' retorna: / usr / local / bin / flume

O arquivo é marcado como executável (fez 'chmod + x flume') e o lsattr não mostra problemas com os bits de atributo.

Ainda não consegui experimentar o 'ldd flume'. Eu também não tentei 'strace flume'. Atualmente estou com uma falha de ar condicionado. [Tem sido esse tipo de semana!]

Eu agora suspeito que alguma biblioteca não está lá.

Esta é uma mensagem profundamente inútil e que nunca vi antes.

Isso é peculiar para o Ubuntu ou talvez apenas para esta instalação.

Nós desistimos e nos mudamos para um sistema RHEL 4 e está tudo bem. Mas tenho certeza que gostaria de saber o que causa isso.

    
por lcbrevard 13.07.2010 / 17:19

3 respostas

3

[copiado de Gilles ' responder em Falha do servidor ]

Você pode obter esta mensagem se o flume existir, mas o seu "loader" não existir, onde

  • o carregador de um executável nativo é seu carregador dinâmico, por exemplo, /lib/ld-linux.so.2 ;
  • o carregador de um script é o programa mencionado em sua linha shebang, por exemplo, /bin/sh se o script começar com #!/bin/sh .

No seu caso, parece que você não tem o carregador dinâmico de 32 bits instalado no sistema Ubuntu de 64 bits. Está no pacote libc6-i386 .

strings ./flume | head -n 1 exibirá o caminho para o carregador dinâmico que o flume requer. Este é um daqueles raros casos em que strace ./flume é completamente inútil.

Eu considero essa situação como a mensagem de erro mais enganosa do Unix. Infelizmente, consertá-lo seria difícil: o kernel só pode relatar um código de erro numérico para o chamador do programa, então ele só tem espaço para “comando não encontrado” e não para o nome do carregador que está procurando.

    
por 13.02.2011 / 01:54
1

Eu tive algo semelhante, no final, foi devido ao fato de que o libstdc ++ 5 foi removido do Ubuntu 10.04 e 9.10. Eu não sei porque o erro que recebi não foi possível encontrar o libstdc ++, mas quando eu o instalei (do debian unstable) o erro desapareceu.

    
por 29.07.2010 / 21:07
1

Eu tive um problema semelhante com EXEs no Ubuntu 12.04 64-bit.

A solução para mim foi instalar o LSB no sistema de destino:

sudo apt-get install lsb

Os programas não funcionando de repente agora funcionavam. O pouco sobre o uso

strings EXE-NOT-WORKING | head -1

forneceu a chave. O loader LSB identificado no EXE-NOT-WORKING foi maior que o padrão exibido para outros arquivos EXE que estavam funcionando.

    
por 22.06.2012 / 19:54