On Mon, Jan 05, 2015 at 06:48:29PM +0100, Pavel Reichl wrote:
On 11/12/2013 11:32 AM, Jakub Hrozek wrote:
>On Tue, Nov 12, 2013 at 11:15:17AM +0100, Sumit Bose wrote:
>>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
>OK, pushed those three to master.
>_______________________________________________
>sssd-devel mailing list
>sssd-devel(a)lists.fedorahosted.org
>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Hello, I'm having some troubles compiling SSSD 1-11 when Samba 4.1.14-1 is
installed.
These problem seem to be solved when patch 'Signals: Remove unused
functions' is applied.
Can we push it to 1-11 branch?
I don't have a problem with pushing a patch that removes unused static
functions, although Samba really shouldn't export non-namespaced
functions.
Is that another manifestation of:
https://bugzilla.samba.org/show_bug.cgi?id=11033
?
pushed to sssd-1-11 btw:
fea2d8c6aef70f1ba6f7528c261606eac4fcea1c