Dlaczego ten plik jest ukryty po uruchomieniu ls?

EDYCJA: Całkowicie zapomniałem o tym wątku. Okazuje się, że miałem zły dysk twardy. Musieliśmy ponownie wdrożyć ten serwer do innych potrzeb, więc w końcu przystąpiłem do wymiany jednego uszkodzonego dysku i wróciliśmy do pracy.

Od kilku tygodni nie mogłem zrozumieć, dlaczego nie byłem w stanie usunąć tego konkretnego pliku. Jako root mogę, ale mój skrypt powłoki działa jako inny użytkownik. Więc idę uruchomić ls -la i nie ma go. Jednak jeśli wywołam to jako parametr, pojawi się! Rzeczywiście, właściciel jest rootem, dlatego nie mogę go usunąć.

Uwaga, brakuje 6535 ...

[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

Teraz pokazuje się, jeśli zadzwonisz bezpośrednio.

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

Oto coś interesującego. Więc złapałem ten problem, ponieważ w moim skrypcie powłoki nie można go usunąć, ponieważ 6535 jest własnością root. Plik faktycznie pojawia się po uruchomieniu „rm -rf”. Próbowałem wcześniej i nie udało się usunąć katalogu, ponieważ powiedział mi, że katalog nie jest pusty. Wszedłem do środka i na pewno w końcu pojawia się plik „6535”. Nie mam pojęcia, dlaczego to robi.

strace mówi, co następuje

#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

To trochę niepokojące. Sprawdziłbym, czy Twój lsplik nie został zmodyfikowany przez porównanie ze znanym dobrym plikiem. Możesz użyć narzędzi pakietu swojej dystrybucji do zweryfikowania pliku w izolowanym systemie.

Czasami nazwy plików zawierają nieparzyste znaki, takie jak sekwencje ruchów kursora. Spróbuj tego, aby upewnić się:

ls -lq

Powinien wyświetlać znaki zapytania zamiast znaków kontrolnych (prawdopodobnie jest to ustawienie domyślne, ale może nie być).

To częściowo pokazuje rodzaj problemu, który może występować:

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

Spróbowałbym również:

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

aby sprawdzić, czy alias lub funkcja jest zdefiniowana, lub aby zobaczyć, czy plik binarny znajduje się w nieparzystym miejscu lub został zmodyfikowany.

Możesz chcieć sprawdzić ten wolumin.

Zwykle robię coś takiego, jeśli uważam, że „ls” zostało zmodyfikowane ...

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

Oczywiście Python, biblioteka C, jądro lub system plików również mogą być modyfikowane, ale zwykle jest to tylko narzędzie powłoki.

Możesz dokładnie sprawdzić, co robi ls, używając strace, a to może ci powiedzieć, dlaczego unika pokazywania tej nazwy pliku.

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

spójrz przez to i zobacz, co się dzieje.

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

Dane wyjściowe będą wyglądać następująco:

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

a jeśli zobaczysz coś takiego

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

bądź ostrożny, zostałeś uznany za ...

To nie jest rozstrzygający test, ale jest dobrym wskaźnikiem ...

(jeśli używasz systemu solaris lub innego systemu operacyjnego, może być konieczne użycie kratownicy lub innego podobnego narzędzia zamiast strace)

(jeśli używasz powłoki pochodnej csh / tcsh, prawdopodobnie będziesz potrzebować różnych instrukcji przekierowania)

Szybka aktualizacja, musieliśmy wymienić serwer z innych powodów. To był system plików. Teraz wszystko jest dobrze !!! Dziękuje wszystkim.

Teoria hacka jest interesująca, ale mam alternatywną teorię. Semantyka usuwania plików uniksowych utrzyma plik dookoła, dopóki wszystkie procesy nie zamkną otwartych uchwytów plików wskazujących na niego. Być może ktoś wstrzymał pobieranie / zatwierdzenie SVN lub wątek serwera został zawieszony. Jeśli ponowne uruchomienie procesu SVN (lub Apache) rozwiązuje twój problem, to właśnie tutaj obwiniłbym winę.

Być może możesz zidentyfikować proces, w którym nadal używasz tego pliku lsof | grep 6535?