On Thu, Dec 5, 2024 at 1:29 PM Windl, Ulrich <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
