Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#923312: gnome-terminal ignores system ulimits
31 views
Skip to first unread message
Harald Dunkel
Feb 26, 2019, 2:40:03 AM2/26/19
to
Package: gnome-terminal
Version: 3.22.2-1
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
Using other terminal emulators (xterm, xfce4-terminal) there
is no such problem.
This breaks my apps. gnome-terminal and gnome-terminal-server
should resepct the ulimits initially set via pam_limits.so at
login time and inherited from the calling process.
Regards
Harri
Version: 3.22.2-1
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
Using other terminal emulators (xterm, xfce4-terminal) there
is no such problem.
This breaks my apps. gnome-terminal and gnome-terminal-server
should resepct the ulimits initially set via pam_limits.so at
login time and inherited from the calling process.
Regards
Harri
Harald Dunkel
Feb 26, 2019, 9:30:03 AM2/26/19
to
Apparently this comes up only, if dbus-user-session (1.10.26-0+deb9u1)
is involved. I did not ask for this package. After deleting it
the problem was gone.
Regards
Harri
is involved. I did not ask for this package. After deleting it
the problem was gone.
Regards
Harri
Harald Dunkel
Feb 26, 2019, 10:30:03 AM2/26/19
to
Sorry, this sounded very harsh. What I meant was:
dbus-user-session sneaked in by some package recommendation
recently, AFAICT. It should not affect a working configuration
in /etc/security/limits.d/ created back in 2016.
Regards
Harri
dbus-user-session sneaked in by some package recommendation
recently, AFAICT. It should not affect a working configuration
in /etc/security/limits.d/ created back in 2016.
Regards
Harri
Simon McVittie
Mar 11, 2019, 5:10:03 AM3/11/19
to
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
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
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.
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
Harald Dunkel
Mar 11, 2019, 6:40:03 AM3/11/19
to
Hi Simon,
On 3/11/19 10:04 AM, Simon McVittie wrote:
>
> 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.
>
ACK
>
> Do you have a line for pam_limits.so in /etc/pam.d/systemd-user?
>
Yes.
> 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.
>
No.
> 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?
>
No, I get 1024/4096 for nofiles. /etc/security/limits.d/local.conf
involved.
systemd is version 232-25+deb9u9
Regards
Harri
On 3/11/19 10:04 AM, Simon McVittie wrote:
>
> 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.
>
>
> 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?
>
says
* soft nofile 4096
* hard nofile 16584
root soft nofile 4096
root hard nofile 16584
/proc/$$/limits shows the expected limits, unless gnome-terminal is
* soft nofile 4096
* hard nofile 16584
root soft nofile 4096
root hard nofile 16584
involved.
systemd is version 232-25+deb9u9
Regards
Harri
Harald Dunkel
Aug 24, 2023, 4:30:04 AM8/24/23
to
Hi Michael,
have the system ulimits in /etc/security been deprecated in
favor of systemd service limits?
Regards
Harri
have the system ulimits in /etc/security been deprecated in
favor of systemd service limits?
Regards
Harri
Harald Dunkel
Sep 1, 2023, 5:40:04 AM9/1/23
to
This is weird, because gdm3 (the display manager required by gnome-core,
which is required by gnome-terminal) depends upon libpam-modules, and this
package owns /etc/security.
If I got this correctly, the real problem is that systemd ignores the
ulimits set via pam.
> systemd (user) services run in a separate, clean context though,
> that's why there are separate knobs for this.
Sorry to say, but it doesn't seem that clean to me.
Regards
Harri
which is required by gnome-terminal) depends upon libpam-modules, and this
package owns /etc/security.
If I got this correctly, the real problem is that systemd ignores the
ulimits set via pam.
> systemd (user) services run in a separate, clean context though,
> that's why there are separate knobs for this.
Sorry to say, but it doesn't seem that clean to me.
Regards
Harri
0 new messages