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

[Dimitri John Ledkov]

On 24 March 2015 at 05:53, Cameron Norman <camerontnorman at gmail.com> wrote:
> On Mon, Mar 23, 2015 at 1:54 AM, 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.
>
> Obviously you want to use systemd, but you may want look at prior art
> in Upstart with the upstart-dbus-bridge:
> http://upstart.ubuntu.com/cookbook/#upstart-dbus-bridge
>

With my upstart upstream hat on, I can honestly say that in practice
that was a costly implementation, at least as implemented in upstart.
As we would launch a capture all dbus monitor and re-emit everything
that's broadcasted by the daemon into essentially fire-hose of events
spamming all upstart event listeners.

A solution for DBus events would be nice. E.g. it would be nice to be
able to "bind" jobs to certain DBus properties and start/stop instance
jobs based on them (e.g. ofono SIM modems appearing and disappearing
on the DBus).

Also to fully convert Ubuntu user session to use systemd, I am leaning
towards having some way for user session units to bind to system level
units... At the moment I am ignoring that part of integration, or
hoping that I can resolve it with cunning ways of using generators and
runtime created "dummy" units rather than inventing / adding new unit
types.

Regards,

Dimitri.


>>
>> 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?
>>
>> My idea is...
>> Add new configuration directory. (e.g. "/etc/systemd/active-by-signal")
>> And service can install its configuration file on there with below
>> format. (Please don't care of its detail. It just a example.)
>
> I would think this fits better as a new unit type. These units would
> act just like socket, path, or timer units, in that they launch
> services (default of service of the same name) when an event occurs.
>
> Regardless of implementation, this is definitely a useful feature that
> I can see being used in a few situations already. For example, in
> elementary OS we use a NM dispatcher script to detect captive logins
> and autoprompt users, but this requires hacky setting of DISPLAY
> variables in that script. It would be cleaner if we could just launch
> a script when NM signals the connection coming. This would be a
> user/session service so there would be no need to manually set env
> variables like DISPLAY.
>
> Here is the script for reference:
> http://bazaar.launchpad.net/~elementary-apps/capnet-assist/trunk/view/head:/90captive_portal_test
>
> Cheers,
> --
> Cameron Norman
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,

Dimitri.

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.