[systemd-devel] systemd-run returns with 'Failed to start transient scope unit: Unit run-13034.scope already exists.'

[Lennart Poettering]

On Thu, 15.10.15 13:25, Petr Horacek (phoracek at redhat.com) wrote:

> Hello,
> 
> recently we encountered strange systemd problem on automated tests of
> networking
> part of oVirt VDSM project.
> 
> Sometimes this happens:
> $ /usr/sbin/ifdown enp1s0f1
> $ /usr/bin/systemd-run --scope --slice=vdsm-dhclient /usr/sbin/ifup enp1s0f1
> Failed to start transient scope unit: Unit run-13034.scope already exists.
> 
> systemd-run should create a new scope every time it's called, should not
> it? Could it be
> a racefull bug in systemd?

The code for this is actually really naive... the number is just the
PID of the caller, and there's no check at all to ensure it is
unique. PIDs overrun easily, hence this is not nice at all...

What's even worse: when you use -H or -M to invoke things remotely we
still pick the client side PID for the name....

I figure we should rework this to pick some sufficiently large random
token instead, so that this is unlikely to conflict without actually
having to check for conflicts.

In the meantime, you should be able to fix this by explicitly picking
a randomized name for the scope using --unit=. For example, consider
just adding --unit=`uuidgen` to your command line, and the clashes
should not happen anymore.

> I found recently added issue [1] which describes similar problem,
> but with --unit instead of --slice. Note that our machine which
> reproduced it has systemd older than v220.
> 
> Is it possible, that this is the same case as described in [1] and
> therefore it should be
> fixed in systemd 220?
> 
> Is it possible to backport [1]'s fix to EL7?

Well, there are still cases where we unable to clean up scope units
properly, because we don't get any notifications for them when they
run empty. But yeah the current upstream versions should be better
than older versions.

Lennart

-- 
Lennart Poettering, Red Hat