RFE: support for FD passing (*inetd/systemd)

[eliasp]

Request for Enhancement

Support for FD passing (*inetd/systemd)

To solve the problem of having Caddy running as privileged user to be able to bind ports below 1024, a common solution is to simply use a service manager with socket activation support ("legacy style" via *inetd, "modern style" via systemd).

This requires the process which is intended to bind sockets to accept FDs from a privileged parent process (*inetd/systemd) which are then used to bind to.

The implementation is relatively trivial as outlined in this blogpost:

package main

import (
    "log"
    "net"
    "net/http"
    "os"
    "strconv"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello World!"))
    })

    if os.Getenv("LISTEN_PID") == strconv.Itoa(os.Getpid()) {
        // systemd run
        f := os.NewFile(3, "from systemd")
        l, err := net.FileListener(f)
        if err != nil {
            log.Fatal(err)
        }
        http.Serve(l, nil)
    } else {
        // manual run
        log.Fatal(http.ListenAndServe(":8080", nil))
    }
}

A systemd setup making use of socket activation to run Caddy unprivileged would look like this:

systemd service unit (/etc/systemd/system/caddy@.service)

[Unit]
Description=Caddy HTTP/2 web server for %I
Documentation=https://caddyserver.com/docs
After=network-online.target
After=sockets.target
Wants=network-online.target
Wants=systemd-networkd-wait-online.service

[Service]
User=%i
Group=%i
ExecStart=/opt/caddy/caddy -agree=true -conf=/etc/caddy/Caddyfile.%i
Restart=on-failure
PrivateTmp=true
LimitNOFILE=8192

[Install]
WantedBy=multi-user.target

systemd socket unit (/etc/systemd/system/caddy@service-foo.socket)

[Unit]
Description=Socket for Caddy (%i)

[Socket]
ListenStream=80
ListenStream=443
[Install]
WantedBy=sockets.target

All that's needed now is:

• to make sure the caddy@service-foo.socket is started on boot: systemctl enable caddy@service-foo.socket
• to start the socket once initially: systemctl start caddy@service-foo.socket

References:

• USENIX-Article about systemd with a lot of information about the concept of socket activation
• systemd socket unit documentation
• systemd sd_listen_fds() documentation

[mark-kubacki]

@eliasp This is sure a detailed and well presented RFE! 👍

Join us on Gitter, where we consider these things!

[mholt]

I wonder how this would affect Caddy's restarts. It uses fd 3 for other things in that case.

[mark-kubacki]

I will iterate on this after #777, https://github.com/caddyserver/caddyserver.com/pull/41, and https://github.com/caddyserver/buildsrv/pull/22 if no one opposes.

[mark-kubacki]

While implementing support for systemd notify I've been told such a tight integration were not sought at the moment. As the aforementioned feature did not make it in I won't pursue this one.

[KellerFuchs]

@wmark I don't get it: are you saying you don't plan to implement socket activation because there are no plans to support systemd notify?
What is the dependency between the two? Type=simple services can definitely be socket-activated.

P.S.: I just read #777 (comment), now this makes sense.

[flokli]

@mholt stumbled over this today, and got confused about the "closed as completed" part.

I'd very much like to use caddy in a socket-activated environment. These days, the FDs can also be named, which should make identifying them much easier, as well as letting the init system take care of zero-downtime deployments. If we use FDs passed by the service manager, we can simply spin up a new caddy with a new configuration, and get all new connections routed to the new service.

[mohammed90]

@mholt stumbled over this today, and got confused about the "closed as completed" part.

I'd very much like to use caddy in a socket-activated environment. These days, the FDs can also be named, which should make identifying them much easier, as well as letting the init system take care of zero-downtime deployments. If we use FDs passed by the service manager, we can simply spin up a new caddy with a new configuration, and get all new connections routed to the new service.

This is closed 8 years ago during the era of Caddy v1. The v2 of Caddy is written from scratch. Please file a new issue with an explanation of your needs and the reasoning.

[flokli]

Will do, thanks!

[flokli]

I opened #6296, PTAL.