[systemd-devel] Moving a service from one systemd slice to another..

Lennart Poettering lennart at poettering.net
Thu May 7 06:56:24 UTC 2020


On Do, 07.05.20 08:28, Tomasz Torcz (tomek at pipebreaker.pl) wrote:

> On Wed, May 06, 2020 at 11:53:14PM +0200, Lennart Poettering wrote:
> > > > >
> > > > >   You can use low-level cgroup access to move it. Something like:
> > > > > systemctl show --property MainPID --value your.service >
> > > > > /sys/fs/cgroup/NEW.slice/cgroup.procs
> > > >
> > > > You void your warranty if you do that. Moreover, on cgroupvs2 this
> > > > doesn't work really, since inner cgroups cannot have processes and
> > > > slices are by definition inner cgroups.
> > >
> > >   Doesn't work? I beg to differ, the following is on Fedora 31:
> > >
> > > Control group /:
> > > -.slice
> > > ├─kodi.slice
> > > │ └─2872766 /usr/lib64/kodi/kodi-wayland      ← here it has process
> >
> >
> > >  Is there an API in systemd to move specific program to a dedicated
> > >  slice?
> >
> > Use Slice= in the service file.
>
>   That would require having a service file.  I don't have it. I just have a
> single process in session which I need to treat specially.  Thus I move
> it to separate slice.  I have /etc/systemd/system/kodi.slice to define
> this separate slice and resource controls for it.

use "systemd-run --scope --slice=kodi.slice …" for that.

Really, if you muck around with the cgroup tree yourself you void all
warranty. I mean, it's Linux you can do whatever you want, but it's
certainly outside of how this is intended to be used, i.e. the
cgroupsv2 "single writer" concept.

> > If you want to run kodi as user service, then assign your user the
> > resources you want to assign to kodi, and then distribute them from
> > there to kodi, and reduce it for the rest.
>
>   This user has a bunch of other things running (compilation, emails,
> batch jobs, torrents). I want Kodi to be isolated from the interference.
> Slices/scopes (are they different? Manpage descriptions of them seem to say the
> same things using slightly different words) should do the trick.

Slices are a way for hierarchially grouping services + scopes. They do
not directly contain processes, but only indirectly because services +
scopes contain them.

Services encapsulates processes systemd starts for you.

Scopes encapsulates processes you fork off yourself but want to manage
in a separate own unit. When instantiating a scope you specify a bunch
of processes which will be migrated to the new scope.

Process generally are placed in services and scopes early on when they
are forked off. Migrating already long running processes into a
different scope or service is not something one wants to do because
accounting is fucked then.

Slices are the inner nodes of the cgroup tree basically, and scopes +
services the leaves.

Please read up on this here:

https://systemd.io/CGROUP_DELEGATION

It's documented in all length...

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list