Control: tags -1 + moreinfo unreproducible Am 03.01.21 um 11:41 schrieb Colin Watson:
Control: reassign -1 systemdOn Sun, Jan 03, 2021 at 10:29:27AM +0100, Marc Haber wrote:On Fri, Jan 01, 2021 at 11:21:31AM +0000, Colin Watson wrote:On Fri, Jan 01, 2021 at 06:59:42AM +0100, Marc Haber wrote:with this last update of the Debian package, unstable systems that are using socket activated ssh lose ssh access (connection refused). It ie nscessary to do systemctl stop ssh.service, systemctl start ssh.socket to be able to log in again.
If you are using ssh.socket, ssh.service should be disabled and not running. Has something triggered the start of ssh.service which stopped ssh.socket?
What exactly was the previous version that worked? 1:8.4p1-3 didn't go anywhere near any of the machinery for socket activation (it only involved a small fix to the ssh-copy-id shell script), so it's hard to see what could possibly have gone wrong there. Is it possible you upgraded some other piece of systemd-related machinery at around the same time?ok, this is interesting. While this has rendered _all_ my unstable installations inaccessible via ssh, I have taken a closer look on the most simple machine, and have found out openssh didn't get upgraded during the apt session in question. Last ssh upgrade was on December 05 when 1:8.4p1-3 replaced 1:8.4p1-2. However there was a systemd upgrade from 247.2-2 to 247.2-3. I have saved the dpkg log in question. If there is anything more I can do to help, please let me know.I'll reassign this to systemd and see if they can work it out.
I can not reproduce the problem. If I run systemctl disable --now ssh.service systemctl enable --now ssh.socket apt install --reinstall systemdssh.socket keeps running. So at a first glance this doesn't look like a systemd problem.
Please provide a (debug) journal log, which shows the problem.
OpenPGP_signature
Description: OpenPGP digital signature
