Discussion:
D-Bus system services: systemd, Upstart, the future
(too old to reply)
Simon McVittie
2011-08-30 14:49:18 UTC
Permalink
Lennart, Scott, any thoughts on this? Sorry, but I'm not going to merge
anything init-system-related into dbus until we have a plan that works for
everyone - or failing that, a plan that works for everyone who talked to us,
and can at least theoretically work for the other systems.

Archive link in case you missed the initial mail:

http://lists.freedesktop.org/archives/dbus/2011-August/014617.html
Current systemd/D-Bus integration (Fedora 15)
=============================================
* merged upstream in D-Bus but apparently Lennart wants to change it
See also <https://bugs.freedesktop.org/show_bug.cgi?id=40409>.
Comments? Alternative proposals? Half-bricks? Cakes?
On #40409, Lennart proposes (via a patch) making the system dbus-daemon
read systemd service files. This solves the "duplicate information" thing
for (e.g.) Fedora packages (which can omit the D-Bus service file knowing that
they have systemd), but upstreams of portable projects would still need to
ship the D-Bus service file anyway, to remain compatible with
sysvinit/Upstart/other.

Regards,
S
Lennart Poettering
2011-09-02 02:16:13 UTC
Permalink
On Thu, 11.08.11 19:06, Simon McVittie (***@collabora.co.uk) wrote:

Heya,

Sorry for not responding earlier, but you can scare me easily with long
mails like this ;-)
- some people have Upstart, but Upstart can run sysvinit scripts, so
the lowest-common-denominator for upstreams is to ship an init script
- some people have runit/daemontools/..., they get to keep both pieces :-P
- problem: systemd and Upstart both work better if you give them native
job formats, but we're giving them init scripts instead; this is
silly
Many upstream packages ship native systemd unit files these days, your
example Avahi for example does. And in Fedora 16 we have have converted
*all* init scripts to systemd unit files. My plan for Fedora 17 is to
have all bus services converted too.
Current systemd/D-Bus integration (Fedora 15)
=============================================
* merged upstream in D-Bus but apparently Lennart wants to change it
Not change, just add an additional, simpler mechanism. The additional,
simpler mechanism will be useful for systemd where compat with legacy
init systems is not necessary, since we basically get rid of the dbus
.service files. (i.e. Debian and suchlike who want to support multiple
init systems simultaneously will still have to ship a dbus .service file
for those systems).
* System services which *don't* want to start on boot may ship a systemd
unit anyway, and just not symlink it
* Activatable system services require a dbus-1 system service definition,
which is a keyfile
- to glue it to the systemd unit, it includes the name of the systemd
unit
- problem: duplicate information in two files
* Service activation is done by systemd if the dbus-1 system service
definition specifies a systemd unit, or by dbus-daemon-launch-helper
otherwise
- problem: services end up with different environment/management
Well, we cannot set a per-service environment in D-Bus, hence the
differences in the exec context are actually minimal. systemd cleans
things a bit better up before execing and getppid() will be 1 for
services spawned via systemd, but that should be it.
Proposal 1: D-Bus service files are how you define D-Bus system services
========================================================================
* if you like starting things during early boot, you can already put them
in /lib/dbus-1/system-services (thanks to a merged patch from Lennart)
* Maybe borrow a concept from systemd by also searching
/etc/dbus-1/system-services, with highest precedence and some way
to say "include the corresponding file from /lib"?
* If you have separate /usr, the init system should tell dbus-daemon to
ReloadConfig after you mount it
I think we prepped the ground well enough now so that we can kill off this
idea entirely.

Splitting off /usr split is fine, as long as it is mounted in the
initrd. This is a consensus the big distributions have now agreed on,
and it is implemented this way at least on Fedora and SUSE. Splitting
off /usr and expecting it to be mounted after the initrd is not
supported anymore, and we should not think about it anymore.

Or in other words: if you want a split off /usr, then use an initrd
which mounts it for you before you jump into the real system. Split off
/usr without initrd is not supported. Due to this I am no longer pushing
my patches that allow D-Bus to be started without /usr around.
* AllowMethodCallsFromConsole? AllowMethodCallsFromGroups?
at_console needs to die.
Proposal 2: dbus-daemon calls out to the init system
====================================================
In this proposal, dbus-daemon delegates ListActivatableNames to the
init implementation and... that's about it.
Upstreams become sad, because they have to ship some combination of
a traditional D-Bus service file, a systemd unit, an Upstart job and an
init script, sufficient to cover every OS they want to target, possibly
with different names. This is basically why I don't like this
approach.
Well, the feature set of the init systems is very different. Trying to
use D-Bus service files as abstraction for service files because you
feel the need to support a gazillion of different init systems is a really
bad idea. The focus should be to design a sane system here, not one that
tries to make everybody happy where it is clear that not everybody can
be made happy.

It is my explicit intention to unify all kinds of services we have under
the umbrella of systemd. If it traditionally was a sysv service, an
inetd service, a bus service or a cron job (of a certain kind) shouldn't
matter anymore, it should now just be a systemd service configured with
the same simple configuration language with the same powerful options,
and the same supervisor, regardless under which category it was
previously sorted. Whether it uses the bus or uses sockets is just an
implementation detail. It is also an implementation detail whether a
service is activated at boot, by sockets, by the bus, by hotplug, by
file creation, by timers or multiple of these triggers at the same
time. In fact, many daemons will use multiple communication interfaces,
and have a number of triggers (Avahi for example uses the bus, and a
local AF_UNIX socket (for the NSS stuff) and is pulled in by hw, by
socket and by bus activation).

So from my perspective Proposal 2 is the only way to go. Proposal 1 is
not at all interesting for us. It would place D-Bus in the focus and
pretend there was something specific about a "D-Bus service", which
however is not the case. There are just "services", some of which happen
to speak D-Bus, among various other communication technologies.

I can understand that you care for Debian, and its interest in supporting
every init system on this planet. But I think it's Debian's job to do
the work, and should not cause us to fuck up the design of D-Bus and the
OS.

Or to put this in even other words: the time of supporting all kinds of
compatibilty syntaxes for services is over for us. systemd is not an
abstraction layer for various service definition files. Right now, in
systemd we only support one legacy format: SysV init scripts, because it
is so deeply entrenched that we cannot really go without it. However
even for that we are slowly getting ready to deemphesize it a bit. For
example, soonishly we'll drop support for init scripts for the "S" or
"boot" runlevels, i.e. "early boot". We will then allow SysV services
only for runlevels 2-5. Next we'll rip out SysV support from PID 1 and
move it into a generator binary which is called at boot and simply
generates dynamic throw-away services that invoke the old sysv
scripts. All that in preparation to get rid of SysV entirely in a couple
of years. That path is clear, and it would be diametrically against our
intentions here to add in another 1st class unit file syntax. We want
fewer service file syntaxes, not more.

It also has something to do with simplicity: in a clean system we better
avoid having two kinds of files with the suffix ".service". Since we
can't get rid of the systemd .service files it is my hope to get rid of
the D-Bus .service files, instead.
Comments? Alternative proposals? Half-bricks? Cakes?
Quite frankly, I am not fond at all of the idea of emphasizing D-Bus
.service files. It is my explicit intention to deemphasize them.

And implementing your idea #1 is much more complex than it might
appear. For example, in systemd we strictly don't do automatic config
reloading, which D-Bus does. It's very hard and inefficient to support
the current behaviour of .service files within systemd that way.

I am open to abstracting the activation mechanism a bit so that the
"systemd" name is removed, if that's what the Upstart/Debian folks want
(I am even happy to do this without keeping compat here). However, I am
unwilling to agree to make D-Bus .service files the new gold standard.

Sorry if this is disappointing,

Lennart
--
Lennart Poettering - Red Hat, Inc.
Jóhann B. Guðmundsson
2011-09-02 10:04:35 UTC
Permalink
Post by Lennart Poettering
Many upstream packages ship native systemd unit files these days, your
example Avahi for example does. And in Fedora 16 we have have converted
*all* init scripts to systemd unit files. My plan for Fedora 17 is to
have all bus services converted too.
Given that i'm the feature owner for the conversation process and got
stressed enough when (some ) online media starting throwing false
statements ( others more reliable and accurate and bothered to read the
feature page ) that we would have *all* init scripts converted to
systemd unit in F16 to the point I extended my day from 24hours to
36hours trying to meet that goal then finding out that your the one
spreading that false statement comes as a bit of a shock.

An statement closer to the truth is we are at 1/3 - 1/2 converting from
the legacy sysv init script to native systemd units however all live
media and default next next install from the dvd is done which means
desktop installs are covered ( perhaps that's *all* in your eyes )
except those that might contain openvpn ( maintainer did not have time
to look at this ) and wpa_supplicant where Dan has yet not build the
package containing the submitted wpa_supplicant units and we did put a
stop on pursuing it until we hear from Dan ( Not heard if Bill manage to
speak to him about this ) since it came to our attention that unit files
where submitted upstream that deviated from what we had created and Dan
had accepted and as you all know we try to stay as close to upstream as
possible so we kinda need know from Dan what's going on and which files
Lennart Poettering
2011-09-03 12:51:30 UTC
Permalink
For the record there will be no more native systemd unit files
introduced into the release ( F16 ) after we release beta and since
we have started composing test candidates for beta what's in the
release ( F16 ) now is pretty much what will be in it during it's
whole release cycle.
Oh, I thought we had the full conversion as release requirement. I
wasn't aware this didn't work out. Sorry for the confusion,


Lennart
--
Lennart Poettering - Red Hat, Inc.
Reindl Harald
2011-09-03 12:54:44 UTC
Permalink
Post by Lennart Poettering
For the record there will be no more native systemd unit files
introduced into the release ( F16 ) after we release beta and since
we have started composing test candidates for beta what's in the
release ( F16 ) now is pretty much what will be in it during it's
whole release cycle.
Oh, I thought we had the full conversion as release requirement. I
wasn't aware this didn't work out. Sorry for the confusion
oh no - please don't tell us we have to wait for F17 or F18 to
get a release-state which should have been mandatory for F15
Jóhann B. Guðmundsson
2011-09-05 14:46:43 UTC
Permalink
Post by Lennart Poettering
For the record there will be no more native systemd unit files
introduced into the release ( F16 ) after we release beta and since
we have started composing test candidates for beta what's in the
release ( F16 ) now is pretty much what will be in it during it's
whole release cycle.
Oh, I thought we had the full conversion as release requirement. I
wasn't aware this didn't work out. Sorry for the confusion,
Fesco themselves approved to block the alpha release until all core,
base and base-x + what's on the live media had been converted.

But when push came to shove FESCO back out of it as in blocking the
release which should have been done since both openvpn and
wpa_supplicant are on the live media and if they had any intention what
so ever to reach that goal they could have stepped in themselves ( which
btw fesco members should never have to do. ) package and shipped the
remaining service that lacked native unit files since I had already
submitted unit files to reach that goal.

Now the the biggest problem I have faced for speedy adoption so far are
non responsive maintainers.

Once a maintainer becomes unresponsive it causes major pain across
various groups within the community and not but not least to the end user.

I'm not sure how other distro's deal with that problem but our method is
far from being efficient.

Anyway to put long story short what I have learned so far is that the
current model surrounding maintainers and maintainership followed by
various policies surrounding that model which is used in Fedora as in
maintainers "Own" their components ( ownership model ) cannot deal with
large scale changes like systemd introduces amongst other things and
that module effectively became outdated when Fedora stopped being hobby
distro made up of relatively few components with relatively few
maintainers and users.

JBG

Continue reading on narkive:
Loading...