Mon 29 Oct 2007
Colin, wrong way around. I don’t think D-Bus wants a dependency on upstart. For various reasons we strive hard to not have complex external dependencies with the exception of some security models which is just out of necessity. The other way around is more fesable.
[read this post in: ar de es fr it ja ko pt ru zh-CN ]
October 29th, 2007 at 4:18 pm
Upstart already has a D-Bus dependency actually; it’s used now for IPC. The discussion is about *also* going the other way.
In particular to make a decoupled dependency between the system bus activation and Upstart. So you could still compile D-Bus without support for talking to Upstart. In fact it could be runtime; if you aren’t running Upstart, then system activation isn’t supported.
October 29th, 2007 at 4:40 pm
That discussion went down on the D-Bus list a year ago or so and it is not the way to go. If there is functionality that Upstart needs it should be added to the D-Bus activation services so that everyone gets it and we are not supporting different code paths.
October 29th, 2007 at 8:28 pm
Imho D-Bus is about IPC and not about service monitoring and management. So using upstart as backend for the D-Bus system activation makes a lot of sense. Why add complexity to D-Bus if upstart can solve this much better (and already does it, remember the special semantics of pid #1). Adding service management capabilities to D-Bus directly only duplicates functionality which already exists in upstart. I can’t think of a good reason not to use upstart as an (optional) backend.
October 29th, 2007 at 8:59 pm
D-BUS is a very good IPC system.
It should not be trying to be a Service Manager *as well*, for many, many reasons.
Upstart is a Service Manager. It should not try to be an IPC systme, so it uses D-BUS for its IPC needs.
D-BUS should use a Service Manager (”Upstart”) for its service management needs. Since Upstart uses D-BUS, this means the dependency is as simple as D-BUS making a D-BUS call for service activation.
[ Something like “org.freedesktop.ServiceManager.start(’servicename’) perhaps, if we go the neutral approach ]
That way D-BUS doesn’t need to worry about the immensely difficult problem of service management (which it already currently gets wrong in several ways); it simply asks another D-BUS service to start and stop them when it needs to.
October 29th, 2007 at 9:09 pm
You guys are splitting it all down the wrong lines. D-Bus doesn’t enforce policy. That would be upstart’s job, but it should provide the facilities to discover and activate services in a consistent manner across platforms.
October 29th, 2007 at 9:36 pm
On Windows, the way to correct activate services is by communication with the Windows service manager.
On Linux, the correct way should be to communicate to Upstart — which is a service manager.
I’m not sure what kind of policy you’re referring to?
October 30th, 2007 at 8:59 am
D-Bus needs service activation for efficient resource usage. Stateless providers are supposed to come and go as needed. You don’t ask D-Bus to “start the apache httpd” - you ask it to “connect you to org.apache.httpd.foo.bar” and whether it involves starting any system services or not is not your business.
Now imagine that connecting to “com.example.foo” involves connecting to “org.freedesktop.ServiceManager” which does not exist (think any BSD or Linux distros who don’t ship upstart) and in turn involves calling “org.freedesktop.ServiceManager” which… is a dead loop.
D-Bus is a straw, it’s your job to get yourself a glass.
October 30th, 2007 at 1:54 pm
Patrys: that’s what *dependencies* are for.
You may as well ask how do you connect to org.apache.httpd.foo.bar on BSD or Linux distros who don’t ship D-BUS.
October 31st, 2007 at 8:19 am
No, adding milk as a dependency to a straw makes no sense. And there is little to no benefit of D-Bus using upstart for service activation. These do not need supervising, they are only supposed to start, connect to the bus and serve the request, then they are free to go away. D-Bus services are not permanent services, they are closer to inetd behavior than to SysVinit.