You are not logged in.
When I run `ulimit -Hn` in xterm, I get 65536, which is exactly what I've configured in /etc/security/limits.conf. But when I run the same command in gnome-terminal, I get 4096. I see this difference even though xterm is running inside of Gnome too -- only gnome-terminal is affected. Does anyone know how gnome-terminal ends up with the low ulimit, and how I can get it to stop doing that?
Last edited by oconnor663 (2016-02-08 21:13:58)
Offline
Ah! Additional info:
If I open an xterm (which has the high ulimit that I want), and in there run `/usr/lib/gnome-terminal/gnome-terminal-server`, and *then* start a gnome-terminal, I see the high limits. So the problem must have something to do with the way gnome-terminal-server is normally started? (By dbus?)
Offline
Figured it out! It looks like (some part of?) systemd doesn't read /etc/security/limits.conf. Instead, I created the directory /etc/systemd/system.conf.d/ and added the file /etc/systemd/system.conf.d/nofile.conf (you can call it whatever) with the contents
[Manager]
DefaultLimitNOFILE=65536
After writing that file and rebooting, gnome-terminal finally shows the right ulimits, and my other terminals including console mode look good too. The configs in /etc/security/limits.conf aren't needed anymore.
Offline
According to systemd-system.conf(5) settings such as DefaultLimitNOFILE "control various default resource limits for units" (emphasis mine).
So I would guess you were on the right track with the issue having to do with the fact that g-t-s is normally started by dbus.
Also, if you want to stick with this solution, I think you should uncomment and set the value in /etc/systemd/system.conf rather than create a file in /etc/systemd/system.conf.d/ .
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
@alphaniner could you talk a little about the tradeoffs between editing system.conf and adding a custom file in system.conf.d? The latter seemed simpler, in case I ever end up with multiple scripts trying to configure these settings, and also to avoid pacnew files.
Offline
Looking at systemd-system.conf(5) again, it seems you're right that there's no reason to choose modification of system.conf over files in system.conf.d/ . I originally misunderstood that it was intended for unit-specific modifications. Still, the .d framework seems excessive for a single machine, but maybe that's just me. I have no idea what's considered best practice.
But for your situation in particular, the more I think about it the more it seems like using a sledgehammer to drive a nail. There's got to be a better way to deal with one misbehaving application than modifying a global setting.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
> There's got to be a better way to deal with one misbehaving application than modifying a global setting.
Yes that was my feeling too
The core of the problem seems to be that the `/usr/lib/systemd/systemd --user` process running for my user defaulted to a low open files limit. My dbus process inherits from that, and my gnome-terminal-server process inherits from dbus. So the issue with gnome-terminal is just a symptom of this problem. The only way I found to raise the limit for `systemd --user` was system.conf. Even /etc/systemd/user.conf, which you'd think would be exactly suited for this, didn't work. (It could lower the ulimit, but it couldn't raise it.)
Offline
Followup: Even with this ulimit fixed, I kept hitting "fork failed" errors. I ended up setting `DefaultTasksMax` as well to fix that problem. More details here: https://bbs.archlinux.org/viewtopic.php … 7#p1604737
Offline
(Hopefully) Final followup: As kaouete mentioned in the thread linked above, today's release of systemd 229 seems to have fixed these issues. I've gotten rid of my DefaultLimitNOFILE and DefaultTasksMax configs, but the "fork failed" problem hasn't come back.
Offline