URL: https://github.com/SSSD/sssd/pull/94 Title: #94: Enable {socket,dbus}-activation for responders
pbrezina commented: """ Squashing is fine, of course. BTW I'm not quite sure if this version contains the uid/gid changes as I see it as parameters in all systemd unit files. In my opinion, even private communication between responders and data providers should prolong the timeout. The communication is triggered by the client anyway. The basic idea is that when a client contacts responder, the responder contacts data provider and awaits reply. It may take a long time for the dp reply to come, but we are still not idle, we await a reply. It probably won't make much difference since we send reply to client as fast as we can when we get reply from dp so the timestamps will be similar, but we don't have to special case IFP anymore and I like that :-) What do other @SSSD/developers think? The only incoming signal SSSD can handle right now is NameOwnerChange and this should not take part in the decision whether SSSD is idle or not. All signals are handled inside `sbus_signal_handler` and should not make it into message handler, if the do I'd consider it a bug. """ See the full comment at https://github.com/SSSD/sssd/pull/94#issuecomment-264175621
_______________________________________________ sssd-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
