On Wed, Oct 12, 2011 at 3:48 PM, Henrique de Moraes Holschuh <h...@debian.org
> wrote:
> 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?
>
Ok I'll adjust that tonight & resubmit a version that only unblocks the
signals cyrmaster handles.
Thanks for your feedback.
