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

[John Florian]

On Thu, 2017-03-30 at 16:04 +0200, Lennart Poettering wrote:
> 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...

Yup, I was aware of that of neat feature...

> 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.

Bingo!  That was just what I needed to put my train of thought on a
different set of tracks.  systemctl status sshd.socket showed that it
was enabled and the vendor preset was also enabled.  Wait...
what????   My package that contains the 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.

Thank you so much for your time and wisdom.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170330/e2f8df66/attachment.html>