1

So I am trying to change my hard limit for file descriptors on Ubuntu18.04 laptop. I have tried everything but the changes have still not taken effect.

I need to run a go program which keeps throwing this error. too many open files

So I made some changes to my /etc/security/limits.conf file according to this blog post https://medium.com/@muhammadtriwibowo/set-permanently-ulimit-n-open-files-in-ubuntu-4d61064429a

These are the contents of limits.conf

* soft     nproc          65535    
* hard     nproc          65535   
* soft     nofile         65535   
* hard     nofile         65535
root soft     nproc          65535    
root hard     nproc          65535   
root soft     nofile         65535   
root hard     nofile         65535

And I also changed /etc/pam.d/common-session to add the line session required pam_limits.so

The I restarted my terminal and ulimit -Hn still showed 4096 but when I did sudo su and ran the same command it gave me 65535

But since I am not running my go program inside of the su session it still doesn't work out for me, I need to change my actual hard limit to a higher value for all the users not just the super user

What am I doing wrong?

Improve this question
2
  • Why sudo su? sudo is enough. sudo -s – ctrl-alt-delor Mar 24 '20 at 21:12
  • I cannot think of a reasonable scenario where a process requires 4096+ files, so I suspect it may be failing to close files when it has finished with them. I did some work on a forum post a while back where the OP wanted to split a file 55,000 ways, and managed to discover an algorithm which only required one output file at a time, and was as fast as the more obvious multi-file methods. – Paul_Pedant Mar 24 '20 at 21:17
1

You're very close.

Add the user name who needs the values. You just set limits for root, now set it for the user you need.

You can add users groups etc. From Redhat site: 

        # vi /etc/security/limits.conf
    #<domain>        <type>  <item>  <value>

    *               -       core             <value>
    *               -       data             <value>
    *               -       priority         <value>
    *               -       fsize            <value>
    *               soft    sigpending       <value> eg:57344
    *               hard    sigpending       <value> eg:57444
    *               -       memlock          <value>
    *               -       nofile           <value> eg:1024
    *               -       msgqueue         <value> eg:819200
    *               -       locks            <value>
    *               soft    core             <value>
    *               hard    nofile           <value>
    @<group>        hard    nproc            <value>
    <user>          soft    nproc            <value>
    %<group>        hard    nproc            <value>
    <user>          hard    nproc            <value>
    @<group>        -       maxlogins        <value>
    <user>          hard    cpu              <value>
    <user>          soft    cpu              <value>
    <user>          hard    locks            <value>

<domain> can be:

a user name
a group name, with @group syntax
the wildcard *, for default entry
the wildcard %, can be also used with %group syntax, for maxlogin limit

Set up the users in limits.conf, log off and back on and see if that helps. 

joe soft     nproc          65535    
joe hard     nproc          65535   
joe soft     nofile         65535   
joe hard     nofile         65535
Improve this answer
5
  • I thought the wildcard * would apply to all users except root, won't it? – sumopal Mar 25 '20 at 4:59
  • Not sure. I always assign values to specific users. I am not sure what the ramifications would be to let everyone have a high value. Also I notice the * domain is not applied to the nproc lines. Not sure it it will take * on nproc. – Mark Stewart Mar 25 '20 at 15:07
  • your solution worked thanks – sumopal Mar 25 '20 at 15:58
  • hey @MarkStewart your solution did work but the next day when I rebooted my laptop ulimit -Hn still displayed 4096, so I opened up the limits.conf file and saved it again without editing anything and then opened a new shell session and it was back to 65536, is there a way to persist this value? – sumopal Mar 26 '20 at 4:48
  • Opening and saving the limits.conf file shouldn't change anything! try rebooting again that doesn't sound logical. Is this a real user logging in or is this a service account like mysql or apache etc? limits.conf will only work for real user shell logins not service accounts. Also in systemd the sysctl settings control the ulimit for files globally. Also look to see /etc/pam.d/login has a line that says "session required pam_limits.so" – Mark Stewart Mar 26 '20 at 19:25

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.