systemd "socket activation" vs xinetd

I don’t think systemd socket activation is significantly better than xinetd activation, when considered in isolation; the latter is stable too and has been around for longer. Socket activation is really interesting for service decoupling: it allows services to be started in parallel, even if they need to communicate, and it allows services to be restarted independently.

If you have a service which supports xinetd-style activation, it can be used with socket activation: a .socket description with Accept=true will behave in the same way as xinetd. You’ll also need a .service file to describe the service. The full benefits of systemd socket activation require support in the dæmon providing the service. See the blog post on the topic.

My advice tends to be “if it isn’t broken, don’t fix it”, but if you want to convert an xinetd-based service to systemd it’s certainly feasible.

You can use either xinetd or systemd for socket activation, both will work. I personally find xinetd easier to use because everything is in one file, but have also used systemd because it is more flexible, especially with listening on multiple addresses and socket forwarding to UNIX sockets and not just to IP sockets.

Here as an example I used to forward TCP connection to the MySQL file socket:

/etc/systemd/system/mysql-proxy.service

[Unit]                                                  
Description=MySql Proxy Service
Requires=mysql-proxy.socket

[Service]
Environment=MYSQL_PROXY_TARGET=/var/run/mysql/mysql.sock
EnvironmentFile=-/etc/sysconfig/mysql-proxy
ExecStart=/usr/lib/systemd/systemd-socket-proxyd ${MYSQL_PROXY_TARGET}

/etc/systemd/system/mysql-proxy.socket

[Unit]                                                  
Description=MySql Proxy Socket

[Socket]
ListenStream=192.168.1.1:3306
ListenStream=192.168.2.1:3306
NoDelay=true
FreeBind=true

[Install]
WantedBy=sockets.target

Traditional forwarding needs Accept=true, systemd aware processes are supposed to handle multiple connections in one process or fork additional processes as required.