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.
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?
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.
Kind Regards
Michael
From: Mantas Mikulėnas <grawity@xxxxxxxxx>
Sent: Thursday, February 6, 2025 11:41 AM
To: Dluhosch, Michael <michael.dluhosch@xxxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: How to stop child cgroup caused by PAMName=
On Thu, Feb 6, 2025 at 10:29 AM Dluhosch, Michael <michael.dluhosch@xxxxxxxxxx> 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.shUser=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
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.
--
