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.

Lennart: would you like to collaborate and co-operate on that "very different interface" so that it can be shared between Upstart and systemd?

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.

Also, this way we can get rid of the dep on /usr easily and start dbus already during early boot.

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.
>

(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.

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.
>

(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?

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

(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.

It appears this isn't going to happen.