archivos de volcado del núcleo en Linux: ¿cómo obtener información sobre los 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

Un volcado del 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.

lsof enumera todos los archivos actualmente abiertos en el sistema, puede verificar su salida para encontrar los 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 tiene una mejor información :-)

Answer 2

Usted puede intentar usar strace para ver la open, socket y close llama al programa hace.

Editar: No creo que pueda obtener la información desde el 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 los descriptores de archivos abiertos y cerrados, lo cual también dudo).

Answer 3

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 4

Si el programa se olvidó de cerrar esos recursos puede ser debido a algo como lo siguiente: pasó

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

ahora no voy a tener el descriptor de fichero 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, para cuando se depure no sabrá qué archivo que realmente significaba en ese momento.

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

Si hay una manera de hacerlo desde el volcado de memoria, estoy ansioso por saberlo también :-)

Answer 5

Su mejor opción es instalar un manejador de señales por cualquier señal está chocando su programa (SIGSEGV , etc.)

Luego, en el controlador de señal, inspeccione/proc/self/fd, y guarde los contenidos en un archivo. Este es un ejemplo de lo que puede llegar:

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 volver a su manejador de la señal, y usted debe obtener un volcado de memoria, como de costumbre.

Answer 6

Si usted tiene un archivo de núcleo y que ha compilado el programa con debuging opciones (-g), se puede ver donde se descargó el núcleo:

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

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

Ahora, si desea ver qué archivos se abren en un error de segmentación, simplemente maneje la señal SIGSEGV, y en el controlador, simplemente voltee 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 el fallo y la fuga del descriptor de archivo están conectados.

Answer 7

Una de las formas en que paso a esta información es simplemente ejecutando 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. Yo sabía que mi carrera habría abierto los archivos del directorio de mi casa, así que acaba de ejecutar:

strings core.14930|grep jodie 

pero este es un caso en el que tenía una aguja y un pajar.

Answer 8

Recientemente durante mi solución de problemas y análisis de errores, mi cliente me proporcionó un volcado de núcleo que consiguió genera en su sistema de archivos, el cual salió de la estación con el fin de explorar rápidamente a través del archivo y leer su contenido i utiliza el comando

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