[PATCH] signal handlers setup
Henrique de Moraes Holschuh
hmh at debian.org
Wed Oct 12 09:48:58 EDT 2011
On Tue, 11 Oct 2011, Greg Banks wrote:
> On 11/10/11 16:57, Bron Gondwana wrote:
> > On Tue, Oct 11, 2011 at 02:51:25AM +0200, Thomas Cataldo wrote:
> >> While testing some java code that executes cyrus init script, I came into a
> >> problem : the Java VM blocks SIGQUIT, event when using -Xrs parameter.
[...]
> >> --- a/master/master.c
> >> +++ b/master/master.c
> >> @@ -1064,7 +1064,11 @@ void sigalrm_handler(int sig __attribute__((unused)))
> >> void sighandler_setup(void)
> >> {
> >> struct sigaction action;
> >> -
> >> + sigset_t all_signals;
> >> +
> >> + sigfillset(&all_signals);
> >> + sigprocmask(SIG_UNBLOCK, &all_signals, NULL);
> >> +
> >> sigemptyset(&action.sa_mask);
> >> action.sa_flags = 0;
[...]
> FWIW I don't see any point explicitly unblocking all the signals,
> including ones other than the ones we're about to explicitly setup
> handlers for, but that's probably harmless.
IMHO we're better off unblocking just what we'll handle, better safe than
sorry. If we're not going to handle it and we don't expect it, better to
never unblock them.
In fact, if there are signals we _want_ blocked, it is best to explicitly do
just that as well.
> Also, as a defensive programming measure it's probably a good idea to
> memset() that struct sigaction to zero rather than explicitly initialise
> some of its members.
Agreed.
Thomas, could you respin the patch to only unblock the interesting
signals, and zero-fill struct sigaction?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
More information about the Cyrus-devel
mailing list