Mailinglist Archive: opensuse-factory (710 mails)

< Previous Next >
Re: [opensuse-project] Re: [opensuse-factory] The road to systemd for openSUSE 12.1
  • From: Kay Sievers <kay.sievers@xxxxxxx>
  • Date: Thu, 16 Jun 2011 15:54:42 +0200
  • Message-id: <1308232483.2794.16.camel@mop>
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. :)


To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
This Thread