Linux blocking signals to Python init

前端 未结 2 2032
醉话见心
醉话见心 2021-02-14 13:43

This is a follow up to my other post Installing signal handler with Python. In short, Linux blocks all signals to PID 1 (including SIGKILL) unless Init has installed a signal h

相关标签:
2条回答
  • 2021-02-14 14:05

    The issue was a compatibility issue with Python compiled against uClibc 0.9.31 with old linux threads. Compiling against 0.9.32-rc3 and using NPTL has fixed the issue.

    0 讨论(0)
  • 2021-02-14 14:07

    I did a bit of debugging under KVM and I found that the kernel is delivering signals to pid 1 when the signal handlers are installed by the standard signal module. However, when the signal is received "something" causes a clone of the process to be spawned, rather than printing the expected output.

    Here is the strace output when I send HUP to the non-working init.sig-mod:

    strace output

    Which results in a new process running (pid 23) which is a clone of init.sig-mod:

    clone of init as pid 23

    I didn't have time to dig deeper into the cause, but this narrows things further. Probably something to do with Python's signal delivery logic (it registers a C hook which invokes your bytecode function when called). The ctypes technique bypasses this. The relevant Python source files are Python/pythonrun.c and Modules/signalmodule.c, in case you want to take a closer look.

    Old Info -- I'm not sure this will solve your problem, but might get you closer. I compared these different ways signal handlers are installed:

    • Installing a handler via Python's signal module.
    • Upstart's signal handlers.
    • Using ctypes to call the signal() syscall directly.
    • Some quick tests in C.

    Both the ctypes-invoked signal() system call and Upstart's sigaction() syscalls set the SA_RESTART flag when the handler is registered. Setting this flag indicates that when a signal is received while the process is executing or blocking inside certain syscalls (read, write, wait, nanosleep, etc), after the signal handler completes the syscall should be automatically restarted. The application won't be aware of this.

    When Python's signal module registers a handler, it zeros the SA_RESTART flag by calling siginterrupt(signum, 1). This says to the system "when a system call is interrupted by a signal, after the signal handler completes set errno to EINTR and return from the syscall". This leaves it up to the developer to handle this and decide whether to restart the system call.

    You can set the SA_RESTART flag by registering your signal this way:

    import signal
    signal.signal(signal.SIGHUP, handler)
    signal.siginterrupt(signal.SIGHUP, False)
    
    0 讨论(0)
提交回复
热议问题