caddy socket activation (bind fd/N, bind fdgram/N) only works with a single systemd.socket file, limiting configurability

[codyps]

systemd.socket files apply many of the options specified therein to all the sockets defined in the systemd.socket file. For example: BindToDevice. Systemd supports using multiple socket files for a single service, but does not define an ordering of the sockets between those socket files. Instead, systemd provides the names of the socket files within environment variables (LISTEN_FDS and LISTEN_FDNAMES combine to name the fds).

To enable the full flexibility of socket activation, caddy could allow binding to fds based on these names.

This is especially useful as caddy does not have BindToDevice (SO_BINDTODEVICE) nor FreeBind (SO_FREEBIND) support, meaning socket activation is the only way to obtain those today.

[Ko496-glitch]

@codyps can i take on this issue ?

[codyps]

@Ko496-glitch sure. 👍

For reference, sd_listen_fds_with_names() is the function systemd provides for C code to obtain this info, and the man page linked here also has some details on the internal behavior with respect to what the env variables contain.

[eriksjolund]

If there are multiple sockets inside one socket unit, they all share the same file descriptor name.

Should the fd be identified by a two-tuple? First a name to identify the socket.unit and then an order number to identify the socket inside the socket unit.

Or should only the name be used?

(I'm not sure what's best)

[Siomachkin]

Hi! I've implemented a solution for named socket activation support. Here's what I did:

• Added getFdByName() function that reads LISTEN_FDNAMES environment variable
• Extended ParseNetworkAddressWithDefaults() to handle fdname/name and fdgramname/name syntax
• Converts named references to fd/N internally, so all existing code works unchanged