[systemd-devel] Requested transaction contradicts existing jobs: start is destructive

Mark Bannister mbannister at janestreet.com
Thu Apr 30 11:20:14 UTC 2020


> On Mon, 2020-04-27 at 11:40 +0100, Mark Bannister wrote:

> > One of the error messages I've been trying to explain is reported like this:
> > 2020-04-22T00:45:47.047710-04:00 jupiter systemd[1]: Requested transaction
> > contradicts existing jobs: Transaction for session-752473.scope/start is
> > destructive (user-16027.slice has 'stop' job queued, but 'start' is
> > included in transaction).

> > This also coincides with a message from sshd:
> > 2020-04-22T00:45:47.049949-04:00 jupiter sshd[20984]: pam_unix(sshd:session): session opened for user userlp by (uid=0)
> > 2020-04-22T00:45:51.181665-04:00 jupiter sshd[20984]: pam_unix(sshd:session): session closed for user userlp

> > I'm not sure where to begin to troubleshoot the problem.  The systemd
> > error is occurring sporadically and I haven't yet found a way to
> > reproduce it.  I also can't say I actually understand the error
> > message or what I'm supposed to do about it.  How is it even possible
> > for stop and start jobs to clash like this?

On Mon Apr 27 19:59:11 UTC 2020, Uoti Urpala wrote;
> See the systemctl documentation for the --job-mode option. Basically
> this should be due to an external request from somewhere to start the
> unit while systemd is in the middle of processing a previously started
> stop command for it.

The documentation says that the default option for --job-mode is "replace", i.e.
any conflicting pending job will be replaced, as necessary.

How does it make sense for systemd to allow stop and start requests to
contradict anyway?  This is the bit I'm finding very hard to understand.
I don't think your explanation can be right.  Surely, if a start command is
issued while a previous stop is still being processed, that is not an error.
The start request should be followed as soon as the stop is finished.

Also I'm unclear on what stop/start job is involved here, it's not sshd.service
that's going to stop and start when a session is opened for a user.


More information about the systemd-devel mailing list