Há algum tempo atrás, ainda em Manaus, lembro-me do Thiago perguntando “Existe algo como uma variável de ambiente COREDUMP_DIR?” Após alguma discussão sobre a viabilidade e uma rápida pesquisa, ele mesmo descobriu que não só é possÃvel especificar um diretório, mas também onde e com que nome o kernel 2.6 deve guardar os arquivos de core-dump.
Para isso basta gravar uma máscara em /proc/sys/kernel/core_pattern de até 64 caracteres usando as seguintes variáveis:
%% o caracter '%'
%p PID do processo
%u UID real do processo
%g GID real do processo
%s número do sinal que causou o dump
%t hora do dump (em segundos desde 00:00h de 1970-jan-01)
%h nome do host
%e nome do arquivo executável do processo
Já o arquivo /proc/sys/kernel/core_uses_pid, bem mais antigo e mantido por questões de compatibilidade, controla se os arquivos de core devem ter ou não anexados a seu nome o PID do processo, sendo ignorado caso %p seja usado no core_pattern.
Por exemplo, para ter a máscara /var/tmp/corefiles/%e-%t-sig%s.core, sem PID, basta executar:
echo /var/tmp/corefiles/%e-%t-sig%s.core > /proc/sys/kernel/core_pattern
echo 0 > /proc/sys/kernel/core_uses_pid
Ou melhor ainda, adicionar a /etc/sysctl.conf:
kernel.core_pattern=/var/tmp/corefiles/%e-%t-sig%s.core
kernel.core_uses_pid=0
Se seu ambiente é multiusuário ou você espera gerar cores de um mesmo nome de processo com uma frequência maior do que de uma vez por segundo, recomendo a máscara /var/tmp/corefiles/%e-%t-%p-sig%s.core.
Algumas dicas:
- Lembre-se de deixar o diretório destino com stick-bit (
chmod 1777) para que multiplos usuários possam ter seus cores guardados de maneira segura;
- Se seus programas não estão gerando core, verifique seu
ulimit (comando ulimit -c e configuração em /etc/security/limits.conf);
- Pra testar, você pode usar um script bash contendo o comando
kill -s SIGSEGV $$.
Mais informações em linux/Documentation/sysctl/kernel.txt
