[systemd-devel] How do I easily resolve conflicting jobs in custom units?

[Lennart Poettering]

On Thu, 30.03.17 09:53, John Florian (john at doubledog.org) wrote:

> On Thu, 2017-03-30 at 15:32 +0200, Lennart Poettering wrote:
> > On Wed, 22.03.17 16:47, John Florian (john at 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 at .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