linux之哪个进程正在发送SIGKILL_编程设计

在我的linux系统中，我有一个守护进程，该守护进程很早启动(在启动过程中)。
引导过程中的守护程序只是初始化g_dbus名称。
具体来说:

        guint id = g_bus_own_name ( G_BUS_TYPE_SESSION, 
                            DBUS_NAME, 
                            G_BUS_NAME_OWNER_FLAGS_NONE, 
                            bus_acquired_handler, 
                            name_acquired_handler, 
                            name_lost_handler, 
                            NULL, 
                            NULL);

但令我惊讶的是，我总是这样:

        ##### deliver signal SIG : 9, [BT]<Process Name>#1(679) get_signal_to_deliver 
        ##### deliver signal SIG : 9, [BT]<Process Name>#2(681) get_signal_to_deliver

我也尝试过这个:

        dmesg | grep -i 'killed process'

但是问题是，dmesg是空的。 (我认为这是有目的的)

我还在过程中检查了全局和静态变量，没有分配的大内存。此外，也没有内存泄漏

我的进程在系统中也具有root权限，因此这也不是问题。

最后一点。从systemd(此守护程序的)自动重启两次或之后，完全没有问题。

有人可以帮助您了解这种行为吗？这样我就可以修复。

请您参考如下方法:

我解决了我的问题。
尽管我不是该主题的专家，但是这是我的解决方法，它为我提供了正在发生的结论。

首先是解决方案，然后我们将尝试推理。

检查系统总线是否启动:

          while(conn==NULL) { 
             dbus_bus_get(DBUS_BUS_SYSTEM,&err); 
             if(dbus_error_is_set(&err)){ 
                 usleep(1000*50); 
              }

之后，只需获取系统总线:

    guint id = g_bus_own_name ( G_BUS_TYPE_SYSTEM, 
                        DBUS_NAME, 
                        G_BUS_NAME_OWNER_FLAGS_NONE, 
                        bus_acquired_handler, 
                        name_acquired_handler, 
                        name_lost_handler, 
                        NULL, 
                        NULL);

现在没有信号，守护进程可以顺利运行。

现在说吧。
我认为，早些时候我试图获取 session 总线，但在启动时并未创建 session 总线，因此内核向我的进程发送了信号9。因此，我转而使用系统总线，它比 session 总线要早得多。
此外，在获得系统总线之前，还要确保system_bus已启动并因此解决方案。

在我看来，要回答哪个进程正在发送sigkill，就没有特别的进程。它来自内核本身。

希望这对其他人也有用。