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 ?

Ameliorator
  • 181
  • 2
  • 6
  • maybe this post can help you http://superuser.com/questions/404239/setting-ulimit-on-a-running-process – c4f4t0r Nov 26 '13 at 19:21

4 Answers4

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
nous
  • 41
  • 1
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
Ameliorator
  • 181
  • 2
  • 6
  • 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/ files, works nicely most of the time. – zerodeux Sep 11 '14 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

Christopher Karel
  • 6,582
  • 1
  • 28
  • 34
  • Thanks for the answer, Christopher.Yes, you guessed it right, I'm trying to avoid reboot.I tried this but it didn't work. – Ameliorator Dec 28 '12 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. – Christopher Karel Dec 28 '12 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 – Ameliorator Dec 28 '12 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 – Ameliorator Dec 28 '12 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. – Christopher Karel Dec 28 '12 at 19:12
  • we can think of azkaban as a daemon process which is running under userxyz. Restarting azkaban has not helped because even on restart it gets the same FD limits which are set for userxyz. Until the limits of userxyz are changed any processes running under it will get the same old limits. – Ameliorator Dec 29 '12 at 09:46
  • I have changed the question a bit to make it useful for someone in future. Christopher's answer was completely relating to the question I posted earlier. Apologies to Christopher for changing the question. – Ameliorator Dec 30 '12 at 09:20
-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.

Mircea Vutcovici
  • 17,619
  • 4
  • 56
  • 83