[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