当程序的守护程序版本崩溃时在哪里查看?

Where to look when a daemonized version of a program crashes?

我有一个 C++ 程序可以接收流式音乐并播放它。我可以 运行 通过 shell 和 运行 附加的程序 运行 完全没问题。我可以将音频流式传输到它并向它发送内容,但它不会崩溃。然而,当我守护它和 运行 分叉代码时,它会在一点点流式处理后意外崩溃。我尝试使用 gdb 对其进行调试,但它并没有提供太多输出。

./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)

我使用的守护代码:

// 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 );

如果程序在未被守护进程时运行,而在被守护进程时崩溃,那么它 运行 的方式显然有些不同。所以我的问题是,我在哪里可以找到这个特定的故障点?

在 64 位 intel arch 处理器上出现同样的错误:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f80777b8700 (LWP 10314)]
0x00007f807baa7297 in __GI_raise (sig=sig@entry=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 (sig=sig@entry=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

运行在交互式环境中或作为守护程序运行进程是有区别的。当您从命令行 运行 一个进程时,该进程将从交互式环境中继承所有资源,例如在环境 PATH 变量中定义的路径,甚至是工作目录,即在交互式环境中,实际进程启动的目录。

在不了解您的系统或环境的情况下,经常犯的错误之一是试图启动后台进程、守护进程,例如从 crontab 启动,但忘记提供进程工作所需的信息。当一个进程 运行 宁作为守护进程时,在不知道你的工作流程的情况下,例如,我有必要给进程提供环境,更不用说工作目录了。例如,我使用 "chdir("/");",所以分叉的 child 将知道他在哪个工作目录上处于活动状态。

根据你的其他资源,你应该给守护进程所有的信息,它需要完成它的工作,例如如果它启动了某个进程,例如进程的 PATH 等等。

问候

原来是日志文件崩溃。我没有看到抛出错误,因为错误出在日志系统本身。由于与 stdout 的所有联系都被切断,因此没有显示任何内容。这正是 post 与 Boost.Log:

中的问题