On Thu, 2011-06-16 at 13:18 +0200, Ludwig Nussel wrote:
Kay Sievers wrote:
On Wed, 2011-06-15 at 11:48 +0200, Kay Sievers wrote:
Le mercredi 15 juin 2011 à 09:08 +0200, Carl-Daniel Hailfinger a écrit :
So if I'm installing a web server machine with apache, it will boot quickly, but the first access to the server will take almost forever because nobody connected to port 80 before and thus apache wasn't started? Or does "use only what you need when you need it" not apply here (and if not, why)?
Socket activation is mainly used to simplify service startup and to avoid to express any dependencies, and not about on-demand start.
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.
With systemd you can even replace services like syslogd with a different implementation without ever losing a single message.
Well, I doubt that's relevant in practice
It is relevant. You can upgrade/restart many services without interruption.
and would only work for the local socket anyways.
No, it wouldn't.
Kind of funny that you take syslog as example though since you only care about rsyslogd.
I don't run any syslog at all on any of my private boxes, I don't need any files on disk, just the kernel bridge and 'dmesg'. And sure, I 'care' about the stuff that properly works together with upstream projects, and that is only the rsyslog guy, hence we recommend rsyslog, if syslog is needed, yes.
Services are also automatically restarted if a service crashes, without losing any new message submitted during the time the service was not available. Clients will never see connection refused.
These are mostly features enterprise users asked for, and what no other init can really provide or work around.
The plain old inetd could already do local socket activation¹. Maybe the name prevented people from using it for that purpose. Unfortunately xinetd lost the ability to use local sockets. Implementing it wouldn't be rocket science though.
That's not the point, you need advanced baby-sitting features, and dependencies. Being able to start things on a request base solves only a very tiny bit of the problem. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org