5 ms·

The fundamental problem here is plainly, and simply, why is an ipc daemon doing anything with starting and stopping processes. I could understand a bit more if

The fundamental problem here is plainly, and simply, why is an ipc daemon doing anything with starting and stopping processes. I could understand a bit more if something like gnome-session was poorly starting and stopping daemons, but an ipc daemon is near the bottom of the List of things that should have that functionality.

geofft 11y ago
Because you want processes to start when IPC to them is needed. The classic example here is CUPS: you don't want CUPS running all the time (init script), nor do you want it running when a printer is plugged in (HAL activation), you just want it when someone's trying to print (service activation). Apple did exactly this with CUPS and launchd well before either D-Bus or systemd existed. D-Bus was developed around the same time as Upstart, which didn't really support service activation, and well before systemd. So what could it have asked to run CUPS, other than itself?
- ploxiln 11y ago
  There was inetd and xinetd, for many years. They start a process which listens on a tcp or udp socket, only when a connection or packet is seen on that socket. I'm not sure how popular they were, but I've been using "desktop" linux since 2003 and working with production servers since 2010, and I've never seen them in actual use myself. Services like cups use a couple of megabytes of memory. All other applications dwarf it on the desktop, and service activation isn't appropriate for servers. It's a complication which you don't need. I'm all about reducing bloat; the best way to do that is uninstall the service. systemd supports socket activiation, and it's actually pretty cool as a startup-dependency-satisfying scheme. But this article talks about just telling systemd to start the service, not by trying to access a socket the service will listen on. And it mentions the "service" command, which is a standard way to do that on redhat and debian based distros since as long as I can remember. So when D-Bus was developed it should have used "service $NAME start" if it really wanted to try to start a service.
- deleted 11y ago
  [deleted]
- vezzy-fnord 11y ago
  The proper way to do this is to have a way for processes to consume sort of public event queue exported by the service in question, and conditionally exec(3) processes in response. Much like the kernel has uevents for device node managers to listen on over a Netlink channel. Without proper mechanism, you can't have true activation from a black box.
- Sanddancer 11y ago
  To re-answer your question, ideally d-bus would send the request to the session manager, which already has logic to start and stop programs as needed. If it is a system-level service, then the session manager should call the init system, through the formalized methods already set up, to start the service. The problem described in the original article is that d-bus lacks any sort of logic to figure out what to do if things go wrong, and thus causes more problems than it solves, in more difficult places to troubleshoot. Finally, regarding d-bus' age, development on DBus started in 2002, about the same time as the first release of OS X with Cups, and well before Canonical started work on upstart. For the first several years, d-bus was just a messaging service, and it worked decently at it. Pasting on another component that starts and stops services is just asking for problems.

geofft 11y ago

Because you want processes to start when IPC to them is needed. The classic example here is CUPS: you don't want CUPS running all the time (init script), nor do you want it running when a printer is plugged in (HAL activation), you just want it when someone's trying to print (service activation). Apple did exactly this with CUPS and launchd well before either D-Bus or systemd existed. D-Bus was developed around the same time as Upstart, which didn't really support service activation, and well before systemd. So what could it have asked to run CUPS, other than itself?

ploxiln 11y ago
There was inetd and xinetd, for many years. They start a process which listens on a tcp or udp socket, only when a connection or packet is seen on that socket. I'm not sure how popular they were, but I've been using "desktop" linux since 2003 and working with production servers since 2010, and I've never seen them in actual use myself. Services like cups use a couple of megabytes of memory. All other applications dwarf it on the desktop, and service activation isn't appropriate for servers. It's a complication which you don't need. I'm all about reducing bloat; the best way to do that is uninstall the service. systemd supports socket activiation, and it's actually pretty cool as a startup-dependency-satisfying scheme. But this article talks about just telling systemd to start the service, not by trying to access a socket the service will listen on. And it mentions the "service" command, which is a standard way to do that on redhat and debian based distros since as long as I can remember. So when D-Bus was developed it should have used "service $NAME start" if it really wanted to try to start a service.
deleted 11y ago
[deleted]
vezzy-fnord 11y ago
The proper way to do this is to have a way for processes to consume sort of public event queue exported by the service in question, and conditionally exec(3) processes in response. Much like the kernel has uevents for device node managers to listen on over a Netlink channel. Without proper mechanism, you can't have true activation from a black box.
Sanddancer 11y ago
To re-answer your question, ideally d-bus would send the request to the session manager, which already has logic to start and stop programs as needed. If it is a system-level service, then the session manager should call the init system, through the formalized methods already set up, to start the service. The problem described in the original article is that d-bus lacks any sort of logic to figure out what to do if things go wrong, and thus causes more problems than it solves, in more difficult places to troubleshoot. Finally, regarding d-bus' age, development on DBus started in 2002, about the same time as the first release of OS X with Cups, and well before Canonical started work on upstart. For the first several years, d-bus was just a messaging service, and it worked decently at it. Pasting on another component that starts and stops services is just asking for problems.