Support systemd socket-based activation

[guignome]

Description

systemd can start services "on-demand", when a client connects to a socket. This works by having systemd listen on a socket, start the relevant service when a client connects to the socket, and pass the file descriptor of the socket to the service.

This would allow devops teams to run many Quarkus applications on limited hardware, by only starting quarkus applications as-needed.

Example /etc/systemd/system/quarkus-app.socket

[Unit]
Description=Quarkus App Socket

[Socket]
ListenStream=8080
Accept=No

[Install]
WantedBy=sockets.target

And the matching /etc/systemd/system/quarkus-app.service

[Unit]
Description=Quarkus App
Requires=quarkus-app.socket
After=syslog.target network.target


[Service]
SuccessExitStatus=143
WorkingDirectory=/opt/quarkus-app/target
EnvironmentFile=/etc/systemd/system/quarkus-app.env
ExecStart=/usr/bin/java -jar /opt/quarkus-app/target/quarkus-app/quarkus-run.jar
StandardInput=socket

[Install]
WantedBy=multi-user.target

Implementation ideas

Similar socket activation for NodeJS apps

Podman socket activation

[guignome]

The .socket and .service files provided in the description will properly start a quarkus application when a client connects to the socket. But the quarkus application then dies with the following exception:

quarkus-run.jar[1051563] ERROR [io.qua.run.Application] (main) Port 8080 seems to be in use by another process. Quarkus may already be running or the port is used by another application.

[melloware]

@guignome isn't that what this extension is for? see: https://github.com/quarkiverse/quarkus-systemd-notify

[guignome]

@melloware My understanding is that the Quarkus systemd notify extension is used to tell systemd when a quarkus app starts or stops. Whereas what is needed here is for a quarkus application to receive its preinitialized sockets from systemd, instead of creating them internally

[dmlloyd]

The main task would be figuring out a way to get java.lang.System#inheritedChannel communicated over to the HTTP layer somehow. A secondary task would be disabling console logging or other console I/O which would probably do something bad in this case.