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 files 1024 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