[systemd-devel] automatic and manual socket unit dependencies

[Mantas Mikulėnas]

On Thu, Dec 5, 2024 at 1:29 PM Windl, Ulrich <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/43c31ba7/attachment.htm>