19 Jan
2019
19 Jan
'19
12:50 a.m.
On 2019-01-17 21:50:48 (-0500), Bill Gribble wrote:
On 1/17/19 5:41 PM, David wrote:
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>(a)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%…
[2] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/pamba…
--
https://sleepmap.de
On Thu, 17 Jan 2019 at 23:22, Bill
Gribble<grib(a)billgribble.com> wrote:
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 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