Bug 1437610 - systemd does not appear to be updating LimitNPROC correctly
Summary: systemd does not appear to be updating LimitNPROC correctly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 26
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-30 16:18 UTC by Michel van der List
Modified: 2017-10-27 13:48 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-27 13:48:17 UTC
Type: Bug


Attachments (Terms of Use)

Description Michel van der List 2017-03-30 16:18:44 UTC
Description of problem:
I need to increase my process limit and can't

Version-Release number of selected component (if applicable):
systemd.x86_64 - 231-14.fc25

How reproducible:
Always

Steps to Reproduce (and steps, etc.)

I am trying to allow the process limit for my login session to be higher than
the default (near as I can tell 1024). As I understand it, this is now under
the control of systemd, but to be sure I added:
    * soft nproc 4096
    * hard nproc 4096
to /etc/security/limits.conf. I then put
    DefaultLimitNPROC=4096
in /etc/systemd/user.conf. None of this seemed to help me get the limit I wanted
witnessed by:
    $ ulimit -u
    1024

I then created /etc/systemd/system/user@.service.d/local.conf:
    $ cat /etc/systemd/system/user@.service.d/local.conf[Service]
    LimitNPROC=8192
    LimitNOFILE=16000
(the NOFILE just to make sure I could see something additional).
Again, no luck. Interestingly, if I do:
    $ systemd-cgls
    Control group /:
    -.slice
    ├─user.slice
    │ ├─user-1000.slice
    │ │ ├─session-5.scope
    ...
    │ └─user@1000.service
    │ │   ├─gnome-terminal-server.service
    │ │   │ ├─ 3400 /usr/libexec/gnome-terminal-server
    │ │   │ ├─ 3451 bash
followed by:
    systemctl show user@1000.service | egrep 'Path|NOFILE|NPROC'
    LimitNOFILE=16000
    LimitNOFILESoft=16000
    LimitNPROC=8192
    LimitNPROCSoft=8192
    FragmentPath=/usr/lib/systemd/system/user@.service
    DropInPaths=/etc/systemd/system/user@.service.d/local.conf
However, when I do
    $ cat /proc/3451/limits | grep 'proc|open'
    Max processes             1024                 1024                 processes 
    Max open files            16000                16000                files     
Which indicates to me that somehow the whole nproc limit is ignored. Note
that I can in the shell in question do:
    $ ulimit -S -n 10000
    $ ulimit -a | egrep 'proc|open'
    open files                      (-n) 10000
    max user processes              (-u) 1024
But:
    $ ulimit -S -u 2048
    bash: ulimit: max user processes: cannot modify limit: Invalid argument
    $ ulimit -a | egrep 'proc|open'
    open files                      (-n) 10000
    max user processes              (-u) 1024

Running:
    $ cat /etc/system-release
    Fedora release 25 (Twenty Five)
    $ sudo dnf list systemd
    Installed Packages
    systemd.x86_64              231-14.fc25          @updates

I have tried to apply the fix suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1341829#c36
but that did not seem to help. This seems like a bug to me, but perhaps I am missing something
elementary?

Thanks

Comment 1 Michel van der List 2017-07-24 16:24:03 UTC
Upgraded to F26. Same problem.

Comment 2 Michel van der List 2017-10-17 14:22:45 UTC
Still a problem with systemd-233-6.fc26. Tried to turn off selinux with no luck. Did a strace on systemd and it appears the NPROC value does not get propagated.

Comment 3 Owen Taylor 2017-10-25 15:58:10 UTC
Can you try a fresh Fedora system in a VM and see what you see there? on a system where I haven't modified anything, I see:

$ cat /etc/system-release
Fedora release 26 (Twenty Six)
$ ulimit -u
77888

So I'm not sure where the small limit you are seeing is coming from - perhaps there's something you have modified in the system configuration or some leftover from an upgrade.

Comment 4 Michel van der List 2017-10-25 18:17:05 UTC
Well, I started a liveCD on a different box and get:
  [liveuser@localhost-live ~]$ cat /etc/system-release
  Fedora release 26 (Twenty Six)
  [liveuser@localhost-live ~]$ ulimit -u
  63764
  [liveuser@localhost-live ~]$ 

I'm pretty sure I tried this on the box in question with a LiveCD with F25 and it had the same problem, but I'm not near that particular system, so I won't be able to boot that one with a LiveCD until tomorrow.

However, I have another F26 box sitting here with the same problem, so let me boot that one up with the LiveCD and see what it does.

For the record, both have been upgraded and doing a clean install would be painful at best, so I'd like to track down what is actually causing this.

I'll be back...

Comment 5 Michel van der List 2017-10-25 19:02:34 UTC
Booting up the system that also has the problem with a LiveCD results in:
  [liveuser@localhost-live ~]$ cat /etc/system-release
  Fedora release 26 (Twenty Six)
  [liveuser@localhost-live ~]$ ulimit -u
  30453
 [liveuser@localhost-live ~]$ 
So it would appear this is some sort of configuration of my current installation(s). I'm open to any suggestions that would help me find it.

For now I'll also remove all of the config stuff I put into the /etc/systemd directory.

Comment 6 Michel van der List 2017-10-25 19:40:51 UTC
After removing all customizations and rebooting, I'm back to square 1 (or perhaps square 1024).

Logging in with SSH results in the same, using the text console results in the same.

Turned selinux to permissive, and it result in the same.

I'm lost. If there are no suggestions I guess I'll just rebuild the system from scratch.

Comment 7 Michel van der List 2017-10-27 13:48:17 UTC
Well, re-built the system(s) keeping the user files only and the problem went away. Something must have been interfering, though I still don't know what.


Note You need to log in before you can comment on or make changes to this bug.