[systemd-devel] Socket based activation/deactivation

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Tue Aug 26 18:24:22 PDT 2014

On Tue, Aug 26, 2014 at 08:49:29PM -0400, Gary Mort wrote:
> Socket based activation for systemd is a really cool feature for my
> dev system.
> Prior to using socket based activation, on my dev system I would
> have 2 choices:
> 1) Automatically start mysql, apache, php fastcgi, memcached,
> mongodb and a dozen other services just in case I happen to be
> working with them on this particular bootup.
> 2) Manually start them when needed....usually /after/ trying to test
> something and discovering the service isn't running.
> With socket based activation, I can start up dozens of servers on
> different sockets and they won't bog my system down - they only
> truely activate if they are actually used.
> However, there is still a missing item to this feature[or it's not
> missing and I am simply unaware of it] - there is no way to do the
> reverse.  IE if apache is running on my server there is no way to
> configure things so if there are no active socket connections for 30
> minutes, have it automatically shutdown and pass the socket control
> back.
This has to be implemented in the service itself. After the service
has been started systemd does not monitor the socket and simply 
does not know when the service can be safely stopped. In addition
to the socket passed by systemd the service might have opened
additional channels of communication itself, or might be doing
some processing that systemd knows nothing about..., so only the
service knows when it has idle and how long it has been idle.
The service can close the socket and shut down. This is race free,
because if a connection comes on the socket in the meantime, it will
be queued by the kernel, and then when the service has shut down,
systemd will start it again.

Various systemd services like systemd-hostnamed do this kind of thing

> A lot of server admins don't
> like the idea of socket activation because it means that when they
> boot a server, they won't know if there is some blocker for a server
> to run[corrupted database files for example] until it is actually
> used.
Of course they can configure the services to start uncondtionally
by adding them to an appropriate target, so this is a really poor 

> ...
> So I'm curious if this feature is somewhere in socket activation I'm
> not aware of[it might simply be needing to write the proper systemd
> configuration files] or if it is something that would need to be
> added?
It needs to be added in the daemon.


More information about the systemd-devel mailing list