On Thu, 2011-06-16 at 15:37 +0200, Ludwig Nussel wrote:
Kay Sievers wrote:
On Thu, 2011-06-16 at 13:18 +0200, Ludwig Nussel wrote:
Kay Sievers wrote:
The other example of socket activation is package upgrades. When pid 1 keeps the socket established, you can replace packages without ever losing any new connection.
You don't need systemd for that though. Keeping sockets open across exec is an operating system feature. The hard part is restoring the application's state and that's nothing systemd can help with. From the top of my head I only remember irssi which can re-exec itself since ages without losing connections or state. It's embarassing that e.g. dbus updates require a system reboot but that's nothing systemd can magically solve.
We don't want any service besides pid 1 to re-ecec itself. It's just to fragile to get right. [...] You can upgrade/restart many services without interruption.
Maybe you didn't run "systemctl restart dbus.service" today to watch your login session collapse :-)
Sure, why would I do that. I know that it doesn't work. :) Not sure if a D-Bus that can re-execute itself would be much better. It's just very hard to get right.
No doubt that systemd taking care of listening sockets is useful for simple, more or less stateless services. Starting udevd that way isn't too impressive though. As soon as you have more connections and state information associated with the connections the application needs to do the hard work though, no matter whether started via systemd or not.
The current idea is to move the D-Bus data transport into the kernel on top of linux unix domain broadcast sockets. Kernel patches already exist. There are quite a few things to sort out, but people are working on it already. That could solve some parts of the restart problem.
Next dbus security update is already in the queue btw.
Sure, not saying it's optimal. But still, don't really get what you mean, and examples that don't work always exist, but don't make the ones who do any less attractive. We pass the /dev/log systemd-kmsg-bridge that way over to rsyslog. If rsyslog will crash, or get stopped, we just start the kmsg bridge again automatically, and rsyslog coming back will take it over again. All that works before any other process than init exists, not sure if there is much to argue. :) Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org