Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
On Tue, May 10, 2022 at 8:48 AM Lennart Poettering
wrote:
> But how would it even work? if you say "everything in foo.slice should
> now be in bar.slice". but once you say it, these units would be in
> bar.slice so the rule doesn't apply anymore... it's messy to use a
> property as matching parameter that is also the parameter you want to
> change, because then things cannot possibly be declarative/idempotent
> anymore...
I see. I had a feeling this would be impractical anyways, but I wanted
to know if it was possible. Thank you for the feedback.
On Tue, May 10, 2022 at 7:47 AM Michal Koutný wrote:
> I'm wondering is the certain slice or its parent any of the systemd
> implicit slices ({user,user-,system,machine}.slice,...)?
>
> Or you just want to override a hierarchy defined by some 3rd party
> units (perhaps with a purpose)?
I was trying to override the cgroup hierarchy for the units made by
the KDE plasma desktop environment to better implement resource
control of the desktop environment and applications. The units were
the system unit session-*.scope (located directly under user-*.slice)
and the user units background.slice and session.slice (under
user@*.service). I thought that by having all of these units under one
slice that was reserved for the desktop environment, it would be
easier to add resource protections (memory, cpu, etc.) to the desktop
environment as a whole. But considering how complicated it is to
override the hierarchy, I settled on a solution that does not require
reorganizing the cgroup hierarchy.
Yeongjin Kwon
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
On Do, 05.05.22 19:12, Yeongjin Kwon (yeongjink...@gmail.com) wrote: > On Thu, May 5, 2022 at 11:17 AM Lennart Poettering > wrote: > > > > On Do, 05.05.22 10:44, Yeongjin Kwon (yeongjink...@gmail.com) wrote: > > > > > On Wed, May 4, 2022 at 4:03 AM Lennart Poettering > > > wrote: > > > > > > > > The slice names match 1:1 to the position in the cgroup tree, that's > > > > where they were designed. > > > > > > > > Basically our rule is: if the object unit types encapsulates > > > > already have a file system path as name then we don't allow you to > > > > make up a new name, but insist that the unit name is derived from that > > > > pre-existing file system path. > > > > > > I see, thank you for responding. > > > > > > Then would it be possible to somehow override the "Slice" property for > > > all units underneath the slice so that it points to another, custom > > > created slice? Maybe using some conditional overriding mechanism? > > > > You can override the slice for any non-slice unit that is backed by a > > cgroup via a dropin that overrides Slice=. > > > > But maybe I don#t grok your question. > > Sorry if I was being unclear. > > I want to relocate all non-slice units that are in a slice to a > different slice. I know I can do this by overriding Slice= > individually for each unit with a dropin, but that would be tedious > and prone to flaws. For example, if a package put a unit under the > slice that I wanted to move all units from, then I would have to > override that new unit as well, which I might forget to do. I could > use a post-install script, but that may not be the best solution > either. And so I was wondering if there was a way to automatically > override all units that are under the slice, without having to > override Slice= for each of them individually. Since I haven't seen > anything like this so far, I guess this is also a sort of feature > request. There's no such feature. But how would it even work? if you say "everything in foo.slice should now be in bar.slice". but once you say it, these units would be in bar.slice so the rule doesn't apply anymore... it's messy to use a property as matching parameter that is also the parameter you want to change, because then things cannot possibly be declarative/idempotent anymore... Note that systemd units allow hierarchal drop-ins. i.e. the drop-in directory "foo-.service.d/" is read for all units matching the glob pattern "foo-*.service". Thus, if you want to migrate a bunch of units at once, you could do so — as long as you enforce a naming scheme that makes all units that "belong together" use the same name prefix. In the past we had some discussion to have a global setting DefaultSlice=, which would allow changing which slice to default to for units that don't specify it. (i.e instead of system.slice). But I am not convinced this really makes too much sense... Anyway, I don't really grok the usecase... Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
Hello.
On Tue, May 03, 2022 at 08:16:48PM -0400, Yeongjin Kwon
wrote:
> I'm trying to override the parent slice of a certain slice unit so I can
> reorganize the cgroup hierarchy.
I'm wondering is the certain slice or its parent any of the systemd
implicit slices ({user,user-,system,machine}.slice,...)?
Or you just want to override a hierarchy defined by some 3rd party
units (perhaps with a purpose)?
Thanks,
Michal
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
On Thu, May 5, 2022 at 11:17 AM Lennart Poettering wrote: > > On Do, 05.05.22 10:44, Yeongjin Kwon (yeongjink...@gmail.com) wrote: > > > On Wed, May 4, 2022 at 4:03 AM Lennart Poettering > > wrote: > > > > > > The slice names match 1:1 to the position in the cgroup tree, that's > > > where they were designed. > > > > > > Basically our rule is: if the object unit types encapsulates > > > already have a file system path as name then we don't allow you to > > > make up a new name, but insist that the unit name is derived from that > > > pre-existing file system path. > > > > I see, thank you for responding. > > > > Then would it be possible to somehow override the "Slice" property for > > all units underneath the slice so that it points to another, custom > > created slice? Maybe using some conditional overriding mechanism? > > You can override the slice for any non-slice unit that is backed by a > cgroup via a dropin that overrides Slice=. > > But maybe I don#t grok your question. Sorry if I was being unclear. I want to relocate all non-slice units that are in a slice to a different slice. I know I can do this by overriding Slice= individually for each unit with a dropin, but that would be tedious and prone to flaws. For example, if a package put a unit under the slice that I wanted to move all units from, then I would have to override that new unit as well, which I might forget to do. I could use a post-install script, but that may not be the best solution either. And so I was wondering if there was a way to automatically override all units that are under the slice, without having to override Slice= for each of them individually. Since I haven't seen anything like this so far, I guess this is also a sort of feature request. A possible way to accomplish the above may be to add a conditional overriding mechanism to systemd. A conditional override would be an entity that overrides the properties of any unit if the unit matches the conditions in the override, similarly to a dropin. So I would be able to override all units that have the Slice property set to the slice I want to move units from and change it to the slice I want to move units into. A possible implementation: Each conditional override would contain a conditions file and an overrides file, both under a common directory that represents the conditional override as a whole. The conditions file would contain a set of conditions, each being a string with a property set to a value that can be a pattern/regular expression, like "Slice=slice-name*.slice". The overrides file would contain a set of overrides, each being similar to conditions except the value has to be a concrete string instead of a pattern. A unit would match the conditions if it matches all or one of the conditions, depending on how the conditional override is configured. The unit would match a condition if the value of the unit's property that corresponds with the property of the condition matches the pattern in the condition. If a unit matches the conditions, then all the values of the overrides would replace the existing values of the corresponding properties on the unit. For example, if there was a unit that contained: [Unit] Description=hello world [Service] Slice=user-1000.slice And there was a conditional override that had: Conditions file: [Service] Slice=user-*.slice Overrides file: [Service] Slice=some-other-slice.slice Then the unit would be overridden to become: [Unit] Description=hello world [Service] Slice=some-other-slice.slice I could also post this on the systemd github as a feature request. Yeongjin Kwon
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
On Do, 05.05.22 10:44, Yeongjin Kwon (yeongjink...@gmail.com) wrote: > On Wed, May 4, 2022 at 4:03 AM Lennart Poettering > wrote: > > > > The slice names match 1:1 to the position in the cgroup tree, that's > > where they were designed. > > > > Basically our rule is: if the object unit types encapsulates > > already have a file system path as name then we don't allow you to > > make up a new name, but insist that the unit name is derived from that > > pre-existing file system path. > > I see, thank you for responding. > > Then would it be possible to somehow override the "Slice" property for > all units underneath the slice so that it points to another, custom > created slice? Maybe using some conditional overriding mechanism? You can override the slice for any non-slice unit that is backed by a cgroup via a dropin that overrides Slice=. But maybe I don#t grok your question. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
On Wed, May 4, 2022 at 4:03 AM Lennart Poettering wrote: > > The slice names match 1:1 to the position in the cgroup tree, that's > where they were designed. > > Basically our rule is: if the object unit types encapsulates > already have a file system path as name then we don't allow you to > make up a new name, but insist that the unit name is derived from that > pre-existing file system path. I see, thank you for responding. Then would it be possible to somehow override the "Slice" property for all units underneath the slice so that it points to another, custom created slice? Maybe using some conditional overriding mechanism? Yeongjin Kwon
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
On Di, 03.05.22 20:16, Yeongjin Kwon (yeongjink...@gmail.com) wrote: > Hi, > > I'm trying to override the parent slice of a certain slice unit so I can > reorganize the cgroup hierarchy. I looked into overriding the "Slice" > property to set the containing slice of the unit, but it seems that > property does not do anything for slices because the location in the cgroup > hierarchy and parent are already set by the unit name. The documentation > says the unit name is composed of a series of words separated by dashes, > where each word represents a directory in the cgroup hierarchy. If the unit > name was independent from the location of the slice in the cgroup > hierarchy, then I would imagine that would make overriding the parent slice > possible. I tried to find the reason why the slice unit name must strictly > match the cgroup hierarchy, but I could not come up with an answer after > searching online and thinking about it myself. > One possibility for why the slice name must match the hierarchy could be > naming conflicts. If there are two slices with the same name but in > different cgroups, they could conflict with each other. But I decided this > could not be the case, since developers could just avoid the conflicts by > using the slice naming convention as a convention instead of following it > as a hard rule. Furthermore, there are several unit types like scopes and > services which can be organized in the cgroup hierarchy like slices, but > don't follow the same naming rule. If it was decided that naming conflicts > in relation to the cgroup hierarchy would not pose a problem for these > other units, then why was it decided for slices? Slices are the categorization, and the other unit types are what you put inside these categories. If we'd allow putting slices into random other slides without this being reflected in the name, then first of all you could create loops. (i.e. put foo.slice inside bar.slice and that back into foo.slice), and it would pretty much defeat the point of the logic, as they would suddenly not be purely categories anymore but stuff that can be put in categories. > Is there another way to override the location of a slice in the cgroup > hierarchy? And what is the reason why slice names have to correspond with > their location in the cgroup hierarchy? The slice names match 1:1 to the position in the cgroup tree, that's where they were designed. We enforce similar rules on naming things btw for .mount, .automount .swap and .device units: the are also named after paths in the file system. Basically our rule is: if the object unit types encapsulates already have a file system path as name then we don't allow you to make up a new name, but insist that the unit name is derived from that pre-existing file system path. Lennart -- Lennart Poettering, Berlin
