Should we catch signals that could cause semaphores to leak?

[jbaublitz]

We recently bumped into a problem where stratisd was leaking semaphores on SIGTERM. Should we add in signal handling for the semaphore code?

@bmr-cymru @mulkieran Curious on your thoughts.

[bmr-cymru]

Generally it's more common for libraries to leave signal handling to the calling application - e.g. this is what happens in lvm2/libdevmapper. Whenever lvm2 is holding a VG lock it blocks signals (this encompasses DM device activation as well as things like metadata updates). If we followed that approach in Stratis then stratisd would block signals before operating on DM devices.

Alternately we could try to handle this internally in devicemapper but give users the ability to opt out if they want to do their own signal handling. I think that's possible and would mean changing UdevSync to block/unblock signals around operations. This could be gated by a feature for clients that don't want that behaviour.

The only thing I'm uncertain of is how this will interact with threading - if I remember correctly blocked signals are per-thread, so by blocking signals in the thread that's processing a DM operation we'd still have the possibility of SIGTERM/SIGINT being delivered to another thread in the process. I'm not certain what would happen in this case and whether we'd need to block signals in other threads (or in the main thread before starting other threads) to prevent an abrupt termination of stratisd.