Executando o comando rpm em determinadas quebras de diretório

1

Eu tenho um problema não relacionado a esse problema de RPM. Não tenho certeza se os dois se relacionam, mas vou falar sobre o que está relacionado com a execução do comando rpm , já que é mais fácil de explicar. A outra questão que estamos tendo diz respeito ao nosso aplicativo, que ninguém mais saberia. De qualquer maneira, nossa pessoa de controle de qualidade está tentando solucionar o motivo pelo qual os arquivos não podem ser gravados nesse diretório específico. Por algum motivo, ela decidiu executar rpm -qa | grep -i lp . Digamos que o diretório seja /home/tom/mydir . Se ela executar o comando rpm fora de /home/tom/mydir como seu usuário, ela obterá o resultado desejado. Se ela está dentro desse diretório, ela encontra o seguinte.

error: cannot open Packages index using db3 - Invalid argument (22)
error: cannot open Packages database in /var/lib/rpm

Como root, posso executar o comando rpm bem dentro do diretório ou em qualquer outro lugar. Ela acha que o problema está relacionado, estou apenas empolgado para entender por que esse diretório está nos dando problema como usuário dela.

Sim, tentei reconstruir o banco de dados RPM também.

    
por luckytaxi 25.05.2012 / 17:45

3 respostas

2

Existem poucas postagens de fóruns com usuários relatando problemas semelhantes, e a resposta popular parece ser assim:

1) encontre e mate qualquer processo que mantenha o rpm db aberto;

lsof | grep /var/lib/rpm

2) e depois reconstruir o banco de dados, e reinicie a máquina ...

rm -fv /var/lib/rpm/__*
rpm --rebuilddb -v -v
sudo reboot

No entanto, se você já fez isso e não teve alegria, eu verificaria o seguinte e colaria o resultado em sua pergunta, ou em um pastebin etc ...

mostre todos os aliases em vigor que possam estar interferindo nas suas opções de invocação;

$ alias                                               
alias cp='cp -i'                                                             
alias egrep='egrep --color=auto'                                             
alias fgrep='fgrep --color=auto'                                             
alias grep='grep --color=auto'                                               
alias l.='ls -d .* --color=auto'                                             
...

mostre o caminho em uso (se você vir um . lá, isso explicaria como você pode obter o CWD efetuando os resultados do comando);

$ echo $PATH
/usr/local/rvm/ge:/usr/:<snip>:/usr/local/sbin:/usr/sbin:/sbin:/opt/depot_too

Em seguida, liste todos os arquivos executáveis que possam estar ocultando os comandos nesse diretório;

 ls -lh /home/tom/mydir
total 400K
drwxrwxr-x    7 tomh tomh 4.0K May 18 16:28 android
...some other stuff...

e

find /home/tom/mydir -executable

etc
fileXXX

mostre qual executável e em qual tipo os comandos estão sendo resolvidos em /home/tom/mydir e outside;

cd /home/tom/mydir
$ which rpm
/bin/rpm
$ type -a rpm
rpm is /bin/rpm


$ which grep
alias grep='grep --color=auto'
/bin/grep
$ type -a grep
grep is aliased to 'grep --color=auto'
grep is /bin/grep
    
por 25.05.2012 / 17:58
0

Execute strace no comando no diretório suspeito e novamente fora. Deve deixar claro onde está o problema.

Como usar o strace?

    
por 25.05.2012 / 18:28
0

Sempre que tive um comando estranho em um diretório em particular, ele geralmente tem duas coisas: ou as variáveis de ambiente PATH ou LD_LIBRARY_PATH contêm caminhos relativos, que acabam pegando um binário / biblioteca daquele diretório particular. Então, examine os dois, e procure por qualquer coisa que não comece com um "/", e também um "::" no meio (isso indicará para pesquisar o diretório atual) ou um caractere ":" à direita.

    
por 29.05.2012 / 03:38

Tags