SIGUSR1 handler only restarts notion if it returns to the mainloop

[wilhelmy]

I've been bitten by this twice so far, quitting the ibus tray icon makes notion hang. Notion offers a feature to restart itself if it is killed with SIGUSR1, but the signal handler only sets a global flag that SIGUSR1 has been received, and notion keeps being stuck further down the call stack without ever returning to the main loop.

I think we should add another signal for emergency restarts when the mainloop is unresponsive.

[wilhelmy]

I propose SIGSTKFLT ("stack fault on coprocessor (unused)" according to signal(7)) since indeed the stack is at fault.

[raboof]

Interesting. We could also use SIGHUP for the 'graceful restart' and SIGUSR1 for 'emergency restart'?

[wilhelmy]

I'm not sure about SIGHUP since it's used at least by ssh to terminate the running program, so it might also be used as such by some session managers? I don't know, though.

SIGUSR2 is already in use for something else, apparently. I guess we should add a SIGNALS section to the manpage, too.

[raboof]

I'm not sure about SIGHUP since it's used at least by ssh to terminate the running program

Not too uncommon to have it mean 'reload config' (https://en.wikipedia.org/wiki/Signal_(IPC)#SIGHUP), though indeed 'restart' is a bit different.

I guess we should add a SIGNALS section to the manpage, too.

Yes!

[wilhelmy]

Not too uncommon to have it mean 'reload config' (https://en.wikipedia.org/wiki/Signal_(IPC)#SIGHUP), though indeed 'restart' is a bit different.

As far as I know only for daemons which are not normally bound to a session, although it's a bit unclear.

[wilhelmy]

We might also be able to use SIGRTMIN..SIGRTMAX but I don't know how portable those are.
Edit: Seems they are part of POSIX.1-2001 and reserved for application specific use.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html