best practice proposal: name locking and process exclusion

[Lennart Poettering]

On Thu, 07.04.11 12:43, Colin Walters (walters at verbum.org) wrote:

> So one of the things I've always said about DBus that it provides for
> the operating system is a reliable means for loose binding between
> components, in the form of well-known bus names like
> org.freedesktop.NetworkManager.
> 
> Claiming a name serves multiple purposes:
> * Acts as a "process exclusion" mechanism, to avoid multiple processes
> in your component or app when not wanted (think in a classic GNOME 2
> desktop, where Firefox has to go out of its way to make clicking on
> the Firefox launcher multiple times work).

Hmpf. I am not sure I agree with this idea. I think to avoid duplicates
you should have a good session manager which ensures that (systemd!). In
fact I believe all services should be bus activatable so that we can
fully parallelize session startup without need for any ordering, hence
bus names will be available unconditionally and you never need to
protect them against each other.

In summary: in a systemd world the problem doesn't really exist.

> * Allows other components or apps to communicate with you
> 
> The tension between these two is simply that for the first property,
> you want to claim the bus name *early*, before you start loading
> resource files and the like.  For the latter, you really only want to
> claim the bus name when your process is fully ready to respond to
> requests.

You want to claim it so early that you want to claim it actually before
the process is even spawned, which you can do by using bus activation.

> Now there are other potential solutions to process exclusion - for
> system services, you can also use a lockfile in /run say.  But this
> solution avoids creating files, which is nice (we don't want to create
> unnecessary writes - think relatime and flash devices).

/run is tmpfs, so nothing will be written to disk anyway. Also,
XDG_RUNTIME_DIR gives you a runtime dir in tmpfs per-user with a
guaranteed life-time bound to your login and even guarantees you that
BSD file locks work on it.

That said I actually believe lock files are an abomination, and I am not
convinced that using bus-based locks (i.e. async locks even -- BSD locks
are at least synchronous) is much better. I'd very much prefer to get
rid of the problem entirely, and simply leave process management to the
session manager.

A simple solution that wouldn't even enforce a systemd dependency in
apps could be an algorithm like the following:

1. If I am not bus activated send Ping() to my own bus name, thus
   activating a bus activated version of myself. Exit.
2. Otherwise, run mainloop and stuff.
3. ...
4. Profitt!

That would be neatly compatible with the ideas of systemd, without
introducing such a dependency. All apps would be maintained by dbus, all
names always available, no explicit locking anywhere and all processes
would be executed in a clean execution context.

And instead of Ping() you could even rung OpenWindow() or so, to open a
new window.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.