[PATCH] signal handlers setup

[Thomas Cataldo]

On Wed, Oct 12, 2011 at 3:48 PM, Henrique de Moraes Holschuh <hmh at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20111012/4da8d74f/attachment.html