regression in signal handling in nslink.py

[jhjensen]

Experiencing this regression requires the application to: use namespaces, asyncio, and register a SIGTERM handler.

In 4420185675b9ca9f71f7110653ee77b957ebbbcb nslink.py was changed to signal TERM instead of KILL.

We use asyncio so it sets signal.set_wakeup_fd. Our application has a TERM signal handler. We are monitoring routing in another namespace.

The fork in init leaves the file descriptors shared. When the nslink is closed the SIGTERM is sent to the child. The childs internal python handler queues it to the FD.
The parent and the child then race to read the FD When the parent wins our registered signal handler runs, shutting down our application.

Previous to this patch the child would just die.

We have several work arounds. The one I suggest to you is calling signal.set_wakeup_fd(-1) signal.signal(signal.SIGTERM, signal.SIG_DFL) # or a signal handler specific to the child. in the child fork in nslink.py.

[svinota]

Can a configurable signal on the library side help in this situation?

[jhjensen]

Sorry I didn't get back to this, I don't log into github very often.

I expect that it could, but it would probably mean future users in this uncommon situation would probably need to debug this very puzzling condition, and find the documentation for changing the configuration. The documentation would need to say why to choose which signal.

It seems to me that the the child is fully owned by nslink and that changes there that further differentiate it from the main process are safest.