Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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 ?

share|improve this question
maybe this post can help you… – c4f4t0r Nov 26 '13 at 19:21

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/
share|improve this answer
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 '14 at 15:40

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
share|improve this answer

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

share|improve this answer
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 /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/ 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

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.

share|improve this answer
This did not work for me: echo: write error: Invalid argument – Old Pro Dec 19 '13 at 20:20
You need to run as root or as the same user as the process. – Mircea Vutcovici Dec 23 '13 at 16:49
Running that as root didn't work either. – timurb Dec 15 '14 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. – RaveTheTadpole Jun 13 at 20:30
Yes, -n is required. It will suppress the new line. – Mircea Vutcovici Jun 13 at 21:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.