<servicedir> scanning order

[Simon McVittie]

On 16/07/13 17:41, Joseph Artsimovich wrote:
> In a system we are developing, we are going to have identically named
> .service files (with different Exec attribute) in 2 different locations.
> We want one of those locations to have higher priority than another.

System or session services, or some third type of bus?

For session services, you can use the XDG Base Directory specification
(set $XDG_DATA_HOME and $XDG_DATA_DIRS) to get a well-understood
precedence order ($XDG_DATA_HOME is most important, then earlier
":"-delimited entries in $XDG_DATA_DIRS is more important than later ones).

For system services, there are already several locations read by default
(see the source code for details) - perhaps those meet your needs? They
include /usr/local/share and /usr/share, with /usr/local/share taking
precedence (at least, it's meant to). They also include the prefix in
which dbus is installed, and /lib.

I wouldn't oppose adding /etc/dbus-1/system-services to the search path
for system services (at the beginning), analogous to
/etc/systemd/system, if that was considered useful.

> From dbus manual page it follows that <servicedir> entries are scanned
> in reverse order they appear in config file:
> -----------------------
> <servicedir>
> Adds a directory to scan for .service files. Directories are scanned
> starting with the last to appear
> in the config file (the first .service file found that provides a
> particular service will be used).
> -----------------------
> 
> Unfortunately my tests show that <servicedir> entries are really scanned
> in the order they appear in config file.
> 
> It looks like either the documentation or implementation needs to be fixed.

I suspect the implementation shouldn't be changed now: if it's wrong,
it's likely to have been wrong for several years, so people might be
relying on it. I'd prefer to fix the documentation to make it match the
implementation. Please open a bug on bugs.freedesktop.org so this
doesn't get lost.

Regression tests also gratefully accepted :-)

Ideally, the documentation would be in terms of (earlier|later)
<servicedir> entries being considered more authoritative/important than
(later|earlier) ones - that's the ordering that matters. Whether we read
least-important-first and overwrite existing entries, or read
most-important-first and skip services that would conflict with existing
entries, is an implementation detail.

    S