<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 28 March 2013 10:54, Simon McVittie <span dir="ltr"><<a href="mailto:simon.mcvittie@collabora.co.uk" target="_blank">simon.mcvittie@collabora.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On 27/03/13 19:46, Darren Garvey wrote:<br>
> We have a situation where some of our processes expose themselves over<br>
> dbus with more than one well-known name.<br>
<br>
</div>telepathy-mission-control does this too. It's directly activatable under<br>
the last name it acquires (AccountManager) and the .service file for its<br>
other name (MissionControl5) runs a helper utility which requests<br>
activation of AccountManager, waits for that name to exist, then exits.<br>
(It's util/wait-for-name.c in our source tree.) This only works because<br>
dbus-daemon does not currently require that the process that eventually<br>
takes the name is a descendant of the process that it executed.<br></blockquote><div><br></div><div>We have similar tools that we can use which fix the problem we're seeing, albeit in a rather inelegant way.<br><br></div>
<div>Why do you need to wait for the busname to appear in your helper utility? Rather than using say a "ping" script? For example, something akin to this:<br><br></div><div>----------8<----------<br>$ cat /usr/bin/ping-service.sh<br>
</div><div>#!/bin/bash<br>dbus-send --session --type=method_call --print-reply --dest=$1 / org.freedesktop.DBus.Peer.Ping<br><br></div><div>$ cat Acme.Tool.service<br></div><div>[D-BUS Service]<br></div><div>Name=Acme.Tool<br>
</div><div>Exec=/usr/bin/acmetool<br></div><div>User=acme<br></div><div><br><div>$ cat Acme.AltTool.service<br></div><div>[D-BUS Service]<br></div><div>Name=Acme.AltTool<br></div>Exec=/usr/bin/ping-service.sh Acme.Tool<br>
User=acme<br>---------->8----------<br></div><div><br>My hope would be that dbus-daemon would see that the "Exec" in the alias service file had exited with a zero return code and then wait for a RequestName message for the expected bus name. This /appears/ to work after some testing, but I'm not convinced.<br>
<br></div><div>From bus/activation.c:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">1337 /* There are two major cases here; are we the system bus or the session? Here this<br>
1338 * is distinguished by whether or not we use a setuid helper launcher. With the launch helper,<br>1339 * some process exit codes are meaningful, processed by handle_servicehelper_exit_error.<br>1340 *<br>1341 * In both cases though, just ignore when a process exits with status 0; it's possible for<br>
1342 * a program to (misguidedly) "daemonize", and that appears to us as an exit. This closes a race<br>1343 * condition between this code and the child process claiming the bus name.<br>1344 */<br>1345 uses_servicehelper = bus_context_get_servicehelper (pending_activation->activation->context) != NULL;<br>
</blockquote><br></div><div>I haven't fully followed through this code to be sure if we need to wait, but the comment above implies otherwise. In this case, the ping script would return with a 0 exit status which I guess would look like a "daemonize".<br>
</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This could be extended to cover an arbitrary number of "secondary names"<br>
(MissionControl5 here; potentially ChannelDispatcher in future) pointing<br>
to one "primary name" (AccountManager here).<br>
<br>
This is not a great solution, and D-Bus would be better off if we could<br>
write something like this (analogous to systemd's Alias):<br>
<br>
# ...AccountManager.service<br>
[D-BUS Service]<br>
Name=...AccountManager<br>
Exec=/usr/libexec/mission-control-5<br>
<br>
# ...MissionControl5.service<br>
[D-BUS Service]<br>
Name=...MissionControl5<br>
ActivateInstead=...AccountManager<br>
<br>
# ...ChannelDispatcher.service<br>
[D-BUS Service]<br>
Name=...ChannelDispatcher<br>
ActivateInstead=...AccountManager<br></blockquote><div><br></div><div>I prefer this solution over the other (snipped from below). It's more explicit.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
> If not, we might consider patching dbus to make it check the "Exec"<br>
> in a service file in a similar way to how it checks the service name,<br>
> to fix any raciness in this situation.<br>
<br>
</div>This was added in commit 075945f6 (with a not-particularly-helpful<br>
changelog entry) and reverted in commit 171934b37, because this<br>
behaviour is not described in the spec and it was breaking conversion of<br>
some system services to systemd activation (which for some reason<br>
involved changing those services to Exec=/bin/false).<br>
See <<a href="https://bugs.freedesktop.org/show_bug.cgi?id=35750" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=35750</a>>.<br>
<br>
So, to merge this, I'd need a clear explanation of why it's OK (or<br>
possibly, how those services were wrong and how they could have been<br>
corrected), and a patch to the D-Bus Specification describing the new<br>
de-duplication semantics.<br></blockquote><div><br></div><div>OK. Thanks for the history, very useful.<br><br></div><div>Cheers,<br><br>Darren<br></div></div></div></div>