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 <graw...@gmail.com> Sent: Thursday, December 5, 2024 2:39 PM To: Windl, Ulrich <u.wi...@ukr.de> Cc: systemd-devel@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.wi...@ukr.de<mailto:u.wi...@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@.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
