Comment 20 for bug 2004551

Sadly, or better gladly, Pitti killed most of my theories which were around the transition from pre-socket to socket-activated mode. Thanks for stopping me from doing more debug that way :-)

FYI - There recently has been bug 2020474 fixed in Mantic.
It seems to be rather similar and throws another tunable into the mix, having proposed enabled or not.
See comment #17 in that bug for more.
Sadly - the example by Andreas in comment #19 is after this fix for mantic. So it can't be all that is needed.

Anyway this made me realize I was trying to recreate on mantic (which I now know has this fix) while it was seen on lunar before.

So I removed all I had on mantic and went back to Lunar ... trying to look for weird state combinations to trigger this.

In the background I ran:
$ while /bin/true; do sleep 0.1s; for s in ssh.service ssh.socket; do printf '%15s: %15s %15s ' "$s" "$(systemctl is-enabled $s)" "$(systemctl is-active $s)"; done; printf "\n"; done

And in another session I ran server actions or loops of actions.

After install:
    ssh.service: disabled inactive ssh.socket: enabled active
logging in via ssh:
    ssh.service: disabled activating ssh.socket: enabled active
    ssh.service: disabled active ssh.socket: enabled active
upgrade or re-install pkg
    ssh.service: disabled inactive ssh.socket: enabled inactive
    ssh.service: disabled inactive ssh.socket: enabled active

So much for states and states that are to be expected.
But so far no matter how many concurrent re-installs, downgrades (to 1:9.0p1-1ubuntu8), upgrades, enable/disable, ssh logins, ... I did - I could not yet trigger the problem in an isolated reproducible environment.
As Robie said, we are looking for someone able to fill that gap to continue ...