<html><head></head><body><div>On Thu, 2017-03-30 at 16:04 +0200, Lennart Poettering wrote:</div><blockquote type="cite"><pre>On Thu, 30.03.17 09:53, John Florian (<a href="mailto:john@doubledog.org">john@doubledog.org</a>) wrote: <blockquote type="cite"> On Thu, 2017-03-30 at 15:32 +0200, Lennart Poettering wrote: <blockquote type="cite"> On Wed, 22.03.17 16:47, John Florian (<a href="mailto:john@doubledog.org">john@doubledog.org</a>) wrote: <blockquote type="cite"> Mar 22 16:11:42 localhost systemd[1]: sshd.service: Looking at job sshd.service/start conflicted_by=no Mar 22 16:11:42 localhost systemd[1]: sshd.service: Looking at job sshd.service/stop conflicted_by=yes Mar 22 16:11:42 localhost systemd[1]: sshd.service: Fixing conflicting jobs sshd.service/start,sshd.service/stop by deleting job sshd.service/start </blockquote> So this suggests that you have both a job that pulls in sshd.service and one that conflicts with it in your initial transaction. Try figuring out what that is... (hint: use "systemctl show sshd.service" for that, and look for Conflicts= and ConlictedBy=) </blockquote> That seems like a reasonable theory, but given the following I can't make any sense of it. # journalctl -b | grep -i conflict Mar 30 09:35:57 localhost systemd[1]: sshd.service: Looking at job sshd.service/start conflicted_by=no Mar 30 09:35:57 localhost systemd[1]: sshd.service: Looking at job sshd.service/stop conflicted_by=yes Mar 30 09:35:57 localhost systemd[1]: sshd.service: Fixing conflicting jobs sshd.service/start,sshd.service/stop by deleting job sshd.service/start Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Looking at job sshd-keygen.target/start conflicted_by=no Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Looking at job sshd-keygen.target/stop conflicted_by=no Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Fixing conflicting jobs sshd-keygen.target/start,sshd-keygen.target/stop by deleting job sshd-keygen.target/stop # systemctl show sshd.service | grep -i conflict Conflicts=shutdown.target ConflictedBy=sshd.socket </blockquote> Note that you can use sshd on Fedora in socket-activated mode or non-socket-activated mode. In socket-activated mode, sshd.socket is started at boot, and for each connection one sshd@.service instance is created. sshd.service otoh is only used in the non-socket-activated mode, and in that case is the singleton service processing all connections... </pre></blockquote><div><br></div><div>Yup, I was aware of that of neat feature...</div><div><br></div><blockquote type="cite"><pre> My educated guess is that you somehow ended up pull in both sshd.service and sshd.socket, but you cannot really do that, you have to make a choice between them, as there's only one port 22, and it's either systemd that listens on it or sshd. </pre></blockquote><div><br></div><div>Bingo! That was just what I needed to put my train of thought on a different set of tracks. <span style="color: rgb(0, 0, 0); font-family: monospace;">systemctl status sshd.socket showed that it was enabled and the vendor preset was also enabled. Wait... what???? My package that contains the </span>sshd-persist-keys.service and sshd-restore-keys.service units also provides a file with unit presets and in there I had "enabled sshd.*". That was fine back in F21, but no so with F25 so I replaced that with a "enable sshd.service" and "disabled sshd.socket" and all is well now. It's funny, the problem seems so obvious now yet only an hour ago I was totally blind to the problem.</div><div><br></div><div>Thank you so much for your time and wisdom.</div></body></html>