0

I have this in my /etc/security/limits.conf:

#<domain>   <type>  <item>         <value>
root        -       memlock     65536
root        -       stack       524288
root        -       nice        -20
root        -       nofile      16384

yet, the process /usr/lib/xorg/Xorg, which does run as root still has only 1024 for RLIMIT_NOFILE:

cat /proc/$(pgrep Xorg)/limits | grep 'open file'
Max open files            1024                 4096                 files   

Why are my settings in /etc/security/limits.conf not reflected in Xorg ? Where can I increase limits for /usr/lib/xorg/Xorg ?

My system is Debian Buster without systemd (I am using sysvinit). And I am using slim as login manager. So I guess it is slim, that launches Xserver. Below is the pam module used by slim:

cat /etc/pam.d/slim
auth    requisite       pam_nologin.so
auth    required        pam_env.so readenv=1
auth    required        pam_env.so readenv=1 envfile=/etc/default/locale

@include common-auth
@include common-account

session required        pam_limits.so
session required        pam_loginuid.so

@include common-session
@include common-password

UPDATE

Inspired by suggestion from @ajgringo619, I have added ulimit -n 16384 to /etc/init/slim.conf, the configuration script used by slim, since it is slim that actually starts xserver:

At first, it looked as if that solved the problem, after adding ulimit -n 16384 and restarting slim, the new ulimit takes effect. But the problem is, after restart, it does not. I mean, I have to manually restart slim for the new ulimits to take effects. if slim starts as a niormal init script, it still has the old ulimit value 1024.

  • What happens if you login as root and run a process? Are the limits applied then? – ajgringo619 Dec 23 '19 at 4:50
  • 1
    How is Xorg started on your system (via xdm, gdm3, startx, etc)? What kind of system is it (Linux with/out systemd, etc)? – mosvy Dec 23 '19 at 6:05
  • @ajgringo619 - when I log in as root (from the console), the limits are applied. – 400 the Cat Dec 23 '19 at 6:14
  • @mosvy - I am using Debian Buster without systemd, and slim as login manager. – 400 the Cat Dec 23 '19 at 6:15
  • Are limits applied to processes started from Xorg (eg a terminal window)? If so, please could you help us understand why you need Xorg itself to have the limits changed (raised) – roaima Dec 23 '19 at 8:44
1
+500

(Updated to reflect your test)

Since the user that's running the Xorg process is not actually logging in, your settings in /etc/security/limits.conf are being ignored. With sysvinit, you need to add ulimit -n 16384 to the beginning of /etc/init.d/slim (tested on antiX 19), not in slim.conf.

The systemd version of this fix also works; tested on my Debian 10 VM (adding a configuration setting that mimicked the aforementioned ulimit command).

| improve this answer | |
  • please see my update. – 400 the Cat Dec 24 '19 at 12:29
  • See my updated answer. – ajgringo619 Dec 24 '19 at 16:21
  • that fixed the problem. Thank you – 400 the Cat Dec 25 '19 at 18:23
-1

can't comment now, so Answer as a suggestion here.

you can try:

root        soft       nofile      16333
root        hard       nofile      16888

make sure to relogin or restart Xorg, then check:

cat /proc/$(pgrep Xorg)/limits | grep 'open file'
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.