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.