[systemd-devel] systemd user instance and raising limits

[Jeff Solomon]

Lennart,

Your explanation sounds great but it's just not what I'm seeing.

My user at .service has "PAMName=systemd-user" in the [Service] section.

I have setup limits for the user in /etc/security/limits.d/foo.conf.

I have no other limit overrides in any other systemd file.

Whether I reboot or "systemctl restart user@<uid>" I see the same thing.
That is, the limits set through pam_limits are not respected.

I consistently see that if I login as that user, then "ulimit -a" shows the
values I expect from pam_limits while "cat /proc/<pid>/limits" for the user
instance process or its children do not.

On Mon, Nov 20, 2017 at 8:47 AM, Lennart Poettering <lennart at poettering.net>
wrote:

> On Mo, 20.11.17 08:32, Jeff Solomon (jsolomon8080 at gmail.com) wrote:
>
> > I am using lingering and I have issued "systemctl restart user@<uid>"
> and
> > then seen the instance restart with a new PID. So I think I am restarting
> > the user instance.
> >
> > When Limit* directives are applied in "user at .service" or in
> > "/etc/systemd/system/user at .service.d/whatever.conf" I see that they are
> > respected in the user instance itself and the child processes it starts.
> >
> > However, I do NOT see settings applied through pam_limits
> > (/etc/security/limits.d etc etc) respected in the user instance although
> > Mantas implied that I should. Is this expected?
>
> When systemd executes a service that has PAM enabled, it will will
> first start the PAM session, which is where pam_limits does its
> thing. It then goes on setting up the execution environment for the
> service, and if resource limits are configured for the unit, they'll
> be put into effect. This means that any settings configured in the
> unit file they take precedence over the pam_limits settings.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20171120/a5c64b61/attachment.html>