On Tue, Nov 12, 2013 at 10:45:48AM +0100, Jakub Hrozek wrote:
On Tue, Nov 12, 2013 at 10:27:48AM +0100, Sumit Bose wrote:
> On Mon, Nov 11, 2013 at 02:37:39PM -0500, Simo Sorce wrote:
> > On Mon, 2013-11-11 at 17:33 +0100, Sumit Bose wrote:
> > > On Mon, Nov 11, 2013 at 08:56:12AM -0500, Simo Sorce wrote:
> > > > On Mon, 2013-11-11 at 09:20 +0100, Sumit Bose wrote:
> > > > > On Sat, Nov 09, 2013 at 04:26:36PM -0500, Simo Sorce wrote:
> > > > > > While checking if our custom signal handlers properly
handle errno, I
> > > > > > stumbled on a few cleanups, they are attached.
> > > > > >
> > > > > > turns out our few signal hanlders are errno safe, and
tevent signal
> > > > > > handling function is also fine.
> > > > > >
> > > > > > Simo.
> > > > > >
> > > > > > --
> > > > > > Simo Sorce * Red Hat, Inc * New York
> > > > >
> > > > >
> > > > > > From 8244f7619c5042dc45751ce3bbff75f2dbc03e05 Mon Sep 17
00:00:00 2001
> > > > > > From: Simo Sorce <simo(a)redhat.com>
> > > > > > Date: Sat, 9 Nov 2013 16:11:04 -0500
> > > > > > Subject: [PATCH 2/3] Signals: Remove empty sig_hup
> > > > > >
> > > > > > SIGHUP handling is simply not implemented, so just block
the signal instead of
> > > > >
> > > > > it is, see te_server_hup() and the usage is documented in the
sssd man
> > > > > page.
> > > > >
> > > > > > using a fake handler.
> > > >
> > > > Ok does it mean I need to remove the part where I block the signal ?
> > >
> > > no, but you have to unblock it in server_setup() and if it is harmless
> > > to unblock a signal twice I would unblock it in monitor_process_init()
> > > before calling tevent_add_signal() as well.
> > >
> > > > Do you have any other comment ?
> > >
> > > no, but I still need to test them.
> > >
> > > > The sig_hup(int sig) function *was* useless ? Or is it there as a
place
> > > > holder until te_server_hup() takes over ?
> > >
> > > no, I think the common patter here is to block everything in
> > > setup_signals() and then unblock the signal when the related
> > > tevent_add_signal() is called.
> >
> > Ok after looking more carefully at how we setup the tevent handlers for
> > SIGHUP I just reverted the part of the patch that would block the
> > signal, it makes no sense to block it just to revert the action a few
> > microseconds later.
> >
> > New patch 0002 attached.
>
> Thank you. With this patch SSSD receives and handles all documented
> signals.
>
> ACK
>
> While testing I came across an oddness which we might want to fix. The
> sssd_be processes can receive SIGUSR1 individually and go offline. But
> the SIGUSR2 is not handled by sssd_be directly but only by the monitor
> which then send a reset offline request to all backends. Shall sssd_be
> handle SIGUSR2 as well?
>
> bye,
> Sumit
Which patches should be pushed? #1 and #3 from the original mail and #2
from the follow up?
yes
bye,
Sumit
(on a tangent: Can we please always resend all patches?)
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel