Failed to restart sshd.service: unit network.service not found

Rocky Linux General
1

After reboot (most recent updates?), I am no longer able to restart the sshd service:

Failed to restart sshd.service: unit network.service not found

Any ideas how to fix this? It seems that network.service is no longer there, but then why is sshd.service asking for it?

Any help greatly appreciated!

2

The sshd.service file should have:

After=network.target sshd-keygen.target

if yours says network.service then it is wrong - so either something has edited this sshd.service file, or someone else has edited it. And this is the same on both Rocky 8 and 9.

3

The sshd.service file looks like you say it should. It requires network.target.
But still, when I do
systemctl restart sshd
I get the error message
Failed to restart sshd.service: unit network.service not found
Any ideas where this could come from?

4

Can you do:

systemctl status network.target

and post the output?

5

Looks normal:

● network.target - Network
   Loaded: loaded (/usr/lib/systemd/system/network.target; static; vendor preset: disabled)
   Active: active since Sun 2022-09-11 12:12:46 CEST; 9h ago
     Docs: man:systemd.special(7)
           https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

Sep 11 12:12:46 localhost.localdomain systemd[1]: Reached target Network.
6

I think ‘network.service’ is related to using “legacy” network-scripts, which would not be normal on Rocky 8 or 9.

7

Interesting. So are you saying it is something in my /etc/sysconfig/network-scripts/* that needs to be changed to fix this?

8

If it really is related to some legacy config, the first thing would be to think about how and why you’ve got a legacy config, e.g. do you have a pure new Rocky install using official repos, and everything using defaults? if so, this should not be happening.

9

It is a pure new rocky install. And this used to work, it stopped working after a reboot for no apparent reason. I was assuming that it’s related to some update that happened recently, but I’m not sure. It’s the first reboot in a couple of months.

10

Can you please post the output of systemctl status sshd.service and the content of /usr/lib/systemd/system/sshd.service ?

11

If it’s this, it can be ruled out very quickly by:

dnf remove network-scripts

since this legacy package can be installed although shouldn’t be by default. This package doesn’t exist in Rocky 9 though.

That said network.service doesn’t exist in this package anyway, so shouldn’t be related to this. I would be more inclined to check for the existence of /usr/lib/systemd/system/sshd.service and check the entire content of this file, and perhaps also do:

find /etc/systemd -iname sshd.service

and check that the results shows a symlink to the /usr/lib/systemd/system/sshd.service file using ls -l, or whether it’s a copy of the sshd.service that may have been edited/played around with.

No packages from doing a dnf repoquery search shows as providing network.service so it sounds like an incorrectly formatted sshd.service file.

12

Thanks very much for helping me investigate. You were right, there was an unusual modification.

Doing grep -R "network\.service" /etc/systemd, I found that there were additional config files under /etc/systemd/system/sshd.service.d/ which had references to network.service.

I replaced these by network.target and now it works fine.

13

Yes, that is the place where local customizations are put (for example, when you do systemctl edit sshd.service )

Systemctl does hint about that. Here is a service with default config:

# systemctl status sshd.service
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-07-28 18:33:15 EEST; 1 months 15 days ago

And another, with customization by local admin:

# systemctl status krb5kdc.service
● krb5kdc.service - Kerberos 5 KDC
   Loaded: loaded (/usr/lib/systemd/system/krb5kdc.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/krb5kdc.service.d
           └─override.conf
   Active: active (running) since Thu 2022-07-28 18:33:27 EEST; 1 months 15 days ago
14

So the problem has been found, but it doesn’t really explain how the customized version got there in the first place.