On 08/04/15 18:05, Lennart Poettering wrote: > In general, so far activation was limited to *explicit* messages sent to > the service in question, services would never be activated as possibly > unintended side-effect of unrelated broadcast messages, and that's a > really good property...
Yes. The same reasoning exists in dbus-daemon. > Well, it's not that simple, we'd also have to queue the signal, and > all following messages, and pass that on to the activated > service... And that's pretty nasty. It's already pretty nasty for the > current logic but it would be even more complex with a match logic... Yes. The same problems exist in dbus-daemon. > I doubt this will fly... That's what I said on dbus@, for remarkably similar reasons. It's reassuring that systemd developers agree. In answer to the original question, I suspect that wanting to do this might be a sign that you should re-think your design. If you described the high-level problem(s) you wanted to solve (not in abstract terms like "I want to run a service in response to a broadcast", but in more concrete terms like maybe "I want to start a VPN whenever we join a wireless network"), perhaps someone could suggest a better way to solve it. However, if you have re-thought it and concluded that yes, you really do want what you initially asked for, I think this is the only way to do it in current D-Bus, and also the only way that will be supported in kdbus: * have your own signal-listening service that listens for the "interesting" broadcasts, and has a configurable map from broadcast characteristics to something to activate for that broadcast * have that signal-listening daemon either send a unicast message to the activatable service (which will cause activation as a side-effect), or explicitly ask dbus-daemon or systemd to activate it * when the activatable service starts up, it performs state-recovery to catch up on the broadcasts that it missed, including the one that resulted in its activation ... all of which can be done right now, if you really need to, without any changes to either systemd or dbus. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
