Default services enabled

Mathieu Bridon bochecha at fedoraproject.org
Tue Aug 23 03:35:06 UTC 2011


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




More information about the devel mailing list