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

Pavel Březina pbrezina at redhat.com
Mon Jul 7 09:47:28 UTC 2014


On 07/02/2014 10:36 AM, Jakub Hrozek wrote:
> On Tue, Jul 01, 2014 at 10:34:11AM +0200, Pavel Březina wrote:
>> 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?
>
> No, currently the IFP responder only tries once and if it fails, it
> doesn't retry until the bus activation.
>
>>
>>>
>>> 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.
>
> I think so too, but I was thinking about the following scenario:
>      1) sssd_nss, sssd_pam and sssd_be start up early. Network is not yet
>        up
>      2) some service started after sssd resolves a sssd user. sssd tries
>        to connect, which might take some time depending on the conditions
>        and eventually sssd goes offline
>      3) messagebus starts up, resets the offline status
>      4) another service does 2) all over again
>      ....
>      N) network is finally up
>
> But I think this won't be a problem at least in the general case because
> most services user local UNIX users anyway and even if sssd was queried,
> the timeouts during boot would be quite fast because /etc/resolv.conf
> would be empty before NM/dhcpd starts.
>
>>
>>> 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.
>
> I will start a separate thread also with #2351 in mind.
>
> New patches are attached, this time I consider them ready for review, so
> I'll remove the RFC tag.

LGTM
Can you just add a debug message that will say that ifp_sysbus_reconnect 
is executed?




More information about the sssd-devel mailing list