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

I'm banging my head on this, and I can't understand why it's not working. I'm hoping that someone can shed light on this, or failing that, give me some suggestions for avenues of investigation.

I've got a Red Hat 7.3 system (don't ask) where it's desirable to increase the open files limit for the wls81 user. I thought that I was just not able to control it, but it increasingly looks as if I've only got the problem with the user I need to change. I've added the following lines to /etc/security/limits.conf:

wls81       soft    nofile      10100
wls81       hard    nofile      10240
madhatta    soft    nofile      10100
madhatta    hard    nofile      10240

pam_limits.so is being properly invoked, as far as I can tell:

[madhatta@server madhatta]$ sudo grep limits /etc/pam.d/*
/etc/pam.d/login:session    required     /lib/security/pam_limits.so
/etc/pam.d/sshd:session    required     /lib/security/pam_limits.so
/etc/pam.d/su:session    required     /lib/security/pam_limits.so
/etc/pam.d/system-auth:session     required      /lib/security/pam_limits.so

When I ssh in as myself, I get the new soft limit, and can increase up to the hard limit:

desktop> ssh server
Last login: Thu May 10 13:20:13 2012 from a.b.c.d
[madhatta@server madhatta]$ ulimit -n 
[madhatta@server madhatta]$ ulimit -n 10200
[madhatta@server madhatta]$ ulimit -n 
[madhatta@server madhatta]$ ulimit -n 10300
bash: ulimit: cannot modify open files limit: Operation not permitted

but when I ssh in as the wls81 user, I can't:

desktop> ssh wls81@server
Last login: Wed May  9 22:29:33 2012 from a.b.c.d
[wls81@server wls81]$ ulimit -n
[wls81@server wls81]$ ulimit -n 10000
bash: ulimit: cannot modify open files limit: Operation not permitted

The same happens when I su - to each user. I honestly can't see why this user's not able to have its ulimits reset. Anyone have any ideas?

share|improve this question

2 Answers 2

up vote 4 down vote accepted

Well, the mystery is solved. I found that when I did su - wls81 I got the 1024 limit, but when I just did su wls81 I got the new, higher limit. It turns out that wls81's .bash_profile invoked another script, which in turn invoked an environment-setting script from a completely different user on the system, which did a ulimit -n 1024.

When I removed that line, wls81 now gets the new limit.

share|improve this answer
The great thing is you debug yurself. +1 for that. –  devsda Mar 12 '13 at 13:09
I am also facing the same problem, like you faced. Can we do a chat discussion for that. Please. –  devsda Mar 13 '13 at 13:03
jhamb, I'm happy to try to help but am working onsite the next couple of days so can't do a chat until next week. Feel free to email me, though; my personal website is listed in my profile, and my work-related email address is on there. –  MadHatter Mar 13 '13 at 13:09
ohk. I will mail that to you. Can I tell the problem here.Please –  devsda Mar 13 '13 at 13:12
Most sysadmins are at least partly philosophers! –  MadHatter Mar 13 '13 at 13:16

I think you might also need to check and probably set max filedescriptors for open files in kernel:

sudo systcl fs.file-max

and edit /etc/sysctl.conf to make changes permanent.

share|improve this answer
Nope, that limit's currently much higher (314570). And if you read my question, you'll see that I have successfully changed the ulimit for another user on that system; so whatever's stopping me, it's not system-wide. Good guess, though! –  MadHatter May 10 '12 at 12:42

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.