On 2015년 04월 09일 02:05, Lennart Poettering wrote: > On Mon, 23.03.15 17:54, WaLyong Cho (walyong....@samsung.com) wrote: > >> Hi, >> >> Now, I'm looking for a method to a service be activated on special DBus >> signal. If a process is running for waiting some of DBus signal this can >> be useful. >> >> I already told with Simon in DBus mailing list. >> >> see this thread: >> http://lists.freedesktop.org/archives/dbus/2015-March/016607.html >> >> Simon said: >> "If it did, there are some nasty ordering constraints - I certainly >> wouldn't want to have to delay delivery of a broadcast until all >> interested services had started up! - so I don't think adding this >> feature would be a good idea." >> >> How about also support for DBus signal? > > Hmm, so this has come up before, but this is really nasty to support, > and I am not convinced we really want this. > > First of all, in a kdbus world this would require kernel support, so > that the kernel will listen and queue messages on behalf of userspace, > and that would be quite a major change... > > 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... > >> Then, make systemd to monitor DBus. And if a matched signal was sent, >> activate the service. > > 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...
Is sd_bus_add_match() useful on here? I thought about... Add option for subscribe signal as SubscribeSignal= and can take option such like SubscribeSignal=path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=Subscribe. Then when the unit(busname seems to be suit but the busname is only supported for kdbus. So I'm not sure. anyway) is loaded, call the sd_bus_add_match() with the parsed strv and register its callback. To transport this missed signal(for who want to listen), another option will be required to specify method call what will be sent with missed signal. Because we really not wants duplicated signal is broadcasted. Assume the option is SubscribeCallback= and can take like SubscribeCallback=path=/foo/bar/waldo interface=foo.bar.waldo.quux member=missedsignal. On the callback(what is called by sd_bus_match()), will send a method call to the specified address with a argument for missed signal contents. I know, this is very strange and seems not cool. And maybe the activation will really slow. But seems not impossible. But, ahead, even if you agree this is possible, those option should be controlled by other unit(not service). busname seems to be suit but I'm not sure the busname unit can joint with currently used DBus1. Thanks, WaLyong _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
