Como definir o local (e o nome) do arquivo de despejo principal?

Estou no CentOS 6, tentando ativar dumps principais para um aplicativo que estou desenvolvendo. Eu coloquei:

ulimit -H -c unlimited >/dev/null
ulimit -S -c unlimited >/dev/null

no meu perfil do bash, mas um dump principal ainda não foi gerado (em um novo terminal).

Também alterei meu /etc/security/limits.conf para que os limites flexíveis sejam zero para todos os usuários.

Como faço para definir o local dos arquivos principais a serem impressos? Eu queria especificar o local e acrescentar a hora em que o despejo foi gerado, como parte do nome do arquivo?

Para definir a localização dos dumps principais no CentOS 6, você pode editar /etc/sysctl.conf. Por exemplo, se você deseja despejos principais em /var/crash:

kernel.core_pattern = /var/crash/core-%e-%s-%u-%g-%p-%t

Onde as variáveis ​​são:

% e é o nome do arquivo
% g é o gid em que o processo estava sendo executado sob
% p é o pid do processo
% s é o sinal que causou o dump
% t é o momento em que o dump ocorreu
% u é o uid em que o processo estava sendo executado

Você também tem que adicionar /etc/sysconfig/init

DAEMON_COREFILE_LIMIT='unlimited'

Agora aplique novas alterações:

$ sysctl -p

Mas há uma ressalva dessa maneira. Se o parâmetro do kernel kernel.core_pattern for sempre redefinido e substituído na reinicialização para a seguinte configuração, mesmo quando um valor for especificado manualmente em /etc/sysctl.conf:

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

Em resumo, quando o abrtd.servicearranque kernel.core_patterné substituído automaticamente pelo sistema instalado abrt-addon-ccpp. Existem duas maneiras de resolver isso:

1. Definir DumpLocationopção no /etc/abrt/abrt.confarquivo de configuração. O diretório de destino pode ser especificado configurando DumpLocation = /var/crashno /etc/abrt/abrt.confarquivo de configuração e sysctl kernel.core_patterno valor exibido é o mesmo, mas, na verdade, o arquivo principal será criado no diretório em /var/crash.

   Além disso, se você tiver o SELinux ativado, precisará executar:

   $ semanage fcontext -a -t public_content_rw_t "/var/crash(/.*)?"  
   $ setsebool -P abrt_anon_write 1
   

   E finalmente reinicie abrtd.service:

   $ service abrtd.service restart
   

2. Interrompa o serviço abrtd. kernel.core_patternnão será substituído. - (Eu nunca testei).

Para gerar o dump principal no Busybox, podemos adicionar os parâmetros abaixo no script de inicialização que executa nosso executável. Portanto, sempre que inicializamos o software e exportamos variáveis ​​de ambiente, podemos copiar as linhas abaixo para o script e despejar o núcleo, caso ocorram falhas.

Para definir o local dos dumps principais no Busybox, você pode definir o caminho do arquivo principal usando o sistema de arquivos proc. Por exemplo, se você deseja despejos principais em /tmp/crash/corefiles:

mkdir -p /tmp/crash/corefiles
chmod 775 /tmp/crash/corefiles
echo "/tmp/crash/corefiles/%e.%s.core" > /proc/sys/kernel/core_pattern

Onde as variáveis ​​são:

% e é o nome do arquivo
% g é o gid em que o processo estava sendo executado sob
% p é o pid do processo
% s é o sinal que causou o dump
% t é o momento em que o dump ocorreu
% u é o uid em que o processo estava sendo executado

Além disso, você deve definir o tamanho do arquivo principal. O comando abaixo define o tamanho do arquivo principal como ilimitado

ulimit -c unlimited

Agora, para verificar o tamanho do arquivo principal definido para cada thread em um processo, podemos verificar usando

cat /proc/<PID>/limits

A saída do comando acima:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max open files            10000                10000                files     
Max address space         unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             31868                31868                processes 
Max locked memory         65536                65536                bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       31868                31868                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us      

Como podemos ver na saída acima, o tamanho máximo do arquivo principal é definido como ilimitado.

Para mais informações, visite este link. Técnicas de depuração de aplicativos Linux / arquivos principais