Documenting service activation

Havoc Pennington hp at redhat.com
Mon Aug 28 06:52:44 PDT 2006


Jeroen T. Vermeulen wrote:
> 
>  * Am I right in understanding that services get activated automatically
> when invoked, i.e. without any explicit request to start them?  Raphaël's
> document seems to say this, but the specification seems to assume an
> explicit request along the lines of "start this service if it isn't
> already running."  Or is it the one at the API level and the other at the
> messaging level?

There's a flag in the method call message for whether to autostart, I 
believe it's enabled by default. There's also an explicit request method 
on org.freedesktop.DBus you can use to start a service by hand.

You might not always want to autostart, for example you might want to 
use the service only if it's already running.

>  * Am I also right in understanding that services get activated only when
> methods on them are invoked--i.e. not yet when proxies on their objects
> are first created?  Does the spec mandate this deferred activation?  If
> not, does the spec forbid it?

How proxies work is totally up to the binding. So the spec wouldn't have 
anything to say about this. On the libdbus/protocol level, there are two 
ways to activate (implicitly if the message has the auto start flag, and 
explicitly with the request to the bus); apps/bindings are free to use 
or not use either of these at any time.

>  * So does this then mean that you can create a proxy on an object in an
> activated service, and start listening for one of its signals, without
> causing that service to be activated in the process?

You can, e.g. I mentioned the GLib bindings have the "for name" proxy 
that doesn't require the remote app to be running, that proxy can listen 
for signals coming from the name even while there's no name owner.

>  * Must the header always say "[D-BUS Service]", or is that just a
> placeholder in the examples?  Is (or was) the idea perhaps that service
> descriptions can be embedded in desktop files?  If so, how does that
> header gel with the required ".service" filename suffix?

I believe so; this is just because the ".ini"-style format usually has 
section names, for whatever historical reason.

>  * Does the "Names=" entry list (well-known) connection names, nothing
> more, nothing less?

Yes, there would be no way to know what unique names to list.

>  * Can service files be written dynamically, i.e. while the bus is already
> running?

The bus watches for changes on the directory of .service files. I'm not 
sure how smart it is, but it should at least pick up newly-installed files.

>  * Is there any other way to register a service with the bus?

For automatic start, no. Of course there's no requirement to autostart, 
you can also just ask to own a well-known name and arrange for your app 
to be started in some other way. For example, desktop components can 
just be in the "startup programs" directory for the desktop.

>  * Can any registered service always be started for any bus where it is
> requested?

The .service files go in a directory specified in the config file that 
defines a particular bus, so e.g. there is a separate directory for the 
system and session bus.

Havoc



More information about the dbus mailing list