ulimit -n 2048 gives "operation not permitted" in SUSE 9.1 Pro.

Does anyone know why when I try to up the file handles in SUSE 9.1 I get the error:

someuser@somemachine:~> ulimit -n 4024
-bash: ulimit: open files: cannot modify limit: Operation not permitted

This happens when I ssh into the box. I haven't tried other access methods. Of course, the root user doesn't get such an error.

What I've tried so far:
Looked in /etc/profile, /etc/profile.local (doesn't exist), the local user .bashrc and .profile files, and in any other login files I could find. This doesn't appear to set a limit anywhere.

Looked in /etc/security/limits.conf, there is no nofiles setting in there.

Looked in /etc/pam.d/login and unset and reset a requirement to use pam_limits.so

Tried creating a /etc/profile.local and setting limits in there in hopes that it would set it as root.

Looked in /proc/sys/fs for the max fs limit, it's very high.

Somewhere, a hard limit is getting set. Maybe the default kernel setting or some special ssh setting? There is nothing in /etc/ssh/sshd_config that looks suspicious.  

Who is Participating?
JJSmithConnect With a Mentor Commented:

As far as getting anomilies when logging in via ssh goes;

if UsePrivilegeSeparation in /etc/ssh/sshd_config is set to yes (the default) - try setting it to 'no' restart the sshd and log back in.

rzupAuthor Commented:
I also looked in /etc/bash.bashrc
most likely the limits are set to hrad limits by thesystem
Try to find ulimit command with option -H in your system resource files in /etc
The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

rzupAuthor Commented:
Thanks ahoffman,

grep'ing every file in /etc /etc/init.d and /etc/sysconfig for ulimit doesn't seem to turn up anything for number of files.

/etc/profile has:

profile:    #ulimit -d 15000            # max data size of a program is 15 MB
profile:    #ulimit -s 15000            # max stack size of a program is 15 MB
profile:    #ulimit -m 30000            # max resident set size is 30 MB
profile:    ulimit -Sc 0                # don't create core files
profile:    ulimit -Sd $(ulimit -Hd)
profile:    ulimit -Ss $(ulimit -Hs)
profile:    ulimit -Sm $(ulimit -Hm)

which wouldn't seem to cause this. Also, you can't add a ulimit -n in /etc/profile without generating the original error.
ahoffmannConnect With a Mentor Commented:
oops, I see you're using -n
this is a kernel limit in Linux, see   cat /proc/sys/fs/file-max

try adding a line to /etc/security/limits.conf like (must not exceed the kernel limit, for obvious reason):

username hard nofile 4048

rzupAuthor Commented:
Thanks, ahoffman

We originally tried adding:

*                hard    nofile          4096

to /etc/security/limits.conf

That didn't work. I assume that doesn't require a reboot, though, I'm not able to try a reboot at this time. The file_max is 52427, which I take to be an overall system open files max.

I can, for any given user, lower the open file setting, e.g. ulimit -n 512 will work. However, if you lower it, you cannot raise it again. For example:

ulimit -n 512 (works)
ulimit -n 256 (works)
ulimit -n 512 (trying to get back up to 512 produces the error in question)

This seems like very odd behavior. Likewise, trying to reset the limit with Hn produces the same errors.
if you lower the limit, you need to logout out and login again, then you get back the limit as defined in /etc
This is indeed strange, I guess a bug ...
rzupAuthor Commented:
Yes, logging out and back in resets the limit to 1024, but the 1024 is  not defined in /etc/ anywhere that I can find. I'm guessing it's just a default, and the bug (if there is a bug) is that limits can never be raised period, only lowered.

There was a note in usenet where someone suggested using an /etc/profile.local file to set a higher initial limit--his logic was that profile.local is run as root. Even that didn't work (I'm not sure it's run as root). There are a lot of references to this issue on usenet. Someone noted that the problem only occurs on remote logins, not via the console. I just tried it, and, sure enough, if I login via the console, I can set ulimit -n 2048 without an error. That doesn't help me much though, other than it might be a good clue.

# Here's an extract from the man page onsetrlimit

    A resource limit is specified as a soft limit and a hard limit.  When a
     soft limit is exceeded a process may receive a signal (for example, if
     the cpu time or file size is exceeded), but it will be allowed to con-continue
     tinue execution until it reaches the hard limit (or modifies its resource
     limit).  The rlimit structure is used to specify the hard and soft limits
     on a resource,

           struct rlimit {
                   rlim_t  rlim_cur;       /* current (soft) limit */
                   rlim_t  rlim_max;       /* hard limit */

     Only the super-user may raise the maximum limits.  Other users may only
     alter rlim_cur within the range from 0 to rlim_max or (irreversibly)
     lower rlim_max.

# So does that suggest that if we start with:

soft limit 1000
hard limit 2000

if we increase to 1500 we would be increasing soft limit towards the hard limit. but if we decrease to something below our current soft setting then it is interpreted as a 'irreversible' lowering of the hard limit. So when we try to increase our soft limit again - it is now exceeding our hard limit !!!!

only guess work - but the manual is sort of explaining the outcome when we raise, lower and then fail to re-raise.

rzupAuthor Commented:
UsePrivilegeSeparation didn't work, but there is a setting just above it called UseLogin, and that seems to work, though I have no idea why. I just happened to start playing with the settings based on your idea. This particular machine, I just noticed, has a special sshd configured (specially compiled) to allow for chroots. This appears to be a further complication that enters into the issue.

Changing the /etc/security/limits.conf was also necessary. That seems to do the trick by itself on my other machines. On several other machines I have just tried, limits.conf  solved the problem by itself. It's unfortunate that the first machine I tried has the strange sshd, as they are all stock SUSE 9.1 Pro other than that one.

Thanks for all the help. I believe this is solved.
Chris GralikeSpecialistCommented:
This error might also occur if no user was specified in the limits.conf file.

Correct syntax should be

* soft {limit} {value}
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.