Wo kann man nachschauen, wenn eine dämonisierte Version eines Programms abstürzt?

Ich habe ein C++ - Programm, das Streaming-Musik empfängt und spielt. Ich kann das Programm über die Shell ausführen und damit verbunden laufen und es läuft völlig in Ordnung. Ich kann Audio dorthin streamen und Dinge dorthin schicken, aber es wird nicht abstürzen. Wenn ich es jedoch dämoniere und den Fork-Code ausführe, stürzt es nach ein wenig Streaming unerwartet ab. Ich versuche, gdb zu verwenden, um es zu debuggen, aber es gibt nicht viel Ausgabe.Wo kann man nachschauen, wenn eine dämonisierte Version eines Programms abstürzt?

./bin/sonar -d ; sleep 1 ; gdb ./bin/sonar $(cat sonar.pid) 
GNU gdb (GDB) 7.4.1-debian 
Copyright (C) 2012 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying" 
and "show warranty" for details. 
This GDB was configured as "arm-linux-gnueabihf". 
For bug reporting instructions, please see: 
<http://www.gnu.org/software/gdb/bugs/>... 
Reading symbols from /var/sonar/bin/sonar...done. 
Attaching to program: /var/sonar/bin/sonar, process 4050 
Reading symbols from /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so...(no debugging symbols found)...done. 
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so 
Reading symbols from /var/sonar/bin/../lib/libboost_system.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_system.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_chrono.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_chrono.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_timer.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_timer.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_iostreams.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_iostreams.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_thread.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_thread.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_log_setup.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_log_setup.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_log.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_log.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_filesystem.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_filesystem.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_atomic.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_atomic.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_date_time.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_date_time.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libboost_regex.so.1.60.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libboost_regex.so.1.60.0 
Reading symbols from /var/sonar/bin/../lib/libopus.so.0...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libopus.so.0 
Reading symbols from /var/sonar/bin/../lib/libmysql.so.16...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libmysql.so.16 
Reading symbols from /var/sonar/bin/../lib/libmysqlpp.so.3...(no debugging symbols found)...done. 
Loaded symbols for /var/sonar/bin/../lib/libmysqlpp.so.3 
Reading symbols from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0...(no debugging symbols found)...done. 
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0 
Reading symbols from /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0...(no debugging symbols found)...done. 
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.0 
Reading symbols from /usr/lib/arm-linux-gnueabihf/libasound.so.2...(no debugging symbols found)...done. 
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libasound.so.2 
Reading symbols from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6...(no debugging symbols found)...done. 
Loaded symbols for /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
Reading symbols from /lib/arm-linux-gnueabihf/libm.so.6...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libm-2.19.so...done. 
done. 
Loaded symbols for /lib/arm-linux-gnueabihf/libm.so.6 
Reading symbols from /lib/arm-linux-gnueabihf/libgcc_s.so.1...(no debugging symbols found)...done. 
Loaded symbols for /lib/arm-linux-gnueabihf/libgcc_s.so.1 
Reading symbols from /lib/arm-linux-gnueabihf/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libpthread-2.19.so...done. 
[Thread debugging using libthread_db enabled] 
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". 
[New Thread 0x749ff450 (LWP 4054)] 
[New Thread 0x75358450 (LWP 4053)] 
[New Thread 0x75b58450 (LWP 4052)] 
done. 
Loaded symbols for /lib/arm-linux-gnueabihf/libpthread.so.0 
Reading symbols from /lib/arm-linux-gnueabihf/libc.so.6...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libc-2.19.so...done. 
done. 
Loaded symbols for /lib/arm-linux-gnueabihf/libc.so.6 
Reading symbols from /lib/arm-linux-gnueabihf/librt.so.1...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/librt-2.19.so...done. 
done. 
Loaded symbols for /lib/arm-linux-gnueabihf/librt.so.1 
Reading symbols from /lib/arm-linux-gnueabihf/libbz2.so.1.0...(no debugging symbols found)...done. 
Loaded symbols for /lib/arm-linux-gnueabihf/libbz2.so.1.0 
Reading symbols from /lib/arm-linux-gnueabihf/libz.so.1...(no debugging symbols found)...done. 
Loaded symbols for /lib/arm-linux-gnueabihf/libz.so.1 
Reading symbols from /lib/arm-linux-gnueabihf/libdl.so.2...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libdl-2.19.so...done. 
done. 
Loaded symbols for /lib/arm-linux-gnueabihf/libdl.so.2 
Reading symbols from /lib/ld-linux-armhf.so.3...(no debugging symbols found)...done. 
Loaded symbols for /lib/ld-linux-armhf.so.3 
Reading symbols from /lib/arm-linux-gnueabihf/libnss_files.so.2...Reading symbols from /usr/lib/debug/lib/arm-linux-gnueabihf/libnss_files-2.19.so...done. 
done. 
Loaded symbols for /lib/arm-linux-gnueabihf/libnss_files.so.2 
0x763e1d14 in epoll_wait() at ../sysdeps/unix/syscall-template.S:81 
81  ../sysdeps/unix/syscall-template.S: No such file or directory. 
(gdb) c 
Continuing. 

Program received signal SIGABRT, Aborted. 
[Switching to Thread 0x75358450 (LWP 4053)] 
0x7633df70 in raise() from /lib/arm-linux-gnueabihf/libc.so.6 
(gdb) bt 
#0 0x7633df70 in raise() from /lib/arm-linux-gnueabihf/libc.so.6 
#1 0x7633f324 in abort() from /lib/arm-linux-gnueabihf/libc.so.6 
#2 0x7656eb5c in __gnu_cxx::__verbose_terminate_handler()() from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
#3 0x7656c9a0 in ??() from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
#4 0x7656c9a0 in ??() from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 
Backtrace stopped: previous frame identical to this frame (corrupt stack?) 
(gdb) c 
Continuing. 
[Thread 0x762ac000 (LWP 4050) exited] 
[Thread 0x75b58450 (LWP 4052) exited] 
[Thread 0x749ff450 (LWP 4054) exited] 

Program terminated with signal SIGABRT, Aborted. 
The program no longer exists. 
(gdb)

Der daemonizing Code, die ich benutze:

// Daemonize 
LOG_INFO(*logger) << "Daemonizing."; 

// Sig stuff 
pid_t pid, sid; 

// Start the forky pig 
if((pid = fork())<0) 
{ 
    LOG_ERROR(*logger) << "Error forking: " << strerror(errno); 
    return(EXIT_FAILURE); 
} 

// The parent can go home 
if(pid>0) 
    return(EXIT_SUCCESS); 

// Make ourselves emancipate 
if((sid = setsid())<0) 
{ 
    LOG_ERROR(*logger) << "setsid error: " << strerror(errno); 
    return(EXIT_FAILURE); 
} 

// Ignore sigpipes 
signal(SIGPIPE, SIG_IGN); 

// Close the file descriptors to detach 
close(STDIN_FILENO); 
close(STDOUT_FILENO); 
close(STDERR_FILENO);

Wenn das Programm funktioniert wenn es nicht daemonisierte und stürzt ab, wenn es ist, gibt es offensichtlich einen Unterschied in der Art und Weise, dass es läuft. Also meine Frage ist wirklich, wo kann ich nach diesem besonderen Punkt des Scheiterns suchen?

Hier ist der gleiche Fehler auf einem 64-Bit-Intel-arch Prozessor:

Program received signal SIGABRT, Aborted. 
[Switching to Thread 0x7f80777b8700 (LWP 10314)] 
0x00007f807baa7297 in __GI_raise ([email protected]=6) at ../sysdeps/unix/sysv/linux/raise.c:55 
55  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. 
(gdb) bt 
#0 0x00007f807baa7297 in __GI_raise ([email protected]=6) at ../sysdeps/unix/sysv/linux/raise.c:55 
#1 0x00007f807baa862a in __GI_abort() at abort.c:89 
#2 0x00007f807c5a700d in __gnu_cxx::__verbose_terminate_handler()() from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 
#3 0x00007f807c5a4e96 in ??() from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 
#4 0x00007f807c5a4ee1 in std::terminate()() from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 
#5 0x00007f807c600c21 in ??() from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6 
#6 0x00007f807be16324 in start_thread (arg=0x7f80777b8700) at pthread_create.c:333 
#7 0x00007f807bb5bf6d in clone() at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Quelle

2016-04-12 Mikey A. Leonetti

Sie sind nicht genügend Informationen zeigen, ein Problem zu diagnostizieren. Bitte versuchen Sie, Ihr Symptom mit einem [MCVE] (http://stackoverflow.com/help/mcve) zu reproduzieren, und wenn das Ihnen nicht hilft, das Problem zu identifizieren, kommen Sie hier zurück und veröffentlichen das minimale Programm und erklären das Problem erneut. – jxh

Stellt sich heraus, dass es ein Absturz der Protokolldatei war. Ich habe den Wurffehler nicht gesehen, weil der Fehler beim Logging-System selbst aufgetreten ist. Da alle Verbindungen zu Stdout unterbrochen waren, wurde nichts angezeigt. Es war genau das Problem in diesem Beitrag mit Boost.Log:

Boost Log causes crash when trying first log statement (when not Administrator)

Quelle

2016-04-15 22:37:48

es ein Unterschied darin, ein Verfahren in einer interaktiven Umgebung oder als Daemon in läuft. Wenn Sie einen Prozess über die Befehlszeile ausführen, erbt der Prozess alle Ressourcen aus der interaktiven Umgebung wie Pfade, die in PATH-Umgebungsvariablen definiert sind, oder sogar das Arbeitsverzeichnis, bei dem es sich in einer interaktiven Umgebung um das tatsächliche Verzeichnis handelt, aus dem a Prozess wird gestartet.

Ohne Ihr System oder Ihre Umgebung zu kennen, ist einer der Fehler, die oft gemacht werden, den Hintergrundprozess zu starten, daemons, zum Beispiel von einer Crontab, aber vergessen, die Informationen zu geben, die ein Prozess braucht. Wenn ein Prozess als Daemon ausgeführt wird, ohne die Umstände Ihres Arbeitsablaufs zu kennen, ist es beispielsweise notwendig, dem Prozess die Umgebung zu geben, um nur eines zu nennen, das Arbeitsverzeichnis. Ich mache das zum Beispiel mit "chdir ("/");" so weiß das gegabelte Kind, in welchem Arbeitsverzeichnis er aktiv ist.

Abhängig von Ihren anderen Ressourcen sollten Sie dem Daemon alle Informationen geben, die er benötigt, um seine Aufgabe zu erfüllen, z. wenn es einen Prozess startet, zum Beispiel der PATH zum Prozess und so weiter.

grüße

Quelle

2016-04-15 09:07:35 Coliban

Dies ist eine sehr gute Antwort, und ich schätze Ihre Antwort. Ich habe ein Problem damit, keine guten Fragen stellen zu können, also danke ich Ihnen, dass Sie sich die Zeit genommen haben, den Beitrag zu schreiben. –

Wo kann man nachschauen, wenn eine dämonisierte Version eines Programms abstürzt?

Antwort

Verwandte Themen