Hola compañeros de la shell,
En esta entrada vamos a revisar que aspectos tendremos que tener en cuenta a la hora de modificar la configuración de generación de cores. Pero antes de abordar cómo modificar la configuración de la generación de cores por parte del Sistema Operativo, vamos a responder de manera muy breve a las siguientes preguntas:
¿Para qué nos sirve un core?
Principalmente, un core nos servirá para investigar porqué el proceso que lo escribió terminó en error de manera inesperada usando para ello técnicas de debug etc.
¿Por qué modificar la configuración que ofrece el S.O. por defecto?
La respuesta a esta pregunta es el motivo por el que escribir esta entrada. A continuación la respuesta a la misma dividida, como en otras entradas, por S.O. (GNU/Linux & Solaris).
1. Configurar generación de core en GNU/Linux.
Primero, modificaremos la configuración por defecto porque es muy posible que la generación de cores esté desactivada en la máquina. Si la ejecución de ulimit (o ulimit -c) devuelve 0 para el tamaño máximo de fichero core, no se generarán cores:
ulimit -a | grep core core file size (blocks, -c) 0
Podemos moficar el parámetro, solamente para la shell actual:
ulimit -c unlimited ulimit -a | grep core core file size (blocks, -c) unlimited
O realizar un cambio permanente mediante la modificación del fichero /etc/security/limits.conf
Bien, una vez hemos modificado el límite que permite la generación de cores, podremos comprobar el patrón de generación de dichos ficheros leyendo el contenido del fichero /proc/sys/kernel/core_pattern , que, por defecto es:
cat /proc/sys/kernel/core_pattern core
Dependiendo de nuestras necesidades, el valor por defecto puede ser perfectamente el que deseemos, pero debemos ser conscientes de que con esta configuración:
1. El fichero core se generará en el path desde el que se lance el proceso que lo genere. Por ejemplo:
pwd /home # vi prueba.txt Vim: Caught deadly signal QUIT Vim: Finished. Quit (core dumped) # ls -ltr core -rw------- 1 root root 3497984 nov 1 17:24 core
2. Si el mismo programa (suponemos que se lanza desde el mismo path), se lanza varias veces generando varios cores, estos se irán machacando y solo conservaremos el último. Por ejemplo, si generamos un nuevo core lanzando vim desde el mismo path, machacaremos el anterior core:
vi prueba.txt Vim: Caught deadly signal QUIT Vim: Finished. Quit (core dumped) # ls -ltr core -rw------- 1 root root 3502080 nov 1 17:28 core
Como apuntabamos anteriormente, la configuración por defecto sería conveniente siempre y cuando seamos conscientes y nos convenga el hecho de que los cores se generen desde el path desde el que lancemos el programa que lo genere y que se irán machacando si hay coincidencia.
Dicho esto, otra configuración en la que no se machaquen los cores generados (para recoger toda la información posible) y agrupar la generación de cores en un mismo filesystem no crítico (para evitar llenados de filesystem en los fs’s en los que corran nuestros programas) parece más razonable.
El fichero de configuración en GNU/Linux a modificar para adaptar el sistema a nuestras necesidades sería /proc/sys/kernel/core_pattern.
Por defecto:
cat /proc/sys/kernel/core_pattern core
Como apuntabamos anteriormente, la configuración por defecto generará el core en el directorio desde el que se lanzó el programa y dicho core será reescrito llegado el caso.
Si quisiéramos generar los cores en un fs específico con otro formato, por ejemplo, podríamos el contenido de /proc/sys/kernel/core_pattern a:
cat /proc/sys/kernel/core_pattern /almacen_cores/core%p%t
A continuación el extracto de man core que describe los patrones a usar para adaptar el nombre de core a nuestras necesidades:
Naming of core dump files
By default, a core dump file is named core, but the /proc/sys/kernel/core_pattern file (since Linux 2.6 and 2.4.21) can be set to define a template that is used to name core dump files. The template can contain % specifiers
which are substituted by the following values when a core file is created:
%% a single % character
%p PID of dumped process
%u (numeric) real UID of dumped process
%g (numeric) real GID of dumped process
%s number of signal causing dump
%t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)
%h hostname (same as nodename returned by uname(2))
%e executable filename (without path prefix)
%E pathname of executable, with slashes (‘/’) replaced by exclamation marks (‘!’).
%c core file size soft resource limit of crashing process (since Linux 2.6.24)
Texto completo (man core).
P.D.: Para generar un core de prueba bastaría con:
vi prueba kill -ABRT pid_vi_prueba
El core de prueba generado fue:
core.vim.89839.hosttest.11.1559831306
Además, en GNU/Linux podemos generar el core de un proceso en ejecución mediante:
gcore PID
Espero que os sirva de ayuda.
Nos vemos al otro lado de la pantalla negra.
