Por que esse arquivo está oculto quando você executa o ls?

10

Edição: Eu esqueci totalmente sobre esta discussão. Acontece que eu tinha um disco rígido ruim. Tivemos que reimplementar esse servidor para outras necessidades, então finalmente consegui substituir o disco defeituoso e estamos de volta aos negócios.

Por algumas semanas, eu não conseguia entender por que não consegui excluir esse arquivo em particular. Como root, posso, mas meu script de shell é executado como um usuário diferente. Então eu corro ls -la e não está lá. No entanto, se eu chamá-lo como parâmetro, ele aparece! Com certeza, o proprietário é root, portanto, não consigo excluir.

Observe que 6535 está faltando ...

[root@server]# ls -la 653*
-rw-rw-r--  1 svn svn  24002 Mar 26 01:00 653
-rw-rw-r--  1 svn svn   7114 Mar 26 01:01 6530
-rw-rw-r--  1 svn svn   8653 Mar 26 01:01 6531
-rw-rw-r--  1 svn svn   6836 Mar 26 01:01 6532
-rw-rw-r--  1 svn svn   3308 Mar 26 01:01 6533
-rw-rw-r--  1 svn svn   3918 Mar 26 01:01 6534
-rw-rw-r--  1 svn svn   3237 Mar 26 01:01 6536
-rw-rw-r--  1 svn svn   3195 Mar 26 01:01 6537
-rw-rw-r--  1 svn svn  27725 Mar 26 01:01 6538
-rw-rw-r--  1 svn svn 263473 Mar 26 01:01 6539

Agora ele aparece se você ligar diretamente.

[root@server]# ls -la 6535
-rw-rw-r--  1 root root 3486 Mar 26 01:01 6535

Aqui está algo interessante. Então, eu peguei esse problema porque, no meu script de shell, ele falharia em excluir porque o 6535 pertence ao root. O arquivo realmente aparece depois que eu executo "rm -rf". Eu tentei anteriormente e ele não conseguiu remover o diretório, pois me dizia que o diretório não está vazio. Entrei e olhei e, com certeza, o arquivo "6535" finalmente aparece. Não faço ideia por que está fazendo isso.

strace diz o seguinte

#strace ls -la 653* 2>&1 | grep ^open

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/tls/librt.so.1", O_RDONLY) = 3
open("/lib64/libacl.so.1", O_RDONLY)    = 3
open("/lib64/libselinux.so.1", O_RDONLY) = 3
open("/lib64/tls/libc.so.6", O_RDONLY)  = 3
open("/lib64/tls/libpthread.so.0", O_RDONLY) = 3
open("/lib64/libattr.so.1", O_RDONLY)   = 3
open("/etc/selinux/config", O_RDONLY)   = 3
open("/proc/mounts", O_RDONLY)          = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
open("/proc/filesystems", O_RDONLY)     = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
open("/usr/share/locale/en_US.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/nsswitch.conf", O_RDONLY)    = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/libnss_files.so.2", O_RDONLY) = 3
open("/etc/passwd", O_RDONLY)           = 3
open("/etc/group", O_RDONLY)            = 3
open("/etc/mtab", O_RDONLY)             = 3
open("/proc/meminfo", O_RDONLY)         = 3
open("/etc/localtime", O_RDONLY)        = 3

linux command-line-interface shell

— luckytaxi
fonte

2

Se você descobrir isso, poste uma atualização.

— einstiien

Interessante. o que é relatado com ls -ab? Talvez algum caractere não octal estranho esteja no nome do arquivo? Eu pensaria que -a listaria de qualquer maneira, mas não tenho certeza.

— 31410 egorgry

1

Você executou um fsck recentemente? É remotamente possível que algo esteja quebrado no sistema de arquivos.

— Zoredache 26/03

Vou ter que testá-lo novamente amanhã, saindo para o dia.

— luckytaxi

7

Isso é um pouco preocupante. Verificaria se o seu lsarquivo não foi modificado comparando com um arquivo válido. Você pode usar as ferramentas de pacote da sua distribuição para verificar o arquivo em um sistema isolado.

— Warner
fonte

+1: ls -al deve mostrar tudo. Caso contrário, há um problema em algum lugar.

— 26610 Satanicpuppy

2

É bem possível que lstenha sido modificado para ocultar um PID específico, possivelmente 6535. #

— MikeyB

Não ... nada ...

— luckytaxi 26/03

6

Às vezes, os nomes de arquivos têm caracteres estranhos, como sequências de movimento do cursor. Tente isso para garantir:

ls -lq

Ele deve mostrar pontos de interrogação em vez de caracteres de controle (provavelmente é o padrão, mas pode não ser).

Isso demonstra parcialmente o tipo de problema que pode estar presente:

touch A C
touch B$(tput cuu1)$'\r'
ls -l
ls -lq
ls -l --show-control-chars    # for systems that have that option and default to -q

Eu também tentaria:

type -a ls
alias ls
declare -f ls
md5sum /bin/ls    # compare to a known-good identical system

para ver se um alias ou função está definido ou se um binário está em um local estranho ou foi modificado.

— Pausado até novo aviso.
fonte

1

+1 boa percepção. É importante observar que, se lsmodificado, md5sumo sistema também pode ter sido potencialmente modificado. Você precisa de um ambiente sadio conhecido para verificar e chegar a uma conclusão definitiva.

— Warner

Descobri que, mesmo que o md5 tenha sido alterado para produzir resultados falsos, se você fizer coisas como 'arquivo md5', ainda poderá obter bons resultados (se o programa md5 funcionar), fazendo algo como bzip2 <arquivo | MD5 e compare isso com o mesmo comando em outro lugar.

— chris

3

Você pode querer fsck esse volume.

— Florin Andrei
fonte

13

isso é o que ela disse.

— einstiien

2

Normalmente faço algo assim se acredito que 'ls' foi modificado ...

python -c "import os; print os.listdir('.')"

É claro que o Python, a Biblioteca C, o kernel ou o sistema de arquivos também podem ser modificados, mas geralmente são apenas os utilitários de shell.

— McJeff
fonte

2

Ou, você poderia usar a expansão nome do arquivo do shell para ler o diretório - * echo (e se você quer tudo, eco *. *)

— chris

*.*mostrará apenas arquivos com caracteres seguidos de um ponto seguido de caracteres. Definitivamente, isso não é tudo no sistema * nix. Eu não tenho certeza echo irá mostrar-lhe tudo em um comando, eu era capaz de fazê-loecho * && echo .*

— einstiien

4

Se você observar com atenção, é * (espaço). *, Não *. * A pontuação não é o ponto forte deste sistema de comentários ... E echo fica perfeitamente feliz em expandir tantas expressões separadas pelo "$ IFS" quanto você se importa de alimentá-lo. O boolean && não é necessário, ou realmente ainda faz muito sentido, porque && é um boolean e e sempre trabalho porque o comando echo é sempre bem sucedida.

— chris

@ Chris: meu mal, muito difícil de ver isso.

— einstiien

2

Você pode analisar exatamente o que o ls está fazendo usando strace, e isso pode lhe dizer por que está evitando mostrar esse nome de arquivo.

strace ls -la 653* 2>&1 | less

veja isso e veja o que está acontecendo.

strace ls -la 653* 2>&1 | grep ^open

A saída será assim:

open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/librt.so.1", O_RDONLY)       = 3
open("/lib/libacl.so.1", O_RDONLY)      = 3
open("/lib/libselinux.so.1", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libattr.so.1", O_RDONLY)     = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libsepol.so.1", O_RDONLY)    = 3
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = 3
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
open("/selinux/mls", O_RDONLY|O_LARGEFILE) = 3

e se você vir algo como

open("/var/tmp/.../H@ckl1st", O_RDONLY) = 3

tenha cuidado, você foi 0wned ...

Este não é um teste conclusivo, mas é um bom indicador ...

(se você estiver usando solaris ou outros sistemas operacionais, pode ser necessário usar treliça ou outro utilitário semelhante em vez de strace)

(se você estiver usando um shell derivado do csh / tcsh, provavelmente precisará de instruções de redirecionamento diferentes)

— chris
fonte

Eu gosto disso. O straceutilitário é realmente um canivete suíço. Você chega ao nível de chamada do sistema e ignora toda uma pilha de complicações arbitrárias. É uma das primeiras coisas que qualquer administrador de sistema. vale um centavo deve despejar em uma máquina recém-instalada.

— McJeff 26/03

Sim - as duas ferramentas mais valiosas para um administrador de sistemas são truss / strace e tcpdump. Com eles, você sempre pode olhar embaixo das cobertas para ver o que acontece quando algo está ou não se comportando da maneira que você espera.

— chris

2

Atualização rápida, tivemos que substituir o servidor por outros motivos. Foi o sistema de arquivos. Está tudo bem agora !!! Obrigado a todos.

— luckytaxi
fonte

Você quer dizer que o sistema de arquivos foi ferrado e isso foi apenas um sintoma maluco?

— chris

sim foi isso.

— Sorteioxi

Você provavelmente poderia ter ficado preso em uma edição para dizer que há uma solução na lista abaixo, pois ela foi ocultada sob outras respostas positivas (e úteis para a solução de problemas).

— Bart Silverstrim

0

A teoria do hack é interessante, mas eu tenho uma teoria alternativa. A semântica de exclusão de arquivo Unix manterá o arquivo por perto até que todos os processos tenham fechado os identificadores de arquivo aberto apontando para ele. Talvez alguém tenha pausado um check-out / confirmação de SVN ou um encadeamento do servidor desligado. Se reiniciar o processo SVN (ou Apache) resolver seu problema, é aqui que eu colocaria a culpa.

Talvez você possa identificar o processo que ainda está usando este arquivo lsof | grep 6535?

— jldugger
fonte

sim, lsof não mostrou nada. O interessante é que 6535 também está "ausente" na fonte. Meu script faz uma cópia instantânea do repositório original para outro diretório. Foi aí que tive problemas com a impossibilidade de excluir esse arquivo específico por algum motivo.

— luckytaxi

Um arquivo excluído, mas aberto, não impedirá que você exclua o diretório que contém, pois uma vez que a entrada do diretório seja excluída, a entrada do diretório não existirá e, portanto, o diretório ficará vazio. Você não recuperará o espaço do arquivo até que o processo que está aberto seja interrompido, mas o diretório que continha esse arquivo agora pode ser excluído.

— chris

Sua teoria alternativa é interessante. A remoção, se bem-sucedida, removeria instantaneamente o link físico. O inode provavelmente ainda conteria os dados e alguns identificadores de arquivo podem tê-lo em cache na memória, mas não acredito que esse cenário possa explicar o comportamento descrito. Ou, o que Chris disse, heh.

— Warner