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

[Kumar Kartikeya Dwivedi]

On Thu, 30 Apr 2020 at 16:56, Mark Bannister <mbannister at janestreet.com> wrote:
>
> 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.

Yes, this error is not raised by external jobs (when you use the
replace job mode, the job sitting in the unit's job slot is always
unseated if possible, and the other job either becomes 'runnable'
instantly, or in some cases waits for the other job to finish before
becoming runnable, emulating a queue (e.g. service unit's start job
waiting for the stop request initiated previously to finish). Even if
you use fail as the job mode, the error you get back is "Transaction
is destructive" or so, not this.

The problem you're seeing is caused when the same transaction pulls
two conflicting/unmergeable jobs, for example a unit being started
adds a start job and some unit in the dependency chain has Conflicts
on it, which would pull in a stop job for the same unit. These are
contradictory state change requests, and there's no easy way to
resolve this automatically (unlike merging where jobs that make the
unit reach a compatible state are merged into the same job).

This is has been reported before:
* The first one explains in detail when and why this happens:
https://github.com/systemd/systemd/issues/11440
* This one is more of a real life example:
https://github.com/systemd/systemd/issues/2830

The easiest way to debug problems like these is to enable debug
logging for the service manager, examine the transaction in the logs,
and inspect your units in the dependency chain to pin down the culprit.

--
Kartikeya