Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 ?

share|improve this question
    
maybe this post can help you superuser.com/questions/404239/… –  c4f4t0r Nov 26 '13 at 19:21

3 Answers 3

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

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

Your Answer

 
discard

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.