Perché questo file è nascosto quando si esegue ls?

10

EDIT: mi sono completamente dimenticato di questo thread. Si scopre che avevo un disco rigido danneggiato. Abbiamo dovuto ridistribuire questo server per altre esigenze, quindi sono finalmente riuscito a sostituire l'unico disco danneggiato e siamo di nuovo in affari.

Ormai da alcune settimane non sono riuscito a capire perché non ero in grado di eliminare questo particolare file. Come root posso, ma il mio script di shell funziona come un altro utente. Quindi vado a correre ls -la e non c'è. Tuttavia, se lo chiamo come parametro, si presenta! Abbastanza sicuro, il proprietario è root, quindi non sono in grado di eliminare.

Notare che manca 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

Ora viene visualizzato se lo chiami direttamente.

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

Ecco qualcosa di interessante Quindi ho riscontrato questo problema perché nel mio script shell, non sarebbe stato possibile eliminarlo perché 6535 è di proprietà di root. Il file viene effettivamente visualizzato dopo aver eseguito "rm -rf". L'ho provato prima e non è riuscito a rimuovere la directory poiché mi ha detto che la directory non è vuota. Entrai e guardai abbastanza sicuro, finalmente il file "6535" si presenta. Non ho idea del perché lo stia facendo.

strace dice quanto segue

#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 lo capisci, ti preghiamo di inviare un aggiornamento.

— einstiien,

Interessante. cosa viene segnalato con ls -ab? Forse qualche strano carattere non ottale è nel nome del file? Penserei di elencarlo comunque, ma non ne sono sicuro.

— egorgry,

1

Hai gestito un fsck di recente? È in remoto possibile che qualcosa si sia rotto sul filesystem.

— Zoredache,

Dovrò testarlo di nuovo domani, in partenza per la giornata.

— luckytaxi,

7

È un po 'preoccupante. Verificherei che il tuo lsfile non è stato modificato confrontandolo con un file valido noto. È possibile utilizzare gli strumenti del pacchetto di distribuzione per verificare il file su un sistema isolato.

— Ammonitore
fonte

+1: ls -al dovrebbe mostrare tutto. In caso contrario, c'è un problema da qualche parte.

— Satanicpuppy,

2

È del tutto possibile che lssia stato modificato per nascondere un PID specifico, possibilmente 6535.

— MikeyB,

No ... niente ...

— luckytaxi

6

A volte i nomi dei file contengono caratteri strani come sequenze di movimenti del cursore. Prova questo per assicurarti:

ls -lq

Dovrebbe mostrare punti interrogativi anziché caratteri di controllo (è probabilmente il valore predefinito, ma potrebbe non esserlo).

Ciò dimostra in parte il tipo di problema che può essere 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

Vorrei anche provare:

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

per vedere se è definito un alias o una funzione o per vedere se un binario si trova in un posto strano o è stato modificato.

— In pausa fino a nuovo avviso.
fonte

1

+1 buona visione. È importante notare che se lsfossero stati modificati, anche md5sumsul sistema avrebbe potuto essere potenzialmente modificato. È necessario un ambiente sano noto per verificare per raggiungere una conclusione definitiva.

— Warner,

Ho scoperto che anche se md5 è stato modificato per produrre risultati fasulli se fai cose come 'file md5' puoi comunque ottenere buoni risultati (se il programma md5 funziona) facendo qualcosa come bzip2 <file | MD5 e confrontare che per lo stesso comando altrove.

— chris,

3

Potresti voler ascoltare quel volume.

— Florin Andrei
fonte

13

questo è quello che ha detto.

— einstiien,

2

Di solito faccio qualcosa del genere se credo che 'ls' sia stato modificato ...

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

Naturalmente Python, la libreria C, il kernel, o il file system potrebbe anche essere modificati, ma di solito è solo il guscio utils.

— McJeff
fonte

2

Oppure, puoi usare l'espansione del nome file della shell per leggere la directory - echo * (e se vuoi tutto, echo *. *)

— chris

*.*ti mostrerà solo i file che hanno caratteri seguiti da un punto seguito da caratteri. Questo non è assolutamente tutto sul sistema * nix. Non sono sicuro che l'eco ti mostrerà tutto in un solo comando, sono stato in grado di farloecho * && echo .*

— einstiien

4

Se guardi da vicino, è * (spazio). *, Non *. * La punteggiatura non è il seme forte di questo sistema di commenti ... E l'eco è perfettamente felice di espandere quante più espressioni separate da "$ IFS" come ti interessa dargli da mangiare. Il booleano && non è necessario, o davvero anche molto senso, perché && è un valore booleano e e sarà sempre lavoro, perché il comando echo è sempre successo.

— chris,

@chris: il mio male, davvero difficile vederlo.

— einstiien,

2

Puoi esaminare esattamente cosa sta facendo ls usando strace, e questo potrebbe dirti perché sta evitando di mostrare quel nome file.

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

guarda quello e vedi cosa sta succedendo.

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

L'output sarà simile al seguente:

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 vedi qualcosa del genere

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

fai attenzione, sei stato cresciuto ...

Questo non è un test conclusivo, ma è un buon indicatore ...

(se stai usando Solaris o altri sistemi operativi, potrebbe essere necessario utilizzare truss o qualche altra utility simile invece di strace)

(se stai usando una shell derivata csh / tcsh, probabilmente avrai bisogno di diverse istruzioni di reindirizzamento)

— Chris
fonte

Mi piace questo. L' straceutilità è davvero un coltellino svizzero. Passa direttamente al livello di chiamata del sistema e ignora tutta una pila di complicazioni arbitrarie. È una delle prime cose che qualsiasi amministratore di sistema. vale la pena spendere su una macchina appena installata.

— McJeff,

Sì, i due strumenti più preziosi per un amministratore di sistema sono truss / strace e tcpdump. Con questi, puoi sempre guardare sotto le coperte per vedere cosa succede quando qualcosa si comporta o non si comporta come ti aspetti.

— chris,

2

Aggiornamento rapido, abbiamo dovuto sostituire il server per altri motivi. Era il filesystem. Va tutto bene adesso !!! Grazie a tutti.

— luckytaxi
fonte

Vuoi dire che il filesystem è stato rovinato e questo è stato solo un sintomo bizzarro?

— chris,

sì, era quello.

— luckytaxi,

Probabilmente potresti esserti bloccato in una modifica per dire che c'è una soluzione nell'elenco seguente, poiché è stata sepolta sotto altre risposte votate (e utili per la risoluzione dei problemi).

— Bart Silverstrim,

0

La teoria dell'hack è interessante, ma ho una teoria alternativa. La semantica di eliminazione dei file Unix manterrà il file attivo fino a quando tutti i processi non avranno chiuso gli handle di file aperti che puntano verso di esso. Forse qualcuno ha messo in pausa un checkout / commit SVN o un thread del server ha riattaccato. Se il riavvio del processo SVN (o Apache) risolve il problema, è qui che darei la colpa.

Forse puoi identificare il processo che sta ancora utilizzando questo file con lsof | grep 6535?

— jldugger
fonte

sì, non ha mostrato nulla. La cosa interessante è che 6535 è anche "mancante" nella fonte. Il mio script esegue una hotcopy del repository originale in un'altra directory. Questo è quando ho riscontrato problemi con la mancata eliminazione di questo particolare file per qualche motivo.

— luckytaxi,

Un file eliminato ma aperto non ti impedirà di eliminare la directory di contenimento perché una volta che la voce di directory viene eliminata, la voce di directory non esisterà, quindi la directory sarà vuota. Non sarà possibile recuperare lo spazio dal file fino a quando il processo che lo ha aperto non viene interrotto, ma la directory che aveva quel file ora può essere eliminata.

— chris,

La tua teoria alternativa è interessante. La rimozione, in caso di successo, rimuove immediatamente il collegamento reale. È probabile che l'inode contenga ancora i dati e alcuni handle di file potrebbero averli memorizzati nella cache, ma non credo che questo scenario possa spiegare il comportamento descritto. O, cosa ha detto Chris, eh.

— Warner,