Re: automatic and manual socket unit dependencies

[Mantas Mikulėnas <grawity@xxxxxxxxx>]

On Thu, Dec 5, 2024 at 1:29 PM Windl, Ulrich <u.windl@xxxxxx> wrote:

Hi!

 

I wonder: If a socket unit is using an TCP/IP (v4) stream socket, can’t systemd deduce that the socket should start *after* the network had been set up?

It technically could watch netlink for that, but likewise you could use [Socket] FreeBind=yes to avoid the need to wait for the network in the first place.

(Also, I'm not sure if netlink events can be filtered, and on servers/routers that run BGP with frequent routing updates it already leads to quite a bit of CPU use from things like networkd or strongswan that try to monitor the whole thing...)

 

 

Specifically I had the case in SLES15 SP6 (systemd-254.18-150600.4.15.10.x86_64) that this socket unit failed to start after the paths target:

 

# /usr/lib/systemd/system/omni.socket

[Unit]

Description=DATA-PROTECTOR-INET

PartOf=omni.service

 

[Socket]

ListenStream=172.20.2.24:5565

Accept=yes

MaxConnections=1000000

MaxConnectionsPerSource=100000

TriggerLimitIntervalSec=0

TriggerLimitBurst=0

 

[Install]

WantedBy=sockets.target

 

The corresponding service unit was:

# /usr/lib/systemd/system/omni@.service

[Unit]

Description=DATA-PROTECTOR-INET

Requires=omni.socket

 

[Service]

StandardInput=socket

PIDFile=/var/run/omni.pid

ExecStart=/opt/omni/lbin/inet -log /var/opt/omni/log/inet.log

SuccessExitStatus=0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 …the list is as long as you can imagine!

Avoid this nonsense by using ExecStart=-/opt/omni/lbin/inet.

 

Type=simple

KillMode=process

 

[Install]

WantedBy=default.target

BTW: Don’t ask ME why the service is a template unit when no instance parameter is being used.

You specified Accept=yes – explicitly requesting "fork a new process for each connection" mode – which obviously needs a template service so that multiple instances of it could be run for multiple connections, and the socket 4-tuple becomes the instance parameter to differentiate them.

 

 

Related is the question whether this dependency is OK or not:

 

# /usr/lib/systemd/system/sshd.service

[Unit]

Description=OpenSSH Daemon

After=network.target

 

[Service]

Type=notify

EnvironmentFile=-/etc/sysconfig/ssh

ExecStartPre=/usr/sbin/sshd-gen-keys-start

ExecStartPre=/usr/sbin/sshd -t $SSHD_OPTS

ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

ExecReload=/bin/kill -HUP $MAINPID

KillMode=process

Restart=on-failure

RestartPreventExitStatus=255

TasksMax=infinity

 

[Install]

WantedBy=multi-user.target

Should it “Wants=” or “Requisite=” network.target, too?

Does it make sense for a manual 'systemctl start sshd' to also start the network? I'd say Requisite= would make sense, but Wants= a bit less so. (I'm reminded of situations where, if you booted into single-user mode and attempted to start udev, it would also start everything up to Xorg; it was annoying.)

--

Mantas Mikulėnas