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
