<div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>We have a situation where some of our processes expose themselves over dbus with more than one well-known name. There are a few reasons this may be done:<br><br>* For optimisation - moving two or more increasingly tightly coupled components into one process;<br>

* Legacy - providing legacy adaptor interfaces from a newer daemon.<br></div><div>* Prototyping - starting with a single-process implementation, knowing that we want to provide separate interfaces over different bus-names.<br>

</div><div><br></div>In these situations, we still provide service files for each bus-name and they all point to the same executable. My expectation was that dbus-daemon would take care of process spawning and avoid any race conditions during activation. IIUC dbus-daemon provides this guarantee for concurrent requests to activate a service, but doesn't appear to support concurrent requests to activate different services that are provided by the same executable. We're seeing multiple instances of an executable started occasionally which we believe is caused by this.<br>

<br></div>This question has been asked in the past:<br><br><a href="http://old.nabble.com/Providing-several-well-known-names-vs.-activation-td31627361.html">http://old.nabble.com/Providing-several-well-known-names-vs.-activation-td31627361.html</a><br>

<br></div>Is this use-case still unsupported? Has there been any work done to patch dbus to make this work? If not, we might consider patching dbus to make it check the "Exec" in a service file in a similar way to how it checks the service name, to fix any raciness in this situation.<br>

<br>Before we attempt that, can anyone give us any reasons why this design is fundamentally broken or why such a patch wouldn't be accepted upstream?<br><br></div><div>Cheers,<br><br>Darren<br></div><br></div>