It looks like the code was trying to deduplicate activation requests for the same app on >1 service name.

I think that would be nice (in the future) to index activation->pending_activations on the name of the .service file, not on the bus name: then one .service file could list n service names and guarantee that it'll be run at most once at a time.

But this fix looks correct to me. I think if anything is depending on this deduplication then we can declare it to be broken; the worst that would happen is that the second instance would fail to claim its bus name and either crash or sit around doing nothing forever.

I r+ this too, so I merged it for 1.4.8. It'll be merged to master shortly, in time for 1.5.0.

(In reply to comment #1)
> I think that would be nice (in the future) to index
> activation->pending_activations on the name of the .service file, not on the
> bus name: then one .service file could list n service names and guarantee that
> it'll be run at most once at a time.

(Please clone this as a separate bug if you want it.)

I disagree on the specific mechanics for this: on the session bus, best-practice (iirc) is for the .service file to be named after the bus name, and on the system bus, it's mandatory for the name to be the same. I believe the reason is something to do with the setuid helper.

One way to get the same effect would be to introduce a way for the "aliases" to omit the Exec= and say "InsteadActivate=com.example.RealName". Another would be to introduce a way for ...RealName.service file to say "AlsoActivateFor=com.example.Alias;com.example.Pseudonym;" or something. In either case, we'd want to only invoke the setuid system-bus helper for ...RealName, and track pending activations in terms of ...RealName.

I believe we used to do something similar for Mission Control (the reference implementation of the Telepathy AccountManager and ChannelDispatcher services) on Maemo, where ...AccountManager.service and ...ChannelDispatcher.service used dbus-send to send Ping to ...MissionControl5, and ...MissionControl5.service did the actual launching?