6

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 
10100
[madhatta@server madhatta]$ ulimit -n 10200
[madhatta@server madhatta]$ ulimit -n 
10200
[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
1024
[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?

0

2 Answers 2

4

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.

9
  • The great thing is you debug yurself. +1 for that.
    – devsda
    Mar 12, 2013 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, 2013 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, 2013 at 13:09
  • ohk. I will mail that to you. Can I tell the problem here.Please
    – devsda
    Mar 13, 2013 at 13:12
  • 1
    Most sysadmins are at least partly philosophers!
    – MadHatter
    Mar 13, 2013 at 13:16
0

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.

1
  • 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, 2012 at 12:42

You must log in to answer this question.

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