[sshd] Require network.target before starting up

rakoo · 2023-10-16 16:33:31

Hey there,

Currently the sshd service file contains the following:

[Unit]
Description=OpenSSH Daemon
Wants=sshdgenkeys.service
After=sshdgenkeys.service
After=network.target

What this means is that when sshd starts, network.target starts, but it doesn't wait for network.target to finish; crucially, some interfaces may take some time to be up. The issue is that sshd will start even if it can't listen on some of the interfaces; it won't automatically pick it up once interfaces are started. A manual operation is required to restart sshd after interfaces are up.

The fix is simple: add

Requires=network.target

to wait for the network to be started; one can do it on their own installation, but is it reasonable to put it in the standard sshd service that archlinux provides ? Or should everyone configure it on their own installation ?

mpan · 2023-10-17 06:26:47

Hello,

I assume, that you are not experiencing any actual problem with sshd.service (it shouldn’t require being online to start) and this is a request for comments.

`After` (and `Before`) determine the order in which units are activated or stopped, if activation happens. Neither of them triggers activation.

`Requires` (and `Wants`) triggers activation, but does not put the invoking unit in control of when the other unit is considered active. That remains entirely in the other unit. And it does not control order: that is what `After` and `Before` do.

So adding `Requires` doesn’t achieve what you think it does. The effect you observe is a coincidence. That would be true for any similar situation, but it’s in a very special way true for your case: network.target itself does not make guarantees you ascribe to it. So, even if the `Requires` idea would have any effect, it would mean nothing.

At startup network.target implies almost nothing. In particular it doesn’t mean network is available or in any specific state. Its primary use is at shutdown: units in `After` relationship with network.target are deactivated before network.target itself. This is why sshd.service declares this relationship.

If you want for a unit to wait for network to be available, you must configure it in a way specific to your system setup. That will usually mean depending on network-online.target. But be aware that network-online.target itself is not by itself making any detection and everything depends on your network manager.

What a network manager considers as “being online” is also imprecise. Which brings us to the question you asked at the end. Yes, everyone should configure it on their own installation. The nature of the problem itself makes an universal, one-size-fits-all solution impossible.

seth · 2023-10-17 07:25:13

Speculating on that sth. might have triggered this inquiry, are you running into a race condition w/ the NIC being renamed?
https://wiki.archlinux.org/title/Networ … face_names - eg. iwd runs into that…

gcb · 2024-02-16 12:07:11

This is a flaw on arch setup.

> I assume, that you are not experiencing any actual problem with sshd.service (it shouldn’t require being online to start) and this is a request for comments.

yes, but.

pacman-init have:
```
Before=archlinux-keyring-wkd-sync.service shutdown.target cloud-final.service sshd.service
After=systemd-journald.socket time-sync.target basic.target system.slice sysinit.target
```

which means it will block sshd, and wait for time-sync.target.

time-sync.target starts a whole chain reaction that causes things to wait forever, with no log messages anywhere nor timeouts. And the before/after mix up there causes most systemd administrative tools be to total and complete garbage and gives no visibility. You can `systemctl list-dependencies --all sshd` all day and not get any wiser.

this is extra funny because:

1. ssh tries to start
2. systemd delays it until pacman-init
3. which is delayed by timesync-target
4. which is delayed by ntp
5. which is delayed by resolved
6. which is delayed by network reachability (maybe it works if you have a local dns?)

and then when you get network access:
1. it starts resolved
2. which allows ntp to run.
3. reaches timesync target
4. only NOW systemd looks at the rest of the pacman-init unit and goes "oh, this is ConditionFirstBoot=yes, so i don't have to do anything. yolo"

sigh.

seth · 2024-02-16 13:29:55

I'm not sure how this is supposed to be related to the subject at hand, but pacman-init is part of archiso, why is that enabled/active on your system?

Arch Linux

#1 2023-10-16 16:33:31

[sshd] Require network.target before starting up

#2 2023-10-17 06:26:47

Re: [sshd] Require network.target before starting up

#3 2023-10-17 07:25:13

Re: [sshd] Require network.target before starting up

#4 2024-02-16 12:07:11

Re: [sshd] Require network.target before starting up

#5 2024-02-16 13:29:55

Re: [sshd] Require network.target before starting up

Board footer