On Thu, Feb 6, 2025 at 1:55 PM Dluhosch, Michael < michael.dluho...@airbus.com> wrote:
> We use this service to control various sub-processes on a shared computer > and in the past without the PAMName we noticed that the processes behaved > differently than on our own computers where we are logged in with our > users. For example it was not aware of the settings in > /etc/security/limits.d/ we solved this by duplicating the settings inside > the systemd service file via > > LimitRTPRIO=… > > LimitMEMLOCK=… > > > > Now we had the issue that processes who want to play audio behave > differently because the XDG_RUNTIME_DIR was not set. I am quite sure that > also for this there is some kind of specific solution to fix the audio > issue but I wanted to try the “log in” approach as a more future proof > solution. > Both would be inherited by user services, as the entire user-service manager already runs within a PAM session (and is what creates XDG_RUNTIME_DIR anyway). If there's always just a single shared account logged in, `systemctl --user [-M "foouser@"] start foo.service` could be used to control the processes. If there are different individual accounts, then...I'm not sure how audio currently works for you, given that XDG_RUNTIME_DIR is separate for each user? > > > Thanks for the potential improvements to the stop script if I continue > with this approach I will definitely adopt it. > > > > I already feared that there is no clean solution for this. Can I maybe > (ab)use some systemd logout features? If I log out my user from my Linux PC > then all the processes I had running are killed. Maybe I can trigger such a > logout for the ‘Foo’ user on a service stop as well? > You could, but that is effectively the same as stopping the "user-xxx.slice" similar to what you're doing now. (loginctl has "terminate-user" and "terminate-session" subcommands which do the same.) > > > Kind Regards > > Michael > > > > > > *From:* Mantas Mikulėnas <graw...@gmail.com> > *Sent:* Thursday, February 6, 2025 11:41 AM > *To:* Dluhosch, Michael <michael.dluho...@airbus.com> > *Cc:* systemd-devel@lists.freedesktop.org > *Subject:* Re: [systemd-devel] How to stop child cgroup caused by PAMName= > > > > On Thu, Feb 6, 2025 at 10:29 AM Dluhosch, Michael < > michael.dluho...@airbus.com> wrote: > > Hello, > > > > I want a service which executes 'startFoo.sh' exactly like a user 'Foo' > would experience it. This is my current approach: > > [Service] > ExecStart=/usr/bin/startFoo.sh > > User=Foo > > PAMName=login > > > > And it seems to work just fine. But I can't figure out how to stop this > service and all of its childs in a clean way. According to the systemd.exec > documentation this service will start a 'session scope' CGroup but it does > not mention how to stop this when the service stops. So far I found this > workaround: > > I add a > > ExecStop=/usr/bin/stopFoo.sh > > to the main service which does that: > > #!/bin/bash > systemctl stop $(systemctl status $(pidof > <anyProcessNameInsideTheChildCGroup>) | grep user.*slice | grep -o > session.*scope) > > > > Is there a clean solution to accomplish something like this? > > > > No; part of "exactly like a user" literally means that it gets moved by > PAM outside of the regular service tracking, so it will be ugly no matter > what. > > > > But reading from /proc/$PID/cgroup is a much more script-friendly method > than "systemctl status", even if it doesn't directly give you a unit > name... but currently you're grepping the cgroup path anyway, so you could > do $(basename "$(</proc/self/cgroup)") to get the needed result. > > > > So If you really have to make it run that way, then have the startFoo.sh > script record its own cgroup (from /proc/self/cgroup) in a file – much like > you'd use a pidfile – and then have stopFoo.sh stop the corresponding unit. > > > > But more generally, I'd really prefer narrowing down that "exactly like a > user". Where does that requirement come from? Does the app need to pop up > on the user's desktop, or something like that? (Is it a standard desktop or > some kind of embedded system with autologon-to-GUI?) In many cases, running > it as a *user* service (systemctl --user start...) would be a better > approach since it lets the contents of the service stay within their > original "service" cgroup and be tracked accordingly. > > > > -- > > Mantas Mikulėnas > The information in this e-mail is confidential. The contents may not be > disclosed or used by anyone other than the addressee. Access to this e-mail > by anyone else is unauthorised. > If you are not the intended recipient, please notify Airbus immediately > and delete this e-mail. > Airbus cannot accept any responsibility for the accuracy or completeness > of this e-mail as it has been sent over public networks. If you have any > concerns over the content of this message or its Accuracy or Integrity, > please contact Airbus immediately. > All outgoing e-mails from Airbus are checked using regularly updated virus > scanning software but you should take whatever measures you deem to be > appropriate to ensure that this message and any attachments are virus free. > -- Mantas Mikulėnas
