[systemd-devel] [EXT] Re: automatic and manual socket unit dependencies

[Windl, Ulrich]

Mantas,

Thanks for pointing out the relationship between “Accept=yes” in the socket unit and the service unit being a template. I missed that; probably because the service is started rarely.

Kind regards,
Ulrich

From: Mantas Mikulėnas <grawity at gmail.com>
Sent: Thursday, December 5, 2024 2:39 PM
To: Windl, Ulrich <u.windl at ukr.de>
Cc: systemd-devel at lists.freedesktop.org
Subject: [EXT] Re: [systemd-devel] automatic and manual socket unit dependencies

On Thu, Dec 5, 2024 at 1:29 PM Windl, Ulrich <u.windl at ukr.de<mailto:u.windl at ukr.de>> 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 at .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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241205/68dc2e25/attachment-0001.htm>