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.
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.
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..)