Il file di dump di base non viene generato

Question

Ogni volta che l'applicazione si arresta, un file di dump di base non viene generato. Ricordo che alcuni giorni fa, su un altro server è stato generato . Sono in esecuzione l'applicazione utilizzando schermo in bash come questo:

#!/bin/bash 
ulimit -c unlimited 
while true; do ./server; done 

Come potete vedere sto usando ulimit -c unlimited che è importante se voglio generare un core dump, ma ancora non generarla, quando ho avuto un errore di segmentazione. Come posso farlo funzionare?

Answer 1

Assicurarsi che la directory corrente (al momento dello schianto - server possa cambiare directory) sia scrivibile. Se il server chiama setuid, la directory deve essere scrivibile dall'utente.

Controllare anche /proc/sys/kernel/core_pattern. Ciò potrebbe reindirizzare core dump in un'altra directory e che la directory deve essere scrivibile. Maggiori informazioni here.

Answer 2

Verificare inoltre di disporre di spazio su disco sufficiente su /var/core o in qualsiasi punto in cui i core dump vengano scritti. Se la partizione è piena di almos o al 100% di utilizzo del disco, questo sarebbe il problema. I miei core dump hanno una durata media di alcuni concerti quindi dovresti essere sicuro di avere almeno 5-10 gig disponibili sulla partizione.

Answer 3

This link contiene una buona lista perché core dump non vengono generati:

• Il nucleo sarebbe stato maggiore del limite di corrente.
• Non si dispone delle autorizzazioni necessarie per eseguire il dump core (directory e file). Si noti che i dump di core sono collocati nella directory corrente del processo di dumping che potrebbe essere diversa dal processo principale.
• Verificare che il file system sia scrivibile e che disponga di spazio sufficiente.
• Se una directory secondaria denominata core esiste nella directory di lavoro, nessun core verrà scaricato.
• Se un file denominato core esiste già ma ha più collegamenti fisici, il kernel non eseguirà il dump del core.
• Verificare le autorizzazioni sull'eseguibile, se l'eseguibile ha i dump core abilitati per bit suid o sgid per impostazione predefinita disabilitati. Lo stesso accadrà se hai le autorizzazioni di esecuzione ma non hai le autorizzazioni di lettura sul file.
• Verificare che il processo non abbia modificato la directory di lavoro, il limite della dimensione del core o il flag dumpable.
• Alcune versioni del kernel non possono eseguire il dump dei processi con spazio di indirizzamento condiviso (thread AKA). Le versioni più recenti del kernel possono scaricare tali processi, ma aggiungeranno il pid al nome del file.
• L'eseguibile potrebbe essere in un formato non standard che non supporta core dump. Ogni formato eseguibile deve implementare una routine core dump.
• L'errore di segmentazione potrebbe effettivamente essere un kernel Oops, controllare i log di sistema per qualsiasi messaggio di Oops.
• L'applicazione denominata exit() invece di utilizzare il gestore di core dump.

Answer 4

Check:

$ sysctl kernel.core_pattern 

per vedere come sono create le discariche (% e sarà il nome del processo, e% t sarà l'ora di sistema).

Se si dispone di Ubuntu, i dump vengono creati da apport in /var/crash, ma in formato diverso (modificare il file per vederlo).

È possibile effettuare delle prove:

sleep 10 & 
killall -SIGSEGV sleep 

Se un core dumping è successo, si vedrà “(core dumped)” dopo la segnalazione di errore di segmentazione.

Per saperne di più:

How to generate core dump file in Ubuntu

---

Ubuntu

Si prega di leggere di più su:

https://wiki.ubuntu.com/Apport

Answer 5

Anche se questo non è andare essere un problema per la persona che ha posto la domanda, perché hanno eseguito il programma che doveva produrre il file core in uno script con il comando ulimit, mi piacerebbe documentare che il comando ulimit è specifico per la shell in cui lo esegui (come le variabili di ambiente). Ho passato troppo tempo a eseguire ulimit e sysctl e roba in una shell, e il comando che volevo eseguire il core nell'altra shell, chiedendomi perché il file core non fosse stato prodotto.

Lo aggiungerò alla mia base. Il sysctl funziona per tutti i processi una volta emesso, ma l'ulimit funziona solo per la shell in cui viene rilasciato (forse anche i discendenti), ma non per altre shell che sono in esecuzione.

Answer 6

Nota: se è stato scritto manualmente un gestore di crash, il core potrebbe non essere generato. Così la ricerca di codice con qualcosa sulla linea:

signal(SIGSEGV, <handler>); 

in modo che il SIGSEGV sarà gestito da conduttore e non sarà possibile ottenere il core dump.

Answer 7

Ricordare che se si sta avviando il server da un servizio, verrà avviata una sessione di bash diversa in modo che l'ulimit non sia efficace lì. Prova a mettere questo in tuo script stesso:

ulimit -c unlimited 

Answer 8

Le risposte qui riportati coprono abbastanza bene la maggior parte degli scenari per i quali non è stato creato core dump. Tuttavia, nel mio caso, nessuno di questi è stato applicato. Sto postando questa risposta come aggiunta alle altre risposte.

Se il file principale non viene creato per qualsiasi motivo, consiglio di guardare/var/log/messages. Potrebbe esserci un suggerimento sul motivo per cui il file core non è stato creato.Nel mio caso c'era una linea che indica la causa principale:

Executable '/path/to/executable' doesn't belong to any package 

Per aggirare il problema modificare /etc/abrt/abrt-action-save-package-data.conf e cambiare ProcessUnpackaged dal 'no' a ' sì'.

ProcessUnpackaged = yes 

Questa impostazione specifica se creare il nucleo per i file binari non installati con il gestore pacchetti.

Answer 9

Se si chiama daemon() e quindi si demone un processo, per impostazione predefinita la directory di lavoro corrente verrà modificata in /. Quindi se il tuo programma è un demone allora dovresti cercare un core nella directory / e non nella directory del binario.

Answer 10

Se uno è su una distribuzione Linux (ad esempio CentOS, Debian), allora il modo più accessibile per scoprire i file principali e le condizioni correlate è nella pagina man. Basta eseguire il seguente comando da terminale:

man 5 core 

Answer 11

Per la cronaca, su Debian 9 Stretch (systemd), ho dovuto installare il pacchetto systemd-coredump. Successivamente, i core dump sono stati generati nella cartella /var/lib/systemd/coredump.

Inoltre, questi file numerici sono compressi nel formato lz4. Per decomprimere, è possibile utilizzare il pacchetto liblz4-tool in questo modo: lz4 -d FILE.

Per essere in grado di eseguire il debug del coredump decompresso utilizzando gdb, ho anche dovuto rinominare il tutto lungo il nome del file in qualcosa di più corto ...