comando - descriptores de archivos linux

archivos core dump en Linux: ¿cómo obtener información sobre archivos abiertos?

Question

Tengo un archivo de volcado de núcleo de un proceso que probablemente tiene una fuga de descriptor de archivo (abre archivos y tomas de corriente, pero al parecer a veces se olvida de cerrar algunas de ellas). ¿Hay alguna forma de averiguar qué archivos y conectores se abrió antes de colapsar el proceso? No puedo reproducir fácilmente el bloqueo, por lo que analizar el archivo central parece ser la única forma de obtener una pista sobre el error.

Answer 1

Otra forma de averiguar qué archivos ha abierto un proceso, de nuevo, solo durante el tiempo de ejecución, es buscar en / proc / PID / fd /, que contiene enlaces simbólicos para abrir archivos.

Answer 2

Puede intentar usar strace para ver las llamadas open , de socket y de close hace el programa.

Editar: no creo que puedas obtener la información del núcleo; a lo sumo tendrá los descriptores de archivos en alguna parte, pero esto aún no le da el archivo / socket real. (Suponiendo que pueda distinguir descriptores de archivos abiertos y cerrados, lo cual también dudo).

Answer 3

Si el programa olvidó cerrar esos recursos, podría ser porque sucedió algo como lo siguiente:

fd = open("/tmp/foo",O_CREAT);
//do stuff
fd = open("/tmp/bar",O_CREAT); //Oops, forgot to close(fd)

ahora no tendré el descriptor de archivo para foo en la memoria.

Si esto no sucedió, es posible que pueda encontrar el número de descriptor de archivo, pero, una vez más, eso no es muy útil porque están cambiando continuamente, cuando llega el momento de la depuración no sabrá qué archivo significa realmente en el momento.

Realmente creo que deberías depurar este en vivo, con strace, lsof y amigos.

Si hay una forma de hacerlo desde el volcado del núcleo, estoy ansioso por saberlo también :-)

Answer 4

Su mejor opción es instalar un manejador de señal para cualquier señal que bloquee su programa (SIGSEGV, etc.).

Luego, en el controlador de señal, inspeccione / proc / self / fd, y guarde los contenidos en un archivo. Aquí hay una muestra de lo que podría ver:

Anderson cxc # ls -l  /proc/8247/fd
total 0
lrwx------ 1 root root 64 Sep 12 06:05 0 -> /dev/pts/0
lrwx------ 1 root root 64 Sep 12 06:05 1 -> /dev/pts/0
lrwx------ 1 root root 64 Sep 12 06:05 10 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 Sep 12 06:05 11 -> socket:[124061]
lrwx------ 1 root root 64 Sep 12 06:05 12 -> socket:[124063]
lrwx------ 1 root root 64 Sep 12 06:05 13 -> socket:[124064]
lrwx------ 1 root root 64 Sep 12 06:05 14 -> /dev/driver0
lr-x------ 1 root root 64 Sep 12 06:05 16 -> /temp/app/whatever.tar.gz
lr-x------ 1 root root 64 Sep 12 06:05 17 -> /dev/urandom

Luego puede regresar de su manejador de señal, y debería obtener un volcado de memoria como de costumbre.

Answer 5

Un volcado de núcleo es una copia de la memoria a la que el proceso tuvo acceso cuando se estrelló. Dependiendo de cómo se está produciendo la fuga, puede haber perdido la referencia a las asas, por lo que puede resultar inútil.

lofda enumera todos los archivos actualmente abiertos en el sistema, puede verificar su salida para encontrar sockets o archivos filtrados. Sí, necesitarías tener el proceso en ejecución. Puede ejecutarlo con un nombre de usuario específico para discernir fácilmente cuáles son los archivos abiertos del proceso que está depurando.

Espero que alguien más tenga mejor información :-)

Answer 6

Si tiene un archivo central y ha compilado el programa con las opciones de depuración (-g), puede ver dónde se descargó el núcleo:

$ gcc -g -o something something.c
$ ./something
Segmentation fault (core dumped)
$ gdb something core

Puede usar esto para hacer una depuración post-mortem. Algunos comandos de gdb: br imprime la pila, fr salta al marco de pila dado (vea la salida de br).

Ahora, si quiere ver qué archivos se abren en una falla de segmentación, simplemente maneje la señal SIGSEGV, y en el manejador, simplemente descargue el contenido del directorio / proc / PID / fd (es decir, con el sistema (''ls -l / proc / PID / fs '') o execv).

Con estas informaciones a mano, puede encontrar fácilmente qué causó el bloqueo, qué archivos se abren y si se conectan el bloqueo y la fuga del descriptor de archivo.

Answer 7

Una de las formas en que paso a esta información es simplemente ejecutar strings en el archivo central. Por ejemplo, cuando estaba ejecutando un archivo en un núcleo recientemente, debido a la longitud de las carpetas obtendría una lista de argumentos truncados. Sabía que mi ejecución habría abierto archivos desde mi directorio personal, así que simplemente ejecuté:

strings core.14930|grep jodie

Pero este es un caso donde tuve una aguja y un pajar.

Answer 8

Recientemente, durante mi solución de problemas de resolución de problemas y análisis, mi cliente me proporcionó un coredump que se generó en su sistema de archivos y se salió de la estación para escanear rápidamente el archivo y leer sus contenidos. Utilicé el comando

cadenas core.67545> coredump.txt y más tarde pude abrir el archivo en el editor de archivos.