5

To increase the FD limit for a daemon process running under a headless user on a Ubuntu Linux machine we did following changes in /etc/security/limits.conf

soft nofile 10000
hard nofile 10000

We also added session required pam_limits.so in /etc/pam.d/login. The changes got reflected for all the users who logged out and logged in again. Whatever new processes are starting under those users are getting new FD limits.

But for the daemon which is running under a headless user the changes are not getting reflected. what is the way by which the changes can be reflected for the daemon which is running under headless user ?

1

4 Answers 4

4

You can read/set the resource limits of a running process with prlimit(1), part of util-linux:

sudo prlimit --pid PID --nofile 8192:16384
1
  • For me, command did not work as it is. I used this:-. "prlimit --pid PID --nofile=8192"
    – piyush
    Jun 23, 2017 at 13:18
3

The problem was in the launching script of daemon. It was using setuidgid to run the daemon under headless user.Looks like setuidgid will not install the resource limits which are set in limits.conf while changing user/group for the process. A daemon should take care of setting resource limits for itself via its launching scripts. By setting max FD limits for the current session in the launching script, the new limits got reflected for the daemon.This was done by inserting a ulimit -n line as below in the lauching script of daemon.

ulimit -n $NEW_MAX_LIMIT
exec setuidgid userxyz /pat/to/daemon.sh
1
  • 1
    That's it. Many services will daemonize without consulting PAM and ignore /etc/security/limits. Sometimes they fiddle with limits themselves before giving up root privileges (like Nginx), sometimes you do it explictly with 'ulimit' beforehand (like with Apache). I sometimes put those 'ulimit -n XXX' in /etc/default/<service> files, works nicely most of the time.
    – zerodeux
    Sep 11, 2014 at 15:40
0

Rebooting will definitely take care of it. But I assume you want to avoid that. (who doesn't?)

So you're going to need to HUP the init process. It almost always runs on PID 1, but you may want to double check on your system. This isn't exactly the safest thing to do, but it could avoid that reboot. So please try this on a test box first:

kill -HUP 1

7
  • Thanks for the answer, Christopher.Yes, you guessed it right, I'm trying to avoid reboot.I tried this but it didn't work. Dec 28, 2012 at 16:46
  • Hmm...can you then be more specific by what you mean by "headless user"? Are these cron jobs, an existing daemon spawning new threads, etc? There may be something more specific you need to HUP. Dec 28, 2012 at 16:53
  • It is a password less userid.we launch our production processes under this userid. If I do a cat on etc passwd, I get this as output.cat /etc/passwd | grep userxyz Output: userxyz:x:1015:1015: userxyz headless user:/home/userxyz:/bin/bash Dec 28, 2012 at 17:00
  • There is an existing shell script which starts azkaban job scheduler using exec setuidgid userxyz /path/to/azkaban/launching/script.sh Azkaban will then periodically launch the other processes. So ultimately the processes are running under userxyz Dec 28, 2012 at 17:07
  • I'm not too familiar with Azkaban, but doesn't that have a persistent daemon process running? If so, HUPing the Azkaban daemon might do what you need. Dec 28, 2012 at 19:12
-1

You can set the limits of a running process using procfs.

Find the process ID that you want to change (in this case 1234), then run:

pid=1234        # This is the process ID, found with `ps`.
h_nofile=16384  # hard limit of "Max open files"
s_nofile=8192   # soft limit of "Max open files"
grep "Max open files" /proc/$pid/limits
echo -n "Max open files=$s_nofile:$h_nofile" > /proc/$pid/limits
grep "Max open files" /proc/$pid/limits

This method is not anymore supported by recent kernel. The alternative is to use prlimit as @nous was mentioning.

5
  • This did not work for me: echo: write error: Invalid argument
    – Old Pro
    Dec 19, 2013 at 20:20
  • You need to run as root or as the same user as the process. Dec 23, 2013 at 16:49
  • Running that as root didn't work either.
    – timurb
    Dec 15, 2014 at 10:49
  • Worked for me in RHEL 6.2 kernel 2.6.32-279.14.1.el6.x86_64. I modified to set max core size in a running process. I believe the "-n" for echo is required, else "write error: invalid argument". Requires kernel 2.6.32 or higher. If the process isn't yours, you'll need root/sudo. Jun 13, 2016 at 20:30
  • Yes, -n is required. It will suppress the new line. Jun 13, 2016 at 21:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .