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

Jan Pazdziora jpazdziora at redhat.com
Fri Jun 27 06:13:12 UTC 2014


On Wed, Jun 25, 2014 at 01:32:58PM +0200, Jakub Hrozek wrote:
> 
> 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.
> 
> 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.

My uninformed view is that signals are a good start. Something else
than HUP might be useful.

-- 
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat



More information about the sssd-devel mailing list