[systemd-devel] Cannot set PATH environment variable from environment.d
Hi, I've been trying to set the PATH environment variable in systemd user daemon with environment.d but it's not working. I'm using Arch Linux, and my systemd version is below: > systemd 252 (252.2-2-arch) > +PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL > +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP > +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB > +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified I created a file at the path ~/.config/environment.d/50-my-vars.conf with the following content: > PATH=custom_path > ANOTHER_VAR=foo and then ran `systemctl --user daemon-reload` and then `systemctl --user show-environment`. The latter command showed that ANOTHER_VAR had been set to foo, but PATH had not changed. I replaced the content of the file with: > PATH=bar > ANOTHER_VAR=baz and daemon-reloaded again, but only ANOTHER_VAR had changed to baz and PATH remained the same again. To see if the issue was with my environment.d config, I ran `/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator`. It showed the same output as my environment.d config. I also made a script with the following content: > #!/bin/bash > > echo "$PATH" > /tmp/log.txt and placed it at /run/systemd/user-environment-generators/99_test_generator. When I daemon reloaded and checked the value of /tmp/log.txt, it showed the value of PATH that I set in my environment.d config. I then moved the script to /run/systemd/user-generators/99_test_generator and daemon reloaded again, and it also showed the same value. What I gathered from this is that the problem is not with the generators. The environment.d generator is working and it's setting PATH to what I expect, but this change is either undone by something else later in the daemon reload, or is not being propagated to the actual systemd environment. After that, I checked if I could adjust the PATH myself manually. I ran `systemctl --user set-environment PATH=my_path_value`, and checked the systemd environment. It showed that PATH had been updated to my_path_value. This new value of PATH persisted after I daemon reloaded multiple times. And so I honestly can't figure out what is going on at this point. I'm guessing something is preventing a change to PATH from environment generators from propagating to systemd's actual environment, but I have no clues as to what that may be. Could someone help me understand why my environment.d configuration is not setting PATH to what I want? Thank you.
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 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 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
[systemd-devel] Relationship between cgroup hierarchy and slice names
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? Another possibility that comes to mind is that naming slices this way makes using them easier, since developers would not have to put an extra Slice property on the unit. It would also be possible to tell the location of a slice in the cgroup hierarchy just by looking at the name. But would people sacrifice the capability for users to reorganize and override the cgroup hierarchy, for some convenience? Another possibility is aesthetic reasons, but then again that would be enforcing a personal decision on a community, which I don't think would happen. 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?
