Comments on: re: upstart and D-Bus http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/ Where the urethane hits the pavement Mon, 10 Oct 2011 13:34:18 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: Patrys http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18790 Patrys Wed, 31 Oct 2007 12:19:57 +0000 http://www.j5live.com/?p=412#comment-18790 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. 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.

]]> By: Scott James Remnant http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18789 Scott James Remnant Tue, 30 Oct 2007 17:54:40 +0000 http://www.j5live.com/?p=412#comment-18789 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. 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.

]]> By: Patrys http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18788 Patrys Tue, 30 Oct 2007 12:59:32 +0000 http://www.j5live.com/?p=412#comment-18788 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. 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.

]]> By: Scott James Remnant http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18787 Scott James Remnant Tue, 30 Oct 2007 01:36:36 +0000 http://www.j5live.com/?p=412#comment-18787 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? 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?

]]> By: J5 http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18786 J5 Tue, 30 Oct 2007 01:09:13 +0000 http://www.j5live.com/?p=412#comment-18786 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. 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.

]]> By: Scott James Remnant http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18785 Scott James Remnant Tue, 30 Oct 2007 00:59:09 +0000 http://www.j5live.com/?p=412#comment-18785 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. 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.

]]> By: Michael http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18784 Michael Tue, 30 Oct 2007 00:28:33 +0000 http://www.j5live.com/?p=412#comment-18784 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. 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.

]]> By: J5 http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18783 J5 Mon, 29 Oct 2007 20:40:29 +0000 http://www.j5live.com/?p=412#comment-18783 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. 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.

]]> By: Colin Walters http://www.j5live.com/2007/10/29/re-upstart-and-d-bus/comment-page-1/#comment-18782 Colin Walters Mon, 29 Oct 2007 20:18:32 +0000 http://www.j5live.com/?p=412#comment-18782 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. 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.

]]>