Ignore SIGUSR1 and SIGUSR2

Some day there may be features bound to these signals.

For now, ignore those -- this gives a period of time when sending
SIGUSR1 and SIGUSR2 to a labwc process is safe, before someone may
implement way to activate features bound to these signals.

Related-to: #1700
This commit is contained in:
Tomi Ollila 2024-05-06 08:10:30 +03:00
parent a7298314a4
commit 174ddfcdc3
2 changed files with 14 additions and 0 deletions

View file

@ -23,6 +23,8 @@ reset_signals_and_limits(void)
/* Restore ignored signals */ /* Restore ignored signals */
signal(SIGPIPE, SIG_DFL); signal(SIGPIPE, SIG_DFL);
signal(SIGUSR1, SIG_DFL);
signal(SIGUSR2, SIG_DFL);
} }
static bool static bool

View file

@ -328,6 +328,18 @@ server_init(struct server *server)
*/ */
signal(SIGPIPE, SIG_IGN); signal(SIGPIPE, SIG_IGN);
/*
* Some day in the future, signal handlers may be assigned to these
* SIGUSR? signals. To give users a chance to develop extensions bound
* to these signals, make signalling labwc with SIGUSR[12] "safe" by
* ignoring these signals (as one may accidentally SIGUSR a labwc
* process not supporting such extensions).
* When signal handler assignment(s) is made, the corresponding
* signal(SIGUSR?, SIG_DFL); call(s) in spawn.c can be removed.
*/
signal(SIGUSR1, SIG_IGN);
signal(SIGUSR2, SIG_IGN);
/* /*
* The backend is a feature which abstracts the underlying input and * The backend is a feature which abstracts the underlying input and
* output hardware. The autocreate option will choose the most suitable * output hardware. The autocreate option will choose the most suitable