Increasing nofiles in ulimit

[Russell Gould]

We are experiencing problems running overnight jobs and I identified that the threshold of nfile was being reached at the point when the job fell over. I subsequently increased the nfile paramter from 6010 to 12020 and rebooted the server. I can see now that the threshold is much higher and is not now being reached.

We are still however experiencing problems intermittanly.

I have been advised to check that values returned by performing 'ulimit -a' from command line, and within the application (which runs the job that is failing).

From within the application, the following is reported :

Ulimit..BeforeJob (ExecSH): Executed command: "/bin/ulimit -a"
*** Output from command was: ***
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 1024

and from command line, issuing a ulimit -a returns :

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 512

This poses a couple of questions ...

I do not understand why the value of nofiles is different running a shell initiated by the app to opening a shell normally, but I suspect that the following lines taken from the application 'environment configuration file' may influence it ...

# Locate "osh" and exec it if found
ULIMIT=`(ulimit) 2>/dev/null`

if [ $? = 0 -a "$ULIMIT" != "unlimited" ] ; then
if [ $? = 0 -a "$ULIMIT" -lt 2113674 ] ; then
if [ -f $ORACLE_HOME/bin/osh ] ; then
exec $ORACLE_HOME/bin/osh
else
for D in `echo $PATH | tr : " "`
do
if [ -f $D/osh ] ; then
exec $D/osh
fi
done
fi
fi
fi




I cannot get my head around why when typing `ulimit` which returns the text 'unlimited' it contiues to report the stats listed at the start (nofiles(descriptors) 1024) instead of unlimited.

How do I get the value of nofiles higher than 1024 ?

The value of the parameters maxfiles (Soft limit) is 512, and maxfiles_lim (Hard limit) is 2048

Do these need to be increased ?

Thanks in advance for your help

Russell

[T G Manikandan]

you can use

#ulimit -Hn 2048

[Russell Gould]

Thanks for this.

I did try ulimit -Hf and -Sf Unlimited, and indeed Hn 2048, but when you run ulimit again, it does not report the new values ?

I therefore am not sure as to whether the new value has been taken or not.

Any ideas ?

Cheers

Russ

[Ramkumar Devanathan]

Hi Russell,

Did you run ulimit as root?

The effective user id and current user id when you run it from command line determine the value of ulimit's output.

>>>>>>>>
$ id
uid=102(ramd) gid=20(users)
$ ulimit
unlimited
$
<<<<<<<<<

>>>>>>>>
# id
uid=0(root) gid=3(sys) groups=0(root),1(other)
(lp)
# ulimit
4194303
<<<<<<<<<

I guess you shuold perform all operations as root to have any effect.

- ramd.

[T G Manikandan]

Can you try this

$ulimit -Sn `ulimit -Hn`

[Russell Gould]

Same thing happens whether I'm a normal user or a UID 0 account.

I have also tried ulimit -Sn `ulimit -Hn`

This does seem to increase limit to 2048

Should I use this in my application environment ? Why is it not taking ulimit and returning it as unlimited ?

Cheers

[Ramkumar Devanathan]

Russell,

ulimit is a shell builtin as well as separate binary.

the ulimit which gets called when you just type ulimit at the prompt is different from the ulimit executable called as /bin/ulimit or /usr/bin/ulimit.

in fact plainly ulimit -a does not work at the command prompt - say 'wrong option(s).

man ksh says this -

ulimit [n] if n is given impose a size limit of 'n' 512 byte blocks on files written by child processes. if n is not given the current limit is printed.

i am unable to find the man page for the ulimit command as opposed to the ulimit shell builtin.

i believe that when you call the ulimit command from within your script as /bin/ulimit, it calls the ulimit command and from command prompt it calls the shell builtin. that's why your variance in output.

wonder why i cannot find a man page for ulimit command.

HTH.
- ramd.

[A. Clay Stephenson]

The limit that ulimit is reporting is maxfiles (soft) and maxfiles_lim. Those refer to the maximum per process limits rather than the system-wide number of files (nfiles). It is those two that need to be increased and the changed will then be reflected in ulimit.

When a process fails, it is important to immediately capture the return code, S{?}; a well written application will return the errno value and that will be of great importance in finding the underlying problem.

[Steven E. Protter]

You could set it in the .profile of the user running the night jobs. Thats what we do.

You could do it in /etc/profile as I do.

ulimit -n 4096

All users get that limit for nofiles.

Its probably better to set it user by user, guess I was lazy.

SEP

[Bill Hassell]

Regarding ulimit:

ksh has *NO* options for ulimit (as you've seen from the man page). The options shown above (ulimit -a or ulimit -Sc, etc) are only available in the default POSIX shell where all the options are defined in the man page for sh-posix. The external ulimit command (if I remember correctly) is nothing but a POSIX shell script so whiole it will accept the POSIX shell options, it cannot change the parent shell's environment.

Unlike Solaris and other Unices, the default shell is not Bourne but a POSIX shell, in the case of HP-UX the POSIX shell is generally a superset (more capabilities) of the Korn shell (which is also a POSIX-compliant shell).

So if you change your login shell to /usr/bin/sh, you'll have all the options available. But note that ulimit is simply a shell command to call the setrlimit system routine. Any program can call this routine and manipulate the ulimit values within the kernel limits. For instance, the soft limit (maxfiles) can be increased by setrlimit (or ulimit) but not to exceed maxfiles_hard. The ulimit builtin has both -S and -H options to allow setting a new soft or hard limit for the current environment and child processes.

However, when you start a process, you may actually be running another shell script which then modifies the environment for the 'real' application program. Since most manufacturers try to write 'portable' shell code, they often miss HP-UX specific features and behavior is not exactly what is intended. In this case, it is best to rewrite the startup script and specify #!/usr/bin/sh as the first line, then modify the ulimit lines to take advantage for HP-UX capabilities.

And do the vendor a favor and forward the resultant changes on to their support staff so their scripts can be improved. I get suspicious of long startup scripts that do not have large case statements concerning specific Unix flavors as in:

case $OPSYSTEM in
HP-UX ) ..do HP-UX things..;;
SOLARIS ) ..do Solaris things..;
AIX ) ..do AIX things..;;
* ) ..print a warning and do general things..;;
esac