On Thu, 30.03.17 09:53, John Florian (j...@doubledog.org) wrote: > On Thu, 2017-03-30 at 15:32 +0200, Lennart Poettering wrote: > > On Wed, 22.03.17 16:47, John Florian (j...@doubledog.org) wrote: > > > > > 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 > > > > 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=) > > > > 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
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... 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. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel