[SSSD] [RFC] [PATCH] Retry system bus connection once messagebus is up

Pavel Březina pbrezina at redhat.com
Tue Jul 1 08:34:11 UTC 2014


On 06/25/2014 01:32 PM, Jakub Hrozek wrote:
> Hi,
>
> the attached (unpolished, see my question below) patches fix
> https://fedorahosted.org/sssd/ticket/2360
> also known as:
> https://bugzilla.redhat.com/show_bug.cgi?id=1110369
>
> Let me explain the problem first -- if SSSD starts before messagebus is
> up, the InfoPipe responder fails to start and doesn't retry, so the
> system bus service is simply not there.
>
> A simple solution would be to start messagebus before SSSD. But I don't
> think that is a robust solution, because the messagebus configuration
> can reference user names, which the SSSD provides. So at the time
> messagebus is up, the identities should be resolvable -- which means the
> NSS responder and the back ends must be up.
>
> The attached patches take advantage of bus activation messagebus
> provides. If the interface InfoPipe provides is not registered on the
> bus when requested, messagebus signals the sssd, which tells the IFP
> responder to retry the system bus connection.

The patches looks good to me. Do you also plan error counter so we can 
fail if we can't establish the connection for a longer time?

>
> Currently, the WIP patches use sss_debuglevel which sends HUP to the
> sssd process, but I think USR2 (aka "go online") would be better. So the
> final patch version would include a helper binary that would do nothing
> but singal the monitor..

> I have one question to discuss though.. is it OK to use signals for the
> IPC? An alternative might be to let IFP spawn a client socket and implement
> only a single 'command' to retry the connection. But that seems like an
> overkill to me. The disadvantage of the signal is that it's also used to
> reset the online status so in theory there might be some timeouts in the
> offline case, though.

I think semantics of "go online" signal is exactly what we want here. We 
can also send USR2 directly to the ifp responder to avoid possible timeouts.

> In the 1.13 timeframe, we will be implementing socket-based activation.
> I think it would be nice to make the IFP responder bus-activated as part
> of that effort. But in the traditional schema where monitor manages all
> the processes, the changes to make InfoPipe bus-activated instead of
> managed by the monitor would be too invasive (I've tried to do that
> yesterday..)

I agree.





More information about the sssd-devel mailing list