[systemd-devel] How to correctly use memory controls (MemoryLow) on unified hierarchy system?
systemd offers MemoryLow for an individual units. It actually sets memory.low cgroup attribute, so this is OK. The problem is according to kernel dcouemtation, memory.low is limited by value set in parent cgroup and all parent cgroups have memory.low=0: /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/gnome-shell-wayland.service/memory.low:536870912 /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/memory.low:0 /sys/fs/cgroup/user.slice/user-1001.slice/memory.low:0 /sys/fs/cgroup/user.slice/memory.low:0 which implies setting on lead cgroup has no effect. Is it necessary to explicitly set it on every ancestor? There is no clarification in systemd documentation and value is applied without any warning. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to correctly use memory controls (MemoryLow) on unified hierarchy system?
Hi, On Fri, 2021-05-21 at 15:25 +0300, Andrei Borzenkov wrote: > systemd offers MemoryLow for an individual units. It actually sets > memory.low cgroup attribute, so this is OK. The problem is according to > kernel dcouemtation, memory.low is limited by value set in parent > cgroup and all parent cgroups have memory.low=0: > > /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/gnome- > shell-wayland.service/memory.low:536870912 > /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/memory.low: > 0 > /sys/fs/cgroup/user.slice/user-1001.slice/memory.low:0 > /sys/fs/cgroup/user.slice/memory.low:0 > > which implies setting on lead cgroup has no effect. > > Is it necessary to explicitly set it on every ancestor? There is no > clarification in systemd documentation and value is applied without any > warning. Yes, you need to set it on all ancestors, and the documentation mentions this: """ For a protection to be effective, it is generally required to set a corresponding allocation on all ancestors, which is then distributed between children (with the exception of the root slice). Any MemoryMin= or MemoryLow= allocation that is not explicitly distributed to specific children is used to create a shared protection for all children. As this is a shared protection, the children will freely compete for the memory. """ Depending on the kernel versions there may be some other caveats: """ Units may have their children use a default "memory.min" or "memory.low" value by specifying DefaultMemoryMin= or DefaultMemoryLow=, which has the same semantics as MemoryMin= and MemoryLow=. This setting does not affect "memory.min" or "memory.low" in the unit itself. Using it to set a default child allocation is only useful on kernels older than 5.7, which do not support the "memory_recursiveprot" cgroup2 mount option. """ You need to configure it correctly in various locations. Personally, I would suggest taking a look at uresourced[1]. It will correctly set a configurable memory protection, enables some other cgroup features and tracks the currently active user. Fedora is shipping it by default and it appears to work well there. Benjamin [1] https://gitlab.freedesktop.org/benzea/uresourced and https://lwn.net/Articles/829567/ signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] depending on user units
On 21.05.2021 18:18, lejeczek wrote: > Hi guys. > > While surfing the web for answers I thought I would try to call on > experts - how, if possible at all, to make systemd service unit depend > on users' unit/services? > No, it is not possible. Nor is it really possible in reverse direction. systemd "imports" some specific units (devices and mounts) from system space into each user space, but that's all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to correctly use memory controls (MemoryLow) on unified hierarchy system?
On 21.05.2021 17:07, Benjamin Berg wrote: > Hi, > > On Fri, 2021-05-21 at 15:25 +0300, Andrei Borzenkov wrote: >> systemd offers MemoryLow for an individual units. It actually sets >> memory.low cgroup attribute, so this is OK. The problem is according to >> kernel dcouemtation, memory.low is limited by value set in parent >> cgroup and all parent cgroups have memory.low=0: >> >> /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/gnome- >> shell-wayland.service/memory.low:536870912 >> /sys/fs/cgroup/user.slice/user-1001.slice/user@1001.service/memory.low: >> 0 >> /sys/fs/cgroup/user.slice/user-1001.slice/memory.low:0 >> /sys/fs/cgroup/user.slice/memory.low:0 >> >> which implies setting on lead cgroup has no effect. >> >> Is it necessary to explicitly set it on every ancestor? There is no >> clarification in systemd documentation and value is applied without any >> warning. > > Yes, you need to set it on all ancestors, and the documentation > mentions this: > > """ > For a protection to be effective, it is generally required to > set a corresponding allocation on all ancestors, which is > then distributed between children (with the exception of the > root slice). Any MemoryMin= or MemoryLow= allocation that is > not explicitly distributed to specific children is used to > create a shared protection for all children. As this is a > shared protection, the children will freely compete for the > memory. > """ > OK, it is in upstream now, was not in my version and I did not pay attention to web page. Sorry. I guess I expected systemd to somehow handle it, given that it knows all the settings, knows exact hierarchy and is the sole master of cgroup tree. > Depending on the kernel versions there may be some other caveats: > > """ > Units may have their children use a default "memory.min" or > "memory.low" value by specifying DefaultMemoryMin= or > DefaultMemoryLow=, which has the same semantics as MemoryMin= > and MemoryLow=. This setting does not affect "memory.min" or > "memory.low" in the unit itself. Using it to set a default > child allocation is only useful on kernels older than 5.7, > which do not support the "memory_recursiveprot" cgroup2 mount > option. > """ > > You need to configure it correctly in various locations. Personally, I > would suggest taking a look at uresourced[1]. It will correctly set a > configurable memory protection, enables some other cgroup features and > tracks the currently active user. Fedora is shipping it by default and > it appears to work well there. > That's overkill for my purposes. This is single user system and all I am trying to do is to prevent swapping out Wayland composer to avoid waiting several minutes to unblank screen. I am fine with setting values once. Thanks for the pointers. > Benjamin > > [1] https://gitlab.freedesktop.org/benzea/uresourced and > https://lwn.net/Articles/829567/ > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] depending on user units
Hi guys. While surfing the web for answers I thought I would try to call on experts - how, if possible at all, to make systemd service unit depend on users' unit/services? many thanks, L. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-run / Failed to create bus connection: Input/output error
On 03/05/2021 16:04, Lennart Poettering wrote: On Fr, 30.04.21 14:33, lejeczek (pelj...@yahoo.co.uk) wrote: Hi guys. I'm do on my pretty vanilla, so I'd like to think, setup this: -> $ systemd-run --machine=qemu-8-c8kubernode1 /bin/cat /etc/centos-release Failed to create bus connection: Input/output error Someone would care to decipher that for me or/and shed bit more light on possible troubleshooting? which host OS, which payload OS? which host systemd, which payload systemd? is this an nspawn container? is the container fully booted up? Lennart -- Lennart Poettering, Berlin it's all CentOS Stream with systemd 239 (239-45.el8) Container(s) is libvirtd managed(started by) and yes it's fully booted up. many thanks, L. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators
On Thursday, May 20, 2021 10:53:24 AM EDT wrote: > On So, 16.05.21 19:41, nerdopolis (bluescreen_avenger at verizon.net) wrote: > > > Hi > > > > I am trying to experiment around replacing the text mode TTYs with usermode > > utilities. > > I don't follow? > I am sorry, I will try to be more clear. That first email, went through several drafts, as at first it was longer and rambly, and I didn't want to bombard the list with a giant wall of text. (I actually found my solution was to use socat since sending that last email.) I was seeking some more existing programs I could try to cobble together to come up with a solution. The main things were: 1. /bin/login needs to be run as root for it to work 2. It's ill-advised to start a graphical terminal emulator as root - I looked into the existing kmscon, but it's older, and ran as root - I tried running tmux client/server with the server as root, the client as non-root. It worked in theory, but tmux didn't seem fit to run ONLY a login prompt - I tried using systemd-run, but it had the quirks I described BUT - I found I could do the same client-server thing with socat, not tmux. tmux has a basic way to forward a PTY to a socket, and then set the permissions on it for a non-root system user, and then connect to it from a command running under a terminal emulator running as that non-root user. So my solution ended up being something like: --- vtty-backend@tty1.service(u:root) vtty-frontend@tty1.service(u:vtty) socat exec:/bin/login unix-listen:/run/socketcage (wayland) /|\ vte (terminal emulator) | socat file:`tty` unix-connect:/run/socket<-| || --- That way there I was able to solve the first issue. (and actually the second issue too, by running the backend on a fake seat-vtty seat) > > While kmscon exists, the problem with it that I see is that it runs as root. > > It's most likely so it can run /bin/login as root, and /bin/login is not > > setuid > > > > > > I found that doing something like (Can't fit the command in 80 chars, > > sorry) > > systemd-run --setenv XDG_SEAT=$XDG_SEAT --setenv XDG_VTNR=$XDG_VTNR -t > > /bin/login -p > > can work in a way to run /bin/login within a non-privleged terminal > > emulator, > > however authentication is needed to run that command. > > hmm? XDG_VTNR is for the Linux VT subsystem but though i don't > understand what you are trying to do i get the impression you don't > want to use VTs? or do you? not following... > Sorry, I got the terminology mixed up again. I am still using TTYs to run the instances of `cage`. It's the kernel mode VT emulators I am replacing with the user mode terminal emulators (running under a fullscreen Wayland compositor) > > First question: > > Is there a supported way to allow a system user account to run one command > > without a password prompt with systemd-run? Otherwise I guess I can just > > make a > > setuid binary that calls the systemd-run command... > > It's PolicyKit enabled, you can allow your user to run unpriv > commands, but it's a all-or-nothing thing. > OK, that's kind of what I thought. Thanks for confirming. (If I hadn't found the other solution, I would have just made the setuid binary for kicking off systemd-run) > > The second thing: Things like nmtui need a full logind session to be able to > > run, and do polkit actions. However on seat0, it seems you need to decide > > on a > > empty TTY to use, which while you can use TTY63, that doesn't seem to be a > > 'clean' idea. > > Can't parse this, sorry. > I am sorry I was not clear, I'll try to use nmtui as an example to describe what I am seeing. nmtui is an example of a utility that needs polkit (or root) to work. It comes with NetworkManager. Start nmtui from a normal terminal emulator, or a classic tty, and you likely will be able to edit connections with it. Now if you do systemd-run -t /bin/login -p and then login, and run nmtui, that instance will then say "not authorized" I forgot what inspired me to experiment with setting XDG_SEAT but if you systemd-run -t --setenv=XDG_SEAT=seat0 /bin/login -p and then log in, and nmtui still doesn't work. Check the journal, you will get an error "failed to create session: VT number out of range" where the VT number that gets logged is 0. I guess it fails because on seat0 VT numbers can't be 0. - one ugly hack though was setting XDG_VTNR to like 63 or something What DOES work is if you create a second seat somehow called seat-vtty then: systemd-run -t --setenv=XDG_SEAT=seat-vtty /bin/login -p and login, and THAT WORKS. because
