17

I have long running process at Debian. At some point in throw an error:

Too many open files.

Running:

ulimit -a

shows:

open files (-n) 1024

I wish to increase number of open files in 2 times. After execution

ulimit -n 2048

the limit is active until end of my session, which is not applicable for the task.

How can I permanently increase number of open files?

kenorb
  • 5,943
  • 1
  • 44
  • 53
FoxyBOA
  • 417
  • 1
  • 6
  • 12

7 Answers7

14

There is also a "total max" of open files set in the kernel, you can check the current setting with:

cat /proc/sys/fs/file-max 

And set a new value with:

echo "104854" > /proc/sys/fs/file-max

If you want to keep the config between reboots add

sys.fs.file-max=104854

to

/etc/sysctl.conf

To check current max file usage:

[root@srv-4 proc]# cat /proc/sys/fs/file-nr
3391    969     52427
|        |       |
|        |       |
|        |       maximum open file descriptors
|        total free allocated file descriptors
total allocated file descriptors
(the number of file descriptors allocated since boot)
rkthkr
  • 8,503
  • 26
  • 38
  • 1
    Note that if free allocated file descriptors shows `0`, [it just means that the number of allocated file handles exactly matches the number of used file handles.](http://www.linuxinsight.com/proc_sys_fs_file_nr.html) – tacotuesday Aug 29 '12 at 17:34
  • Mine shows some obscene numbers in here: `49152 0 18446744073709551615 `. I don't understand why the first two columns don't add up to the third. And if I have 1.8 trillion trillion that are available, I don't see how I used them all. – mlissner Oct 20 '19 at 16:07
13

If your process is started via a script, you can place the call to ulimit in the script just prior to executing the daemon.

If you wish to increase the ulimit for your user, or for all users, you can set limits that are applied via pam_limits on login. These are set in /etc/security/limits.conf. In your case, you could do something like:

*               hard    nofile             2048

Note that "hard" denotes a hard limit - one that cannot be exceeded, and cannot be altered. A soft limit can be altered by a user (e.g. someone without root capabilities), but not beyond the hard limit.

Read the limits.conf for more information on using pam_limits.

kenorb
  • 5,943
  • 1
  • 44
  • 53
Daniel Lawson
  • 5,426
  • 21
  • 27
  • At limits conf I have 2 lines: * soft nofile 4096 * hard nofile 8192 Which have no effect. – FoxyBOA Jun 05 '09 at 10:15
  • And you've logged out and in again since testing these? This will mean logging right out of X / GNOME/ KDE etc, if you're trying this on a local machine – Daniel Lawson Jun 05 '09 at 10:36
  • Yes. /etc/security/limits.conf doesn't work for me. I'll try second approach. – FoxyBOA Jun 05 '09 at 10:53
  • 3
    /etc/security/limits.conf works only for services that use pam and the pam module pam_limits (see /etc/pam.d/ for the PAM config of each service and /etc/pam.d/common-* in particular). It thus concerns all user-sessions created by sshd, gdm, login, etc. It doesn't concern all programs started at boot-time... – Raphaël Hertzog Jun 06 '09 at 12:08
  • I did say something to that effect, but thanks for clarifying it. The OP hasn't clarified if it's a service or a process his user is running. – Daniel Lawson Jun 07 '09 at 04:02
  • What is the max number we can add for nofile. I know it's depend on physical RAM but what is the math? – KKE Nov 18 '20 at 18:31
5

Be aware that if you run your process by start-stop-daemon setting ulimits in /etc/security/limits.conf doesn't work. If you for example want to raise open file limit for tomcat to 20000 you need to add these to lines to /etc/default/tomcat:

ulimit -Hn 32768
ulimit -Sn 32768

I encountered this problem on debian 6.0.4 For other process the answers given should help.

Janning
  • 1,191
  • 1
  • 19
  • 35
4

As others have said you can apply specific limits per user or group in /etc/security/limits.conf.

Note: ulimit -n shows the soft limit.

ulimit -H -n 

will show you the hard limit.

This makes ulimit -a and ulimit -n output quite confusing if for example, you were raising the number of files from 1024 to 4096, as you would expect to see the hard limit output, but you're still seeing 1024 which is the soft limit.

Also, remember that these limits are enforced per login, so re-login in a new shell and check your changes , don't expect them to be propagated to existing logins.

Tom Feiner
  • 16,758
  • 8
  • 29
  • 24
1

It depends on how you start your long-running process. If it's started at boot time (via /etc/rcX.d/* scripts) then you must put a ulimit call in your startup script as the default limit is set by the kernel and it's not tunable without recompiling it.

Using /etc/security/limits.conf could work if you use cron to start it for example with a entry like this:

@reboot $HOME/bin/my-program

That should work because /etc/pam.d/cron enables pam_limits.so.

Raphaël Hertzog
  • 706
  • 1
  • 5
  • 11
-1

You can add this in /etc/security/limits.conf

root soft nofile 100000
root hard nofile 100000

save then reboot.

kxmp
  • 101
-2

A very nice command is ulimit -n but there is a problem with too many connection and too many open files:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 519357
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
Jacob
  • 9,114
  • 4
  • 44
  • 56
chat
  • 1
  • I tried to clean up your answer but I'm still unclear what you're trying to say to the original posters question. Can you try and clean this up further? – slm Mar 17 '13 at 01:33
  • Also this is the output of `ulimit -a`, not `ulimit -n`. – Yvan Mar 08 '18 at 07:49