On Mon, 2011-08-22 at 20:09 -0400, Genes MailLists wrote: > On 08/22/2011 07:07 PM, Adam Williamson wrote: > > On Sun, 2011-08-21 at 17:09 -0400, Steve Clark wrote: > > > >>> -Steve > >> Obviously a lot on this list value boot up speed over security! > > > > You're making a false assumption, which is that socket activation is > > only about speed. It's also about resource usage. (There may be other > > advantages I haven't considered, this is not to be considered an > > exclusive list.) > > > Mmmm Adam - not sure I'd give up security for a little resource saving > either ... if indeed that is the trade-off ... Well, socket activation gives you better speed and resource usage as already mentioned, but it also gives you: (from [1]) - We no longer need to configure dependencies explicitly. Since the sockets are initialized before all services they are simply available, and no userspace ordering of service start-up needs to take place anymore. Socket activation hence drastically simplifies configuration and development of services. - If a service dies its listening socket stays around, not losing a single message. After a restart of the crashed service it can continue right where it left off. - If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continously responsive. Not a single connection is lost during the upgrade. - We can even replace a service during runtime in a way that is invisible to the client. For example, all systems running systemd start up with a tiny syslog daemon at boot which passes all log messages written to /dev/log on to the kernel message buffer. That way we provide reliable userspace logging starting from the first instant of boot-up. Then, when the actual rsyslog daemon is ready to start we terminate the mini daemon and replace it with the real daemon. And all that while keeping around the original logging socket and sharing it between the two daemons and not losing a single message. Since rsyslog flushes the kernel log buffer to disk after start-up all log messages from the kernel, from early-boot and from runtime end up on disk. So basically, much improved service availability (which is what matters to your business, isn't it?), and easier configuration/maintenance (granted, once you've learnt the new commands/tricks). Knowing that the security issue is highly exaggerated (as Lennart has repeatedly stated, systemd doesn't read network packets), does that seem like a better trade-off? [1] http://0pointer.de/blog/projects/socket-activation.html -- Mathieu -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel