Bug 34526 - Support service activation via Upstart
Summary: Support service activation via Upstart
Status: RESOLVED WONTFIX
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.5
Hardware: All All
: medium enhancement
Assignee: Havoc Pennington
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2011-02-21 04:08 UTC by Simon McVittie
Modified: 2014-09-23 15:22 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon McVittie 2011-02-21 04:08:14 UTC
Scott proposed some patches on the mailing list, but concerns were raised about the design: it was intended to be service-activator-neutral, but Upstart and systemd seem to have different intended policies (Upstart wants to take over responsibility for activation entirely, whereas systemd only wants to be responsible for activating services that have explicitly opted-in) and want different information from us.

Havoc pointed out that adding a third form of service activation really deserves some regression tests.

Mailing list threads:

http://lists.freedesktop.org/archives/dbus/2010-December/013868.html

http://lists.freedesktop.org/archives/dbus/2011-January/013938.html
Comment 1 Lennart Poettering 2011-03-09 19:30:43 UTC
NAK. I plan to add a very different interface for bus activation in systemd now, so please do not merge this before this new scheme isn't clear.
Comment 2 Scott James Remnant 2011-03-10 10:35:38 UTC
Lennart: would you like to collaborate and co-operate on that "very different interface" so that it can be shared between Upstart and systemd?
Comment 3 Lennart Poettering 2011-03-28 10:44:53 UTC
So, here's what I plan to do for systemd, on top of what already exists in dbus:

dbus would not only monitor /usr/share/dbus/system-services, but also /etc/systemd/system and /lib/systemd/system/ and implicitly add all service files found in there that start with "dbus-" and end in ".service" as activatable service to the list. That way we don't need the indirection via files in /usr/share/dbus/system-services anymore and things get vastly simpler. 

By creating dbus-xxxx.service symlinks in /etc/systemd/system/ via systemctl it is hence trivially possibly to enable/disable bus services.

I am not sure where this leaves Upstart's activation support, but maybe Upstart wants to go in the same direction, too? We should figure that out before we merge any work. I am not particularly thrilled to update systemd to make Upstart happy although I actually believe a completely different solution is the future.
Comment 4 Lennart Poettering 2011-03-28 10:48:33 UTC
Also, this way we can get rid of the dep on /usr easily and start dbus already during early boot.
Comment 5 Scott James Remnant 2011-03-28 10:48:36 UTC
Since this is "on top" of what already exists in D-Bus, I'm not sure
how this conflicts with any of the RFC patch sets I've sent out. Could
you explain your rationale for the NAK?

By "completely different solution in the future" are you thinking that
systemd would create the AF_UNIX multicast socket used for the bus, so
the dbus daemon wouldn't be needed?

On Mon, Mar 28, 2011 at 10:44 AM,  <bugzilla-daemon@freedesktop.org> wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=34526
>
> --- Comment #3 from Lennart Poettering <lennart@poettering.net> 2011-03-28 10:44:53 PDT ---
> So, here's what I plan to do for systemd, on top of what already exists in
> dbus:
>
> dbus would not only monitor /usr/share/dbus/system-services, but also
> /etc/systemd/system and /lib/systemd/system/ and implicitly add all service
> files found in there that start with "dbus-" and end in ".service" as
> activatable service to the list. That way we don't need the indirection via
> files in /usr/share/dbus/system-services anymore and things get vastly simpler.
>
> By creating dbus-xxxx.service symlinks in /etc/systemd/system/ via systemctl it
> is hence trivially possibly to enable/disable bus services.
>
> I am not sure where this leaves Upstart's activation support, but maybe Upstart
> wants to go in the same direction, too? We should figure that out before we
> merge any work. I am not particularly thrilled to update systemd to make
> Upstart happy although I actually believe a completely different solution is
> the future.
>
> --
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Comment 6 Lennart Poettering 2011-03-28 11:20:06 UTC
(In reply to comment #5)
> Since this is "on top" of what already exists in D-Bus, I'm not sure
> how this conflicts with any of the RFC patch sets I've sent out. Could
> you explain your rationale for the NAK?

Well, we don't need four activation mechanisms in D-Bus.

I am just asking you to reconsider the scheme you proposed in light what I plan to do add for systemd. After all your patch would basically just relabel the systemd-specific messages to something more generic, so maybe you want to do something like my new scheme, too? And then wouldn't need the relabelling of those names?

> By "completely different solution in the future" are you thinking that
> systemd would create the AF_UNIX multicast socket used for the bus, so
> the dbus daemon wouldn't be needed?

No, I just mean that I want to drop the need for /usr/share/dbus/systemd-services/ files to support bus activated services. It's vastly simpler if people can just create a symlink in /etc/systemd/system to make something bus activatable.
Comment 7 Scott James Remnant 2011-03-28 12:09:40 UTC
I've proposed three different schemes and patches, so I'm not sure to
which you're referring ;-)

But yes, I think we can work together here - because it sounds like
you and I both want to drop the need for the files in /usr/share

On Mon, Mar 28, 2011 at 11:20 AM,  <bugzilla-daemon@freedesktop.org> wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=34526
>
> --- Comment #6 from Lennart Poettering <lennart@poettering.net> 2011-03-28 11:20:06 PDT ---
> (In reply to comment #5)
>> Since this is "on top" of what already exists in D-Bus, I'm not sure
>> how this conflicts with any of the RFC patch sets I've sent out. Could
>> you explain your rationale for the NAK?
>
> Well, we don't need four activation mechanisms in D-Bus.
>
> I am just asking you to reconsider the scheme you proposed in light what I plan
> to do add for systemd. After all your patch would basically just relabel the
> systemd-specific messages to something more generic, so maybe you want to do
> something like my new scheme, too? And then wouldn't need the relabelling of
> those names?
>
>> By "completely different solution in the future" are you thinking that
>> systemd would create the AF_UNIX multicast socket used for the bus, so
>> the dbus daemon wouldn't be needed?
>
> No, I just mean that I want to drop the need for
> /usr/share/dbus/systemd-services/ files to support bus activated services. It's
> vastly simpler if people can just create a symlink in /etc/systemd/system to
> make something bus activatable.
>
> --
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Comment 8 Colin Walters 2011-04-01 10:37:38 UTC
(In reply to comment #3)
> So, here's what I plan to do for systemd, on top of what already exists in
> dbus:
> 
> dbus would not only monitor /usr/share/dbus/system-services, but also
> /etc/systemd/system and /lib/systemd/system/ and implicitly add all service
> files found in there that start with "dbus-" and end in ".service" as
> activatable service to the list. That way we don't need the indirection via
> files in /usr/share/dbus/system-services anymore and things get vastly simpler. 

Hmm, so for every bus activatible service there would be *two* systemd units, one prefixed with dbus- and one not?

I know this exists for NetworkManager but I really feel it's a stupid hack =/  We should be able to do better.

> By creating dbus-xxxx.service symlinks in /etc/systemd/system/ via systemctl it
> is hence trivially possibly to enable/disable bus services.

Are there any cases where an admin would want to turn off bus activation for a unit, but *not* disable the unit?
Comment 9 Colin Walters 2011-04-05 10:18:35 UTC
So I still think this is a good plan: http://lists.freedesktop.org/archives/dbus/2010-December/013921.html

Lennart, your reply was basically "some software calls ListActivatableNames now", but Rygel isn't installed by default by anyone, and really, how much of a hit is reading all the unit files anyways?  I doubt it's much compared to the overhead of streaming music or whatever rygel does.

So in this world then, the ony tricky parts I see are:

* systemd would have to make up a unit on the fly when system apps install *just* a .service file
* dbus would need to delegate ListActivatableNames to systemd
Comment 10 Lennart Poettering 2011-05-02 11:33:52 UTC
(In reply to comment #8)
> (In reply to comment #3)
> > So, here's what I plan to do for systemd, on top of what already exists in
> > dbus:
> > 
> > dbus would not only monitor /usr/share/dbus/system-services, but also
> > /etc/systemd/system and /lib/systemd/system/ and implicitly add all service
> > files found in there that start with "dbus-" and end in ".service" as
> > activatable service to the list. That way we don't need the indirection via
> > files in /usr/share/dbus/system-services anymore and things get vastly simpler. 
> 
> Hmm, so for every bus activatible service there would be *two* systemd units,
> one prefixed with dbus- and one not?

No. There would be only one. And a symlink alias for it, which might or might not exist. e.g. dbus-org.freedesktop.Avahi.service → avahi-daemon.service. To make Avahi bus activatable only this symlink would be created and that's it. "systemctl enable" can do this already.

> I know this exists for NetworkManager but I really feel it's a stupid hack =/ 
> We should be able to do better.

I think this is actually a pretty nice solution. it's how we do things in systemd: we install a unit file and then create symlinks to hook it into various places. It is in fact how SysV worked too, except that they only had bootup and runlevel changes as events one could hook things into.

Note that systemd understand symlinks, and will load only one unit, and treat the symlink names simply as aliases for it

> > By creating dbus-xxxx.service symlinks in /etc/systemd/system/ via systemctl it
> > is hence trivially possibly to enable/disable bus services.
> 
> Are there any cases where an admin would want to turn off bus activation for a
> unit, but *not* disable the unit?

Yes, I needed that a couple of times myself. Mostly for debugging issues though.
Comment 11 Simon McVittie 2014-09-23 15:22:26 UTC
It appears this isn't going to happen.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.