Fedora 41/42 images do not always start the ssh service

[cquike]

This is a follow up of #883 . I am afraid that it is actually not completely solved.

It seems that now sometimes the sshd service is started and sometimes it doesn't. In my incus cluster that happens roughly 50% of the time. I don't really now what makes systemd think that sometimes it can trigger it while sometimes it does not.

The way to reproduce is basically the same as in #883. But after starting the container I reboot it and check whether sshd.service is running and I do that several times. As said, around half of the times the service is in the inactive (dead) state.

[stgraber]

I can see that behavior though this time I don't have an explanation for it.

sshd starts as part of multi-user.target which now is correctly starting.
I can confirm it is part of that target too. Its other dependencies are on both network.target and sshd-keygen.target, both of which are also started.

[cquike]

Just some minor update on this: I see this also for Fedora 40. However older images of Fedora 40 worked in the past.

Also, if I restart sshd manually I see the following message:

May 23 15:05:45 pipe-fedora40-amd64-cij01 systemd[418]: Queued start job for default target default.target.
May 23 15:05:45 pipe-fedora40-amd64-cij01 systemd[418]: Created slice app.slice - User Application Slice.
May 23 15:05:45 pipe-fedora40-amd64-cij01 systemd[418]: grub-boot-success.timer - Mark boot as successful after the user session has run 2 minutes was skipped because of an unmet condition check (ConditionVirtualization=!container).

Also, some containers start sshd properly when "booting" while others no, so it seems there is some kind of race condition.

[cquike]

BTW, the message above appears in Fedora 40 but not in Fedora 41 or 42.