Restart policy needed for sshd.service
Description:
On any of the devices I've set up with Arch over the past few years, or devices I've bought that come shipped with Arch (Steam Deck), I've always experienced this issue. After configuring sshd_config, and enabling sshd.service, the service will often fail after a reboot. For some devices like the Steam Deck, this seems to actually interrupt launching the graphical desktop, and requires switching to a TTY to remedy. In the case of devices like the servers in my workshop, I have to put on pants, and physically go to them to resolve the issue.
Investigation into the service state will show:
Arch systemd[1]: sshd.service: Service hold-off time over, scheduling restart.
Arch systemd[1]: Stopped OpenSSH Daemon.
Arch systemd[1]: sshd.service: Start request repeated too quickly.
Arch systemd[1]: Failed to start OpenSSH Daemon.
Arch systemd[1]: sshd.service: Unit entered failed state.
Arch systemd[1]: sshd.service: Failed with result 'exit-code'.
This is overcome by simply stopping the service, and starting it again. The cause for the initial failure seems to vary greatly, but it seems apparent that sshd was eager to start, other things weren't ready for it to start, and sshd just needed to wait a brief moment longer in order to start successfully. I can say for certain that the default configuration of sshd.service can result in it being caught in an infinite restart loop that gets killed for starting to quickly, and that's not ideal.
In the past, I would modify the sshd.service file directly, and add RestartSec=15s
to the [service]
section, but I noticed that this does not survive updates.
My permanent fix is to now create a /etc/systemd/system/sshd.service.d
directory, and within it a sshd-restart-policy.conf
drop-in file, which contains:
[Unit]
StartLimitInterval=60s
StartLimitBurst=3
[Service]
Restart=always
RestartSec=15s
I can't claim any strategic brilliance behind the values I've chosen, but I understand what they do, and know that they work.
I want to propose that sensible values from the above configurations get added directly to the systemd.service
file, or that we add a restart policy drop-in config, and update the PKGBUILD.