On Thu, 11.08.11 19:06, Simon McVittie (simon.mcvit...@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 > ======================================================================== > > We already have a search path: > > * 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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
