¿Por qué este archivo está oculto cuando ejecuta ls?

10

EDITAR: me olvidé por completo de este hilo. Resulta que tenía un disco duro defectuoso. Tuvimos que volver a implementar este servidor para otras necesidades, por lo que finalmente pude reemplazar el disco defectuoso y volvimos al negocio.

Durante algunas semanas, no pude entender por qué no pude eliminar este archivo en particular. Como root puedo, pero mi script de shell se ejecuta como un usuario diferente. Así que voy a ejecutar ls -la y no está allí. Sin embargo, si lo llamo como parámetro, ¡aparece! Efectivamente, el propietario es root, por lo tanto, no puedo eliminarlo.

Aviso, falta 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

Ahora aparece si lo llamas directamente.

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

Aquí hay algo interesante. Entonces capté este problema porque en mi script de shell, no podría eliminar porque 6535 es propiedad de root. El archivo en realidad aparece después de ejecutar "rm -rf". Lo intenté antes y no pudo eliminar el directorio ya que me dijo que el directorio no está vacío. Entré y miré y, efectivamente, el archivo "6535" finalmente aparece. No tengo idea de por qué está haciendo esto.

strace dice lo siguiente 

#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
fuente
2
Si se da cuenta de esto, publique una actualización.
Einstiien
Interesante. ¿Qué se informa con ls -ab? ¿Quizás hay algún carácter extraño no octal en el nombre del archivo? Creo que -a lo enumeraría de todos modos pero no estoy seguro.
egorgry
1
¿Has ejecutado un fsck recientemente? Es remotamente posible que algo esté roto en el sistema de archivos.
Zoredache
Tendré que volver a probarlo mañana, dejando el día.
luckytaxi

Respuestas:

7

Eso es un poco preocupante. Verificaría que su lsarchivo no se modificó comparándolo con un archivo bueno conocido. Puede usar las herramientas de paquete de su distribución para verificar el archivo en un sistema aislado.

Warner
fuente
+1: ls -al debería mostrar todo. Si no es así, hay un problema en alguna parte.
Satanicpuppy
2
Es muy posible que lsse haya modificado para ocultar un PID específico, posiblemente 6535.
MikeyB
No ... nada ...
luckytaxi
6

A veces, los nombres de archivo tienen caracteres extraños, como secuencias de movimiento del cursor. Prueba esto para asegurarte:

ls -lq

Debería mostrar signos de interrogación en lugar de caracteres de control (es probable que sea el valor predeterminado, pero podría no serlo).

Esto demuestra parcialmente el tipo de problema que puede 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

También intentaría:

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

para ver si se define un alias o una función o para ver si un binario está en un lugar extraño o si se ha modificado.

Pausado hasta nuevo aviso.
fuente
1
+1 buena idea. Es importante tener en cuenta que si lsse modificaran, md5sumel sistema también podría haberse modificado. Necesita un entorno sano conocido para verificar y llegar a una conclusión definitiva.
Warner
Descubrí que incluso si md5 se ha modificado para producir resultados falsos si hace cosas como 'archivo md5', aún puede obtener buenos resultados (si el programa md5 funciona) haciendo algo como bzip2 <archivo | MD5 y comparar que al mismo comando en otro lugar.
Chris
3

Es posible que desee fsck ese volumen.

Florin Andrei
fuente
13
eso es lo que ella dijo.
Einstiien
2

Usualmente hago algo como esto si creo que 'ls' ha sido modificado ...

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

Por supuesto, Python, la Biblioteca C, el kernel o el sistema de archivos también podrían modificarse, pero generalmente son solo las utilidades de shell.

McJeff
fuente
2
O bien, puede usar la expansión del nombre de archivo del shell para leer el directorio - echo * (y si lo desea todo, echo *. *)
chris
*.*solo le mostrará archivos que tienen caracteres seguidos de un punto seguido de caracteres. Esto definitivamente no es todo en el sistema * nix. No estoy seguro de que echo te muestre todo en un solo comando, pude hacerloecho * && echo .*
einstiien
44
Si observa de cerca, es * (espacio). *, No *. * La puntuación no es el punto fuerte de este sistema de comentarios ... Y, echo está perfectamente feliz de expandir tantas expresiones separadas por el "$ IFS" como te importa alimentarlo. El & booleano no es necesario, o incluso tiene mucho sentido, porque && es un booleano y siempre funcionará porque el comando echo siempre es exitoso.
Chris
@ Chris: mi mal, muy difícil de ver eso.
Einstiien
2

Puede ver exactamente qué está haciendo ls usando strace, y eso puede decirle por qué evita mostrar ese nombre de archivo.

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

mira eso y ve lo que está pasando.

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

La salida se verá así:

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

y si ves algo como

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

ten cuidado, has sido 0wned ...

Esta no es una prueba concluyente, pero es un buen indicador ...

(si está utilizando Solaris u otros sistemas operativos, es posible que deba usar truss u otra utilidad similar en lugar de strace)

(si está utilizando un shell derivado de csh / tcsh, es probable que necesite diferentes declaraciones de redirección)

Chris
fuente
Me gusta esto. La straceutilidad realmente es una navaja suiza. Llegas directamente al nivel de llamada del sistema y evitas un montón de complicaciones arbitrarias. Es una de las primeras cosas que cualquier administrador del sistema. vale la pena pagar en una máquina recién instalada.
McJeff
Sí, las dos herramientas más valiosas para un administrador de sistemas son truss / strace y tcpdump. Con estos, siempre puede mirar debajo de las sábanas para ver qué sucede cuando algo se comporta o no de la manera esperada.
Chris
2

Actualización rápida, tuvimos que reemplazar el servidor por otras razones. Era el sistema de archivos. Todo está bien ahora! Gracias a todos.

Luckytaxi
fuente
¿Quieres decir que el sistema de archivos estaba jodido y esto era solo un síntoma loco?
Chris
Sí, eso fue todo.
luckytaxi
Probablemente podría haberse atascado en una edición para decir que hay una solución en la lista a continuación, ya que está enterrada debajo de otras respuestas votadas (y útiles para solucionar problemas).
Bart Silverstrim
0

La teoría del hack es interesante, pero tengo una teoría alternativa. La semántica de eliminación de archivos de Unix mantendrá el archivo hasta que todos los procesos hayan cerrado los identificadores de archivos abiertos que lo apuntan. Tal vez alguien ha pausado un checkout / commit de SVN, o ha colgado un hilo del servidor. Si reiniciar el proceso SVN (o Apache) resuelve su problema, aquí es donde culparía.

¿Quizás pueda identificar el proceso con este archivo que todavía usa lsof | grep 6535?

jldugger
fuente
sí, lsof no mostró nada. Lo interesante es que 6535 también "falta" en la fuente. Mi script hace una copia en caliente del repositorio original a otro directorio. Fue entonces cuando tuve problemas con la imposibilidad de eliminar este archivo en particular por alguna razón.
luckytaxi
Un archivo eliminado pero abierto no le impedirá eliminar el directorio que contiene porque una vez que se elimina esa entrada del directorio, la entrada del directorio no existirá, por lo que el directorio estará vacío. No recuperará el espacio del archivo hasta que se elimine el proceso que lo tiene abierto, pero el directorio que tenía ese archivo ahora se puede eliminar.
Chris
Su teoría alternativa es interesante. La eliminación, si tiene éxito, eliminaría instantáneamente el enlace duro. Es probable que el inodo aún contenga los datos y algunos identificadores de archivos pueden tenerlo en la memoria caché, pero no creo que este escenario pueda explicar el comportamiento descrito. O, lo que dijo Chris, je.
Warner