Using D-Bus well-known service names and deprecating mapper service lookups

[Andrew Jeffery]

Hello,

Recently Andrew Geissler, William and myself have been running into limitations of the mapper's service lookups. In my opinion we should move to use well known service names and avoiding reliance on the mapper to determine who to talk to.

My issues with using the mapper for service dependencies are:

1. Ambiguities in the way `mapper wait` functions
2. Race conditions between bus name announcement, mapper introspection and inbound service lookups
3. Increased IPC traffic (decreasing performance).

Expanding on 1, `mapper wait` takes a path name argument and waits until the path is available on a bus connection. The problem here is that multiple connections can (and do) implement objects under a given path, so the successful exit of `mapper wait` with the expectation that a given service is available can be an undefined result, as it's possible the *wrong* service was used to resolve the wait.

Where this hits home is that we currently have a systemd service, mapper-wait at .service, that allows units to depend on the presence of a service providing a required path. With the ambiguity outlined above it's possible that dependent services are started earlier than they should be due to `mapper wait` falsely exiting success with respect to the dependent's actual requirement.

A quick grep of the openbmc tree gives an idea of the potential problem size:

$ git ls-files -- recipes-phosphor/ | grep '\.service$' | wc -l
98
$ git ls-files -- recipes-phosphor/ | grep '\.service$' | xargs grep -li mapper-wait | wc -l
32

So about a 1/3 generic services are potentially exposed.

Point 2 leads to patches like [1] where we wind up implementing a fallback to a well-known service name if we get issues with a mapper lookup. If this is a valid approach then we should just avoid looking up the service altogether; implementing this fallback approach everywhere seems tedious and error-prone, and the lookup is a waste of resources if the fallback works regardless.

By moving to well known service names we can exploit more of systemd's D-Bus integration with units of Type=dbus, and depending either on unit names aliased to D-Bus service names, or on D-Bus service activation, and receive reliable behaviour for D-Bus-based dependencies.

Point 3 is something William has complained about, and I think it's a good point - avoiding IPC where we can is a good thing no matter what we're doing.

I'm kicking this thread off because it's something that's bothered me for a while. I've complained about it to various people in private but have never taken it any further. My impression is that there's support for the idea that we move away from the mapper for service lookups (though we can't eliminate it entirely, we still need the interface reverse mapping feature), and I want to gauge how much support it has and whether there are solid counter-arguments.

Cheers,

Andrew

[1] https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-state-manager/+/20460