Come impostare il percorso (e il nome) del file di dump principale?

Sono su CentOS 6, cercando di abilitare i core dump per un'applicazione che sto sviluppando. Ho messo:

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

nel mio profilo bash, ma un dump core non è stato ancora generato (in un nuovo terminale).

Ho anche cambiato il mio /etc/security/limits.conf in modo che i limiti software siano zero per tutti gli utenti.

Come posso impostare la posizione dei file core da emettere? Volevo specificare la posizione e aggiungere l'ora in cui è stato generato il dump, come parte del nome del file?

Per impostare la posizione dei core dump in CentOS 6 è possibile modificare /etc/sysctl.conf. Ad esempio, se si desidera eseguire il dump core in /var/crash:

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

Dove sono le variabili:

% e è il nome file
% g è il gid in cui il processo era in esecuzione sotto
% p è il pid del processo
% s è il segnale che ha causato il dump
% t è il tempo in cui si è verificato il dump
% u è il uid in cui il processo era in esecuzione

Inoltre devi aggiungere /etc/sysconfig/init

DAEMON_COREFILE_LIMIT='unlimited'

Ora applica nuove modifiche:

$ sysctl -p

Ma c'è un avvertimento in questo modo. Se il parametro kernel kernel.core_pattern viene sempre resettato e sovrascritto al riavvio alla seguente configurazione anche quando un valore viene specificato manualmente in /etc/sysctl.conf:

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

In breve quando abrtd.servicestart kernel.core_patternviene sovrascritto automaticamente dal sistema installato abrt-addon-ccpp. Esistono due modi per risolvere questo problema:

1. DumpLocationOpzione di impostazione nel /etc/abrt/abrt.conffile di configurazione. La directory di destinazione può essere specificata impostando DumpLocation = /var/crashnel /etc/abrt/abrt.conffile di configurazione e sysctl kernel.core_patternil valore visualizzato è lo stesso, ma in realtà il file core verrà creato nella directory in /var/crash.

   Inoltre se hai SELinux abilitato devi eseguire:

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

   E infine riavviare abrtd.service:

   $ service abrtd.service restart
   

2. Interrompere il servizio Abrtd. kernel.core_patternnon verrà sovrascritto. - (Non ho mai provato).

Per generare core dump su Busybox possiamo aggiungere i seguenti parametri nello script di inizializzazione che esegue il nostro eseguibile. Pertanto, ogni volta che inizializziamo il software ed esportiamo le variabili di ambiente, possiamo copiare le righe sottostanti nello script e scaricare il core nel caso in cui si verifichino crash.

Per impostare la posizione dei dump principali in Busybox è possibile impostare il percorso del file core utilizzando il file system proc. Ad esempio, se desideri core dump in /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

Dove sono le variabili:

% e è il nome file
% g è il gid in cui il processo era in esecuzione sotto
% p è il pid del processo
% s è il segnale che ha causato il dump
% t è il tempo in cui si è verificato il dump
% u è il uid in cui il processo era in esecuzione

Inoltre, devi impostare la dimensione del file core, sotto il comando imposta la dimensione del file core su illimitata

ulimit -c unlimited

Ora per verificare la dimensione del file core impostata per ogni thread all'interno di un processo che possiamo verificare usando

cat /proc/<PID>/limits

L'output del comando precedente:

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      

Come possiamo vedere dall'output sopra, la dimensione massima del file core è impostata su illimitata.

Per maggiori informazioni, visita questo link. Tecniche di debug di applicazioni Linux / file core