[systemd-devel] How to stop child cgroup caused by PAMName=

[Mantas Mikulėnas]

On Thu, Feb 6, 2025 at 1:55 PM Dluhosch, Michael <
michael.dluhosch at 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 <grawity at gmail.com>
> *Sent:* Thursday, February 6, 2025 11:41 AM
> *To:* Dluhosch, Michael <michael.dluhosch at airbus.com>
> *Cc:* systemd-devel at 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.dluhosch at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250206/fc294417/attachment.htm>