Re: How to stop child cgroup caused by PAMName=

["Windl, Ulrich" <u.windl@xxxxxx>]

Hi!

When changing distro defaults be careful not to open another can of worms, however 😉

Kind regards,
Ulrich Windl

> -----Original Message-----
> From: systemd-devel <systemd-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On
> Behalf Of Dluhosch, Michael
> Sent: Friday, February 7, 2025 10:08 AM
> To: Lennart Poettering <lennart@xxxxxxxxxxxxxx>
> Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: [EXT] Re:  How to stop child cgroup caused by
> PAMName=
> 
> Hi,
> 
> The hint with the 'KillUserProcesses' setting was exactly what I needed.
> We indeed use a distro which is setting this to 'no' and this caused all my
> issues. When I set it to yes then the "login" done by the service seems to be
> correctly cleaned up by loginctl.
> This is exactly the clean solution I was looking for.
> 
> Thanks and Kind Regards,
> Michael
> 
> 
> -----Original Message-----
> From: Lennart Poettering <lennart@xxxxxxxxxxxxxx>
> Sent: Thursday, February 6, 2025 4:01 PM
> To: Dluhosch, Michael <michael.dluhosch@xxxxxxxxxx>
> Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re:  How to stop child cgroup caused by
> PAMName=
> 
> On Do, 06.02.25 08:25, 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.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.
> 
> Well, the whole session concept is about disconnecting lifecycles of the login
> manager and the sessions they spawn a bit (i.e. that the sessions can be
> killed independently of the session manager and can be tracked separately
> from it).
> 
> > 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?
> 
> Well, a service can register as many sessions as it wants, simultaneously or
> serially, everything is allowed, hence there is no direct 1:1 connection
> between service and scope and what you are asking for is not necessarily
> available.
> 
> I guess you could theoretically bind the lifetime of your session object to the
> lifetime of the allocating service via BindsTo= but we currently have no way
> to request that in a friendly way.
> 
> That said, why is this even an issue? note that logind tracks the primary
> process of a session as its "leader" and binds the session's lifetime to that
> leader process lifetime. Except of course you are using some distro that turns
> KillUserProcesses= off, which disables this logic for compat with legacy.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 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.