[HEADS-UP] The systemd unit files I'll post

[Lennart Poettering]

On Mon, 19.07.10 11:33, Stephen Gallagher (sgallagh at redhat.com) 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.