[systemd-devel] [RFC] activate on DBus signal

[WaLyong Cho]

On 2015년 04월 09일 02:05, Lennart Poettering wrote:
> On Mon, 23.03.15 17:54, WaLyong Cho (walyong.cho at 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