This is messed up, totally messed up:

"On upgrades from Ubuntu 22.04 LTS, users who had configured Port settings or a ListenAddress setting in /etc/ssh/sshd_config will find these settings migrated to /etc/systemd/system/ssh.socket.d/addresses.conf."

It's like Canonical is doing 1960's quality acid.

At least the garbage can be disabled:

"it is still possible to revert to the previous non-socket-activated behavior"

With having to remove snapd then mark it to not be installed and in the next Ubuntu having to fix ssh back to the current behavior, it might be easier to migrate my servers back to Debian, or look for a solid non-systemd OS.

What exactly is "garbage" about this? It's so tiring how systemd opponents insist on name-calling instead of substantiated criticism.

There is no reason every single application should manage network socket acquisition on its own - I'm not very fond of the times everyone and their mother wrote whacky shell scripts to start and stop their services, either. But somehow those seem to be the "good old times" you guys miss.

I don't think its a systemD thing. This sounds more like an issue with changing a server's behaviour without asking.

Distribution upgrades have never been an unobtrusive thing. Despite this, everything will continue working exactly as configured before the upgrade, which applies new configuration recommendations by the vendor. What is wrong with that?

What's wrong is the config file moved. If a sysadmin is used to a config file being somewhere they know, and then it disappears that can be extremely frustrating. Especially on a production system.

Which the sysadmin knows, because they reviewed the changelog for the major system upgrade they just did. You wouldn’t install a new major version of a database without any precautions either, right?

> because they should have reviewed the changelog

I.. uhh.. Yeah.

No, seriously, my point is: can you blame anyone else if you don’t?

Certainly for SSH I find this a bad idea. If you need to ssh into a troubled machine then it might very well be it cannot be started.

I don't necessarily think it's an outright bad idea, but it's certainly a departure from how sshd is traditionally run, and without awareness of this kind of change, this kind of "magic" runtime change could lead you to not expecting sshd to be unavailable in this kind of a scenario, and increase time to resolution during an incident.

If your systems are more pets than cattle, then I think I too would prefer an always-running ssh daemon. If your workflow is only to ssh into machines during bootstrap, however, then having sshd run only during initial bootstrap and then shut itself off does seem like a nice way to free up a small amount of resources without stopping or disabling the daemon post-bootstrap.

If it's so troubled that a process won't start, it's probably time to reach for the IPMI console. Even if ssh is still running, if the system is that broken, is bash going to start, or what tools you might need?

I've rescued pretty messed up systems before. In one case, a service went haywire and created tens of millions of <1kb files, eating up all the available inodes in the filesystem. The volume was only ~45% full, but you couldn't make any new files. If that happened here, it's unlikely the ssh process could start correctly since it creates locks, logs, and pid files. Those are mostly in /run, so it might be okay, but it does make me a bit antsy.

TBH - for any non-server class machine on my network, I'm fine with that.

SSH should probably be running 24/7 on any server(to keep those resources allocated for maintenance access), but if it's my workstation with a monitor - then it's a non-issue.

Ew