On 24 March 2015 at 05:53, Cameron Norman <camerontnor...@gmail.com> wrote: > On Mon, Mar 23, 2015 at 1:54 AM, 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. > > 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@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel