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

[Mark Bannister]

On Wed May 6 17:49:02 UTC 2020, Kumar Kartikeya Dwivedi <memxor at
gmail.com> wrote:
> This issue is NOT reproducible with the version you reported
> originally. The stock CentOS image on my cloud provider comes with the
> same version (219-67.el7_7.4) that you said you see this issue with,
> but that can't be, as it doesn't include this change:
> https://github.com/systemd-rhel/rhel-7/commit/0600681f04e3818282a2d518ec3e6afee85f7978,
> unless I'm missing something. It took me a while to figure this out...

You're missing something, although I don't know what, because we're
definitely seeing this on 219-67 from
http://vault.centos.org/7.7.1908/os/Source/SPackages/ and it
definitely does not contain the change that you've linked to.  The
only custom patch we've applied is
https://github.com/systemd/systemd/commit/cf99f8eacf1c864b19a6a02edea78c43f3185cb7.
Something else is clearly going on here.

Thanks for the suggestions on how to reproduce.  I managed to
reproduce it once (first time lucky) with:

# service=$(systemd-run --uid=$RUNUSER /tmp/myscript 2>&1 | awk
'{sub("\\.$", ""); print $NF}'); systemctl --no-block stop $service &
systemctl --no-block stop user-$RUNUID.slice; sleep 1; systemctl
list-jobs

... where /tmp/myscript is:

#!/bin/sh
trap '' INT TERM HUP
sleep 1d

However, after the first success, repeated attempts failed to reproduce it.

> All in all, you can't do much about these errors, they're mostly
> harmless (at worst you need to retry the login)

While most of the time this is triggered by SSH session, I have
discovered that we have one script that is using systemd-run and which
failed to launch a command with this 'transaction is destructive'
error.  Could it be that when this problem is triggered, a systemd-run
could fail?

> and upgrading to v228
> (the patchset mentioned in the previous exchange) or higher should fix
> all of this for you.

Alas systemd is so big and so baked into everything these days that we
daren't do more than add a handful of custom patches to the version
shipped with the release.  So if there is a small patch we can add
that fixes it in both 219-67 and 219-73, that would be immensely
helpful.

Best regards
Mark