On 2019-01-17 21:50:48 (-0500), Bill Gribble wrote:
> On 1/17/19 5:41 PM, David wrote:
> > On Thu, 17 Jan 2019 at 23:22, Bill Gribble<grib@xxxxxxxxxxxxxxx> wrote:
> > > I have opened a Debian bug report against the "libpam-modules" package
> > > (containing pam_limits.so, the module that actually reads and applies
> > > the /etc/security/limits.{conf,d} limits). We'll see what happens!
> > For the benefit of other readers, I guess that would be this one:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919528
>
> That's the one. To summarize my later findings for posterity, this isn't a
> "bug" in libpam-modules per se but a known bad-interaction between systemd
> and gnome.
>
> In short, systemd implements its own system for setting process limits on
> login, and /etc/security/limits.* are obsolete.
>
> Here's the Link I Needed To Find:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1364332
>
> The bummer is that systemd's mechanism for setting limits is less powerful
> than the limits.conf style and doesn't permit setting limits for users based
> on group membership.
>
> I still haven't nailed the workaround (the ideas in the fedora thread above
> haven't worked, but I have little understanding of how systemd manages
> processes so I'm sort of poking in the dark) but I will post a followup to
> this thread when I do so that others might benefit as well.
I think this is only a problem in the weirdly integrated gnome apps,
such as gnome-terminal, which auto-launches a
gnome-terminal-server.service (user service) via dbus, that applies
(probably only some) systemd user service configurations or whatever. In
that case you would have to overload that user service locally (e.g.
~/.config/systemd/user/gnome-terminal-server.service), adding
`LimitNOFILE=<your-nofile>` [1]. This is because the user service is
started below your <username>@user.service and not in the
<session-number>.scope of that user. Theoretically, this approach is
more flexible (as one can have many different types of services, that
have different types of limits or settings or whatever, but that's a
different topic).
I recommend using other terminal emulators, such as termite or xterm or
urxvt (as they don't depend on a systemd user service) and are started
in .scope.
However, if this *did apply* to all applications, it *would be* a PAM
configuration problem (which might be specific to GDM), that your
distribution should figure out/ would need to fix. Therefore this only
marginally has something to do with systemd. There is no "systemd black
magic" preventing the limits from being applied (contrary to what some
others seem to believe), but rather bad design choices of gnome (of the
type "one size fits all) being applied.
As a sidenote: On Arch Linux we use the package 'pambase' [1], which
takes care of the configuration of e.g. system-auth, system-services and
I believe this functions simililarly on other distros.
If you do a `grep -R "pam_limits" /etc/pam.d`, I'm sure 'pam_limits.so'
will show up in some of the configuration files.
I don't really use gdm/gnome anymore (other bloat reasons), but just
tested my window manager and also a gnome session started from gdm and I
can't reproduce your problem (limits are applied), when using another
terminal emulator than gnome-terminal.
Bests,
David
[1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties
[2] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/pambase
--
https://sleepmap.de
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
