Inscreva-se no feed

Serverless is an event-driven computing paradigm where applications are allocated dynamically to serve a request or consume events. When the application is not in use, there are no computing resources allocated.

The serverless ecosystem offers a large number of runtimes, which start/stop/monitor software (e.g., Knative, Kubeless and many others). They come with different features, and they can trigger applications based on different kind of events (e.g., HTTP requests, messages, etc.).

Even if systemd cannot be considered a real serverless runtime, the socket activation feature provides a foundation for a serverless architecture.

Socket activation

The concept of systemd socket activation is that the socket is created by systemd, when a connection is received on such socket the application is activated. The application must be prepared to receive an already-initialized socket instead of creating a new one, for this reason not all applications can natively support socket activation.

To overcome this limitation, systemd provides a proxy supporting the socket activation and is capable of forwarding the connection to another socket.

The proxy

Recently (in version 209) systemd introduced a new tool named systemd-socket-proxyd. This is a handy tool that can be used with applications not supporting socket activation.

systemd-socket-proxyd is a proxy supporting socket activation that can be used to bi-directionally forward traffic from a socket inherited from systemd to another unix or network socket.

From the main page of systemd-socket-proxyd: One use of this tool is to provide socket activation support for services that do not natively support socket activation. On behalf of the service to activate, the proxy inherits the socket from systemd, accepts each client connection, opens a connection to a configured server for each client, and then bidirectionally forwards data between the two.

Since Podman does not support socket activation natively, systemd-socket-proxyd can be used as a sort of wrapper to intercept the socket activation and spin up a container.

The idea

Let's use a system with IP address as an example. On this system we want to activate a rootless container running an httpd server exposing the HTTP service on port 8080.

Basically the flow is:

- systemd creates the TCP socket listening on using a .socket unit.

- Once the TCP socket is hit by a connection, the corresponding .service unit is activated. This service unit executes systemd-socket-proxyd and requires another .service unit that starts the container.


painless services 1

Why Podman?

Podman plays very well with systemd: here is a great video showing how podman can integrate with systemd to easily manage containerized services.

Podman can run rootless containers, and this post provides an overview of the advantages of rootless containers.

Let's do it

The following procedure has been tested on a Fedora 33 with systemd 246 and podman 2.2.1. The auto scale-down feature requires systemd 246, so it will not work on RHEL 8. However it's still worth understanding for future versions of RHEL.

As a first step we create the web server document root on the host and we put some dummy content: 

$ mkdir -p ~/www-data ; echo "Hello World" > ~/www-data/index.html

At this point we can create the httpd container. Please note that is exposing the port 8080 bound to the address, and this is important to avoid conflicts with the systemd socket listening on the same port but on a different address.

$ podman pull
$ podman create --name httpd -p \
    -v ~/www-data:/var/www/html/:Z

In order to define a user service we must create the systemd user units directory. From now we will work inside this directory:

$ mkdir -p ~/.config/systemd/user && cd ~/.config/systemd/user

As anticipated, podman can create the systemd unit files to manage the container, let's do it:

$ podman generate systemd -f -n httpd --new

The previous command generated a systemd unit file named container-httpd.service.

By default this unit file has an [Install] section that we don't need because the unit file should not be installed but activated only on-demand.

So we should edit the file and completely remove the [Install] section and all the contained directives.

Now we are ready to create the systemd socket, for that purpose we create an unit file named container-httpd-proxy.socket:

$ cat << EOF > container-httpd-proxy.socket


Please note that the socket is listening on  Leaving just the port number without the address will lead to a conflict with the container needing to open the port 8080.

At this point, we are ready to create the proxy service running systemd-socket-proxyd:

$ cat << EOF > container-httpd-proxy.service 


Since this will be the unit activated by the socket, it is important to name this unit the same as the socket.

As you can see, the systemd-socket-proxyd forwards the connection to where the container is listening.

The other fundamental bit of this file is the Requires=container-httpd.service which is triggering the podman container when the unit is activated.

Here we are now ready to activate the socket unit, which is the only unit file that must be enabled at the start-up:

$ systemctl --user daemon-reload
$ systemctl --user enable --now container-httpd-proxy.socket
$ # let's check if the socket is open:
$ netstat -ltpn | grep 8080

Test it

After creating the systemd unit files and activating the socket, we should have a TCP socket listening on the address and the container httpd should not be running.

Now sending an HTTP request to should trigger the container start:

$ curl
Hello World
$ podman ps
CONTAINER ID  IMAGE                              COMMAND               CREATED        STATUS            PORTS                     NAMES
c0cbdafc54ae  /usr/bin/run-http...  9 seconds ago  Up 8 seconds ago>8080/tcp  httpd

Auto scale-down

With that, the container is started at the first request but is never terminated.

To avoid unneeded resource usage the container should be stopped when not in use.

To achieve that, there is a couple of useful features:

- systemd-socket-proxyd --exit-idle-time: permits to define a timeout to terminate in case of no connections. This command switch has been introduced in version 246.

- adding StopWhenUnneeded=yes to the container-httpd.service unit will stop the container when the proxy unit is terminated.

Putting all together

Let’s have a look to all the systemd units:

$ systemctl --user cat --no-pager container-httpd-proxy.socket 

$ systemctl --user cat --no-pager container-httpd-proxy.service 

ExecStart=/usr/lib/systemd/systemd-socket-proxyd --exit-idle-time=30s
$ systemctl --user cat --no-pager container-httpd.service 
Description=Podman container-httpd.service

ExecStartPre=/bin/rm -f %t/ %t/container-httpd.ctr-id
ExecStart=/usr/bin/podman run --conmon-pidfile %t/ --cidfile %t/container-httpd.ctr-id --cgroups=no-conmon -d --replace --name httpd -p -v ${HOME}/www-data:/var/www/html/:Z
ExecStartPost=/bin/sleep 1
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/container-httpd.ctr-id -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/container-httpd.ctr-id
$ systemctl --user list-unit-files | grep container-httpd
container-httpd-proxy.service                                                          static    -            
container-httpd.service                                                                static    -            
container-httpd-proxy.socket                                                           enabled   disabled

Systemd opened the socket

$ netstat -ltpn | grep 8080
tcp  0  0*        LISTEN 12298/systemd

The `httpd` container is not running:

$ podman ps

Let’s send an HTTP request:

$ curl
Hello World

The request has been answered and the httpd container is started:

$ podman ps
CONTAINER ID  IMAGE                              COMMAND               CREATED        STATUS            PORTS                     NAMES
8487372aaadd  /usr/bin/run-http...  7 seconds ago  Up 6 seconds ago>8080/tcp  httpd

Let’s wait 30 seconds and check if the container is stopped:

$ sleep 30 && podman ps

As we can see the container is not running anymore. Sending another request will trigger a new start of the container:

$ curl
Hello World

$ podman ps
CONTAINER ID  IMAGE                              COMMAND               CREATED        STATUS            PORTS                     NAMES
ebede0c85103  /usr/bin/run-http...  4 seconds ago  Up 3 seconds ago>8080/tcp  httpd



Systemd and Podman can work very well together and thanks to the socket activation when a container is not serving any request can be stopped without keeping resources allocated.

Sobre o autor

Pietro Bertera is a Senior Technical Account Manager working with Red Hat OpenShift. He is based in Italy.  

Read full bio

Navegue por canal

automation icon


Últimas novidades em automação de TI para empresas de tecnologia, equipes e ambientes

AI icon

Inteligência artificial

Descubra as atualizações nas plataformas que proporcionam aos clientes executar suas cargas de trabalho de IA em qualquer ambiente

open hybrid cloud icon

Nuvem híbrida aberta

Veja como construímos um futuro mais flexível com a nuvem híbrida

security icon


Veja as últimas novidades sobre como reduzimos riscos em ambientes e tecnologias

edge icon

Edge computing

Saiba quais são as atualizações nas plataformas que simplificam as operações na borda

Infrastructure icon


Saiba o que há de mais recente na plataforma Linux empresarial líder mundial

application development icon


Conheça nossas soluções desenvolvidas para ajudar você a superar os desafios mais complexos de aplicações

Original series icon

Programas originais

Veja as histórias divertidas de criadores e líderes em tecnologia empresarial