On Mon, 19.07.10 12:29, Stephen Gallagher (sgallagh@xxxxxxxxxx) wrote:
> I'll certainly give it some thought. My main concern is portability at
> this point. There are a lot of systems that do not (and will not)
> support systemd. I'm not sure how one would configure this socket
> activation conditionally depending on whether systemd was available.
Oh, we actually thought about that. Daemons patched for systemd support
do not lose their compatibility with non-systemd systems.
An example: previously most daemons probably did something like this, to
bind a socket:
fd = socket(...);
bind(fd, ...);
listen(fd, ...);
With systemd this becomes something like this:
n = sd_listen_fds();
if (n == 1) {
fd = SD_LISTEN_FD_START;
} else {
fd = socket(...);
bind(fd, ...);
listen(fd, ...);
}
i.e. with sd_listen_fds() you check how many file descriptors have been
passed. If there's one, you just use that socket (note that the passed
fds will be found between SD_LISTEN_FD_START (which is 3) and
SD_LISTEN_FD_START+n-1). If no fds are passed, then you just use the old
code to create the socket yourself.
This way, if your daemon is started from systemd using socket activation
you automatically make use of the passed sockets. If it is started from
another init system, or even from systemd without socket activation
enabled, then your code will work as it always did.
> I'm wary of moving to *requiring* systemd, since my intent is for SSSD
> to remain compatible with Red Hat Enterprise Linux 5 and 6 for their
> complete respective lifetimes. So if I made any move to add this
> functionality, it would have to be capable of living alongside
> traditional socket allocation (and ideally be capable of detecting this
> at run-time rather than build-time, since I don't want to enforce a
> requirement on platforms where systemd is available but not mandatory
> e.g. rawhide in its current state)
Yes, that's perfectly well supported and the recommended way to do
things. Adapting your program to systemd does not break compatbility
with sysv or upstart systems.
In fact, we tried our best to keep the machanisms as simple and
independent of systemd as possible, to make it easier for other systems
to adopt this scheme if they want to. So there's hope that even if other
init systems continue to exist that they adopt the same scheme of
activation.
So in summary: making changes to your software to adapt it to socket
activation does NOT mean you make it incompatible with other init
systems and eventually there might be other init systems actually making
use of this scheme, too.
Also note that the implementation of sd_listen_fds() above is trivial
(it just checks two env vars), and can easily be reimplemented in your
code. You have the option to either copy our reference implementation
into your tree or just reimplement that one function manually. Either
way there will be no additional library dependency (i.e. there is no
libsystemd) to your project, and hence adopting socket based activation
should not have any drawback. It's just a little feature that's not
visible to most and only shows its powers if your daemon is started via
socket activation from systemd.
Or in other words: we really tried our best to make it as easy as
possible and politically unproblematic to adopt systemd in your
project.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
