[systemd-devel] unable to attach pid to service delegated directory in unified mode after restart
Lennart Poettering
lennart at poettering.net
Thu Mar 3 17:45:38 UTC 2022
On Do, 03.03.22 18:35, Felip Moll (felip at schedmd.com) wrote:
> I have read and studied all your suggestions and I understand them.
> I also did some performance tests in which I fork+executed a systemd-run to
> launch a service for every step and I got bad performance overall.
> One of our QA tests (test 9.8 of our testsuite) shows a decrease of
> performance of 3x.
systemd-run is synchronous, and unless you specify "--scope" it will
tell systemd to fork things off instead of doing that client-side,
which I understand is what you want to do. The fact it's synchronous,
i.e. waits for completion of the whole operation (including start-up
of dependencies and whatnot) necessarily means it's slow.
> > But note that you can also run your main service as a service, and
> > then allocate a *single* scope unit for *all* your payloads. That way
> > you can restart your main service unit independently of the scope
> > unit, but you only have to issue a single request once for allocating
> > the scope, and not for each of your payloads.
> >
> >
> My questions are, where would the scope reside? Does it have an associated
> cgroup?
Yes, I explicitly pointed you to them, it's why I suggested you use
them.
My recommendation if you hack on stuff like this is reading the docs
btw, specifically:
https://systemd.io/CGROUP_DELEGATION
It pretty explicitly lists your options in the "Three Scenarios"
section.
It also explains what scope units are and when to use htme.
> I am also curious of what this sentence does exactly mean:
>
> "You might break systemd as a whole though (for example, add a process
> directly to a slice's cgroup and systemd will be very sad).".
if you add a process to a cgroup systemd manages that is supposed to
be an inner one in the tree, you will make creation of children fail
that way, and thus starting services and other operations will likely
start failing all over the place.
Lennart
--
Lennart Poettering, Berlin
More information about the systemd-devel
mailing list