Control: reassign -1 systemd
Control: affects -1 + dbus-user-session
On Tue, 26 Feb 2019 at 08:24:07 +0100, Harald Dunkel wrote:
> Package: gnome-terminal
> Version: 3.22.2-1
I assume from the version that you're using stretch? Please report
bugs with reportbug whenever possible, that way I'd already have this
information.
> My /etc/security/limits.d/local.conf says
>
> * soft nofile 4096
> * hard nofile 16584
> root soft nofile 4096
> root hard nofile 16584
>
> But within gnome-terminal I just get
>
> % egrep ^Limit\|open /proc/$$/limits
> Limit Soft Limit Hard Limit
> Units
> Max open files1024 4096
> files
This seems a lot like #838191 "systemd user units do not honor resource
limits set in /etc/security/limits.conf" in systemd; but that bug was
fixed in 231-8, so it should already be fixed in stretch.
Do you have a line for pam_limits.so in /etc/pam.d/systemd-user?
Do you have unmerged local changes for /etc/pam.d/systemd-user,
with a version containing "session required pam_limits.so" in
/etc/pam.d/systemd-user.dpkg-dist? If you do, please merge the changes
in the distributed version into your local version.
After making sure you have "session required pam_limits.so" in
/etc/pam.d/systemd-user, do these commands, run from an ordinary
non-root login session:
prlimit -p $(pgrep -u $(id -u) -f "systemd --user")
prlimit -p $(pgrep -u $(id -u) -f "dbus-daemon --session")
report the limits you would expect?
(The good news is that you won't need most of this configuration in
buster, because buster's systemd sets fs.nr_open, fs.file-max and the
hard limit for RLIMIT_NOFILE to be very large by default. See systemd's
NEWS file for more information about this: in particular, they recommend
leaving the soft limit set to 1024 for compatibility with select(),
with individual programs that need lots of fds and are known not to use
select() raising their fd limit as needed.)
On Tue, 26 Feb 2019 at 15:22:47 +0100, Harald Dunkel wrote:
> Apparently this comes up only, if dbus-user-session (1.10.26-0+deb9u1)
> is involved.
That's because if you have dbus-user-session, `dbus-daemon --session`
becomes a systemd user service that is outside the scope of any of your
login sessions (and so do all the activatable services that it starts,
like gnome-terminal-server), so they inherit their rlimits from the
rlimit of `systemd --user`, not from the rlimit of whatever service
processed your login (typically xdm/gdm/etc., sshd or login). In PAM
terms, that's /etc/pam.d/systemd-user.
Regards,
smcv
