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

[Mantas Mikulėnas]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250206/ce59bb53/attachment.htm>