On Mon, 19.07.10 11:33, Stephen Gallagher (sgallagh@xxxxxxxxxx) wrote: > Hmm, unfortunately I'm not sure that this will work with SSSD as it > currently exists. SSSD as a service needs to be running as early in the > boot process as it can be brought up, because it is is possible that > other services will require its ability to serve up users and groups. Yes, and that will work just fine with socket activation, because the socket is established very early during bootup and the clients can then just connect to that socket, without having sssd necessarily already started up. This is the great thing about socket activation: the dependencies just go away, and ordering of stuff becomes mostly irrelevant. One of the key features of systemd is that you don't have to do anything special anymore to make sure that sssd is available before the clients. It just happens automatically and the kernel orders everything for us, to the degree this is atcually necessary, and not a tiny bit more. And that is awesome for parallelization! > Furthermore, there are advanced features of the SSSD that require it to > be running even before any clients connect (or even if they never do). > For example, we have an internal facility that can monitor and refresh > kerberos tickets for the LDAP server connection. This happens > irrespective of whether a client has actually ever connected. So the > SSSD cannot be started on-demand. As I already wrote, on-demand starting is not relevant for sssd. However, the other items are: - if you use socket based actviation we can start ssd at the same time as the clients which want to acces it! - the need to order sssd in the startup and provide proper dependencies goes away! - and things become more robust because sssd can be restarted or crash and no client request is lost. And this is why sssd should adopt socket base activation! Note again: if you understood socket based activation simply as scheme to do on-demand starting of daemons, then you misunderstood things. The point is parallelization, simplicty and robustness. And optinally, in a few cases on-demand starting is also handy. But in the general case this is actually out of focus! i.e. we already patched syslog, and dbus for socket based activation -- even though (much like sssd) it will have to be started at boot very early. Because this allows us to start the syslog and dbus daemons at the same time as the clients that use them (let's say udisks), and everything will just work. It would be great if sssd would adopt socket based activation, because then we could start syslog, sssd and let's say an ssd client "foo", all in one big step, instead of having to run them serially. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
