62

I was using ubuntu 12.04 ,on which I run ulimit -n ,it is showing 1024, I want to increase my open file limit from 1024 to 65535,so I tried the following command:

sudo ulimit -n 65535

but i get the following error:

sudo: ulimit: command not found

How to increase the file limit from 1024 to 65535? Any help will be appreciated.

Mahmoud Al-Qudsi
  • 28,357
  • 12
  • 85
  • 125
sunpy
  • 739
  • 1
  • 5
  • 9

2 Answers2

123

ulimit is a shell builtin like cd, not a separate program. sudo looks for a binary to run, but there is no ulimit binary, which is why you get the error message.

You have a few options:

  1. On newer linux versions, there is usually a prlimit command which is a binary, meaning you can sudo it if needed.

    Run

    prlimit --pid=$$ --nofile=65000:

    to increase the soft limit for the current shell. $$ is magic that gets interpreted as, “the process id of the current shell.”

    If that command complains about “Operation not permitted,” sudo prlimit will work in most cases.

    sudo prlimit --pid=$$ --nofile=65000

    If you still get “Operation not permitted” with sudo, you might be running into some other kernel limit, like exceeding the max allowable limit.

  2. You used to be able to rely on running

    sudo sh -c "ulimit -n 65535 && exec su $LOGNAME"

    and that may still work on older linux installs. It will give you a new shell, without root privileges, but with the raised limit. The exec causes the new shell to replace the process with sudo privileges, so after you exit that shell, you won’t accidentally end up as root again.

    However this doesn’t seem to work reliably on newer (2022+?) distros, where su re-applies the default limits.

    The prlimit approach is much better though as you don’t have the security concern of running a root shell, or a process that was forked from a root shell. If you are desperate a risky variant that seems to work on newer distros is the monstrosity sudo -E sh -c "ulimit -n 65000 && exec setpriv --reuid=$(id -u) --regid=$(id -g) --inh-caps=-all --groups=$(groups|tr ' ' ,) -- env USER=\"$USER\" LOGNAME=\"$LOGNAME\" \"$SHELL\" --login".

    However option #1 is far simpler, much less risky from a security perspective, and you should definitely use it if available.

andrewdotn
  • 32,721
  • 10
  • 101
  • 130
  • Slight tweak worked perfect for me: sudo sh -c "ulimit -u 1000000 && ulimit -n 100000 && exec su $LOGNAME" – Dasmowenator Mar 18 '14 at 18:38
  • Note that this makes one loose env for user. – user367890 Jan 20 '15 at 12:45
  • Thanks. Related https://unix.stackexchange.com/questions/446539/how-can-i-change-my-command-to-run-without-superuser-privilleges-but-with-the-ch?noredirect=1&lq=1 – Tim May 28 '18 at 20:14
  • 1
    Actually I don't understand yet how `sudo sh -c "ulimit -c 1024 && exec su $LOGNAME"` can solve any problem. – Tim May 29 '18 at 17:57
  • Thanks. Another explanation https://gist.github.com/ntamvl/017ce61db2d3c6b9c595f2fac8eeac3c – Isuru Hemantha Apr 06 '21 at 05:00
0

I've had to deal with issues like this in the past. Since there is no setuid mechanism for shell scripts (because it's insecure), I've found writing a simple C wrapper with a setuid is suffice and then using a system call to modify the ulimits of the running process before dropping privileges and executing your shell script.

Craig
  • 4,268
  • 4
  • 36
  • 53