C++ 如果我使用正在运行的守护进程重新启动或关闭系统，该守护进程使用fanotify控制对文件的访问，系统将冻结

我让我的守护进程使用FanotifyAPI来控制对文件的访问。以下是工作线程：

void * threadProc( void * data )
{
    if( data == NULL ) return 0;

    RealTimeDrvrImp & _this = *( ( RealTimeDrvrImp * )data );

    const unsigned int fi_flags = FAN_CLOEXEC | FAN_CLASS_CONTENT | FAN_NONBLOCK;
    const unsigned int fi_event_f_flags = O_RDONLY | O_LARGEFILE;

    _this.m_fa_fd = fanotify_init( fi_flags, fi_event_f_flags );
    if (-1 == _this.m_fa_fd )
        return NULL;

    const unsigned int fm_flags = FAN_MARK_ADD | FAN_MARK_MOUNT;
    const uint64_t fm_event_f_flags = FAN_OPEN_PERM /*| FAN_ACCESS_PERM*/ /*| FAN_CLOSE_WRITE*/;

    if (-1 == fanotify_mark( _this.m_fa_fd, fm_flags, fm_event_f_flags, 0, "/" ) )
    {
        close( _this.m_fa_fd );
        return NULL;
    }

    char buf[4096];
    int len = 0;
    struct timespec tmsp = { 0, 1000000 };//500 miliseconds
    pid_t self_pid = getpid();

    while( _this.m_DoAvRealtimeScanThread )
    {
        if(-1 == ( len = read(_this.m_fa_fd, (void *) &buf, sizeof (buf))) )
        {
            if( EAGAIN == errno )
            {
                nanosleep( & tmsp, NULL );
                continue;
            }
            else
                break;
        }
        const struct fanotify_event_metadata *metadata
                = (struct fanotify_event_metadata *) buf;    

        while (FAN_EVENT_OK(metadata, len)) {
            if (metadata->fd != FAN_NOFD ) {
                if (metadata->fd >= 0)
                {
                    bool bCloseFdNow = true;

                    if(  metadata->mask & FAN_OPEN_PERM ||
                        metadata->mask & FAN_ACCESS_PERM )
                    {
                        bool bWriteNow = true;
                        struct fanotify_response response = {0,0};
                        response.fd = metadata->fd;
                        response.response = FAN_ALLOW;

                        if( metadata->pid == self_pid )
                        {//this process event, always allow
                        }
                        else if( _this.IsReplyReadyNow( response ) )
                        {//response.response is set in IsReplyReadyNow();
                        }
                        else //else event is added to a queue, 
                             //will be handled and closed later in another thread
                        {
                            bCloseFdNow = false;
                            bWriteNow = false;
                        }

                        if( bWriteNow )
                        {
                            pthread_mutex_lock( & _this.m_faWriteMtx );
                            write( _this.m_fa_fd, &response, sizeof (struct fanotify_response ) );
                            pthread_mutex_unlock( & _this.m_faWriteMtx );
                        }

                    }
                    if( bCloseFdNow )
                        close( metadata->fd );
                }
            }
            metadata = FAN_EVENT_NEXT(metadata, len);
        }
     }

    close( _this.m_fa_fd );
    _this.m_fa_fd = -1;    
    return NULL;
}

它工作正常。如果在重新启动或关闭之前停止守护进程，一切都正常。但是，如果我试图重新启动系统或关闭正在运行的守护进程，系统将冻结

我认为系统可能会在重新启动/关闭时向其守护进程发送SIGSTOP，对吗？如果是这样，守护进程将不允许对任何文件进行任何访问并锁定系统

请帮忙

---

我在内核3.11.0中使用Ubuntu 12.04 64位。

我找到了它被阻止的原因

显然，在重新启动时，linux会集中访问由我的守护进程控制的文件。在_this.IsReplyReadyNow（）调用中必须允许每次访问，该调用反过来使用几个syslog（）调用来记录文件系统事件。在我的一些条目出现后，在syslog中重新启动时，出现以下消息：

'由于速率限制，imuxsock开始从中删除邮件'

在此之后，我的守护进程被阻止，并停止以允许或拒绝文件访问权限，从而阻止了系统

---

当我注释掉syslog（）调用时，系统最终重新启动。

我相信我看到SIGKILL被发送到守护进程。我可能也错了。是的，我也这么认为，但与此同时，守护进程是否以某种方式被挂起？在重新启动期间，其他用户进程是如何停止的？也许你可以跟着。可能会打开浏览器并启动重新启动。根据您的初始化脚本，守护进程通常会看到一个SIGTERM（15），然后是一个SIGKILL（9）。在没有init脚本的情况下，当

upstart

决定它已经有足够的非终止进程时，您将只看到SIGKILL。