Re: Increase maximum per-process open files in 4.1.2? (summary)

From: Tim Goodwin (
Date: Thu Jul 22 1993 - 07:03:17 CDT

In article <22k4je$> I wrote:
>Is it possible to increase the per-process number of open files in a
>SunOS 4.1.2 system (running on an IPC)? [ beyond 64 ]

I got answers from

    Jim Davis <>
    Mario Nigrovic <>
    Eckhard Rueggeberg <>
    Guy Harris <>

Thank you all. Guy's was (of couse :-) the fullest answer, so I
include that below.

Presumably where the sysconf(2) man page says

    The value does not change during the lifetime of the calling

it should add

    ...unless the process calls setrlimit.



Return-Path: <>
Received: from AUSPEX-GW.AUSPEX.COM by with SMTP (PP)
          id <>; Wed, 21 Jul 1993 22:50:16 +0100
Received: from (
          by auspex-gw.Auspex.COM (4.1/SMI-4.1) id AA13308;
          Wed, 21 Jul 93 14:50:01 PDT
Received: from by (4.1/SMI-4.1) id AA22394;
          Wed, 21 Jul 93 14:49:58 PDT
Date: Wed, 21 Jul 93 14:49:58 PDT
From: (Guy Harris)
Message-Id: <>
Received: by (4.1/SMI-4.1) id AA07657;
          Wed, 21 Jul 93 14:50:50 PDT
Subject: Re: Increase maximum per-process open files in 4.1.2?

>Is it possible to increase the per-process number of open files in a
>SunOS 4.1.2 system (running on an IPC)?


>I've tried changing NOFILE in /sys/sys/param.h, and also NOFILE_IN_U
>in /sys/sys/user.h before rebuiling the kernel, but to no avail.

Neither of those will help.

The first governs the size of a data structure in the kernel, so to
change it successfully, you'd need to recompile from *full* kernel
source and *also* rebuild any user-mode code that depends on the layout
of the U area (the "-lkvm" library, etc.).

The latter is used in compiled-in code in a kernel module source to
which is not supplied.

However, you presumably noticed that NOFILE is greater than NOFILE_IN_U,
and that the limit you're currently seeing is NOFILE_IN_U:

>sysconf(_SC_OPEN_MAX) and getdtablesize() both continue to report 64
>(correctly: open()s fail after fd 63).


>I can't find anything in the documentation on this.

Check out "GETRLIMIT(2)"; you'll find

     Limits on the consumption of system resources by the current
     process and each process it creates may be obtained with the
     getrlimit() call, and set with the setrlimit() call.

     The resource parameter is one of the following:


     RLIMIT_NOFILE one more than the maximum value that the
                         system may assign to a newly created
                         descriptor. This limit constrains the
                         number of descriptors that a process may


>Is it possible,


>or is 64 hardwired in?


The default "soft limit" for RLIMIT_NOFILE is 64 (NOFILE_IN_U); the
"hard limit" is 256 (NOFILE).

If you crank the "soft limit" up above 64, you get more than 64 file
descriptors. You can do that in a program with "getrlimit()" and
"setrlimit()"; you can do it from the C shell with the "limit" command:

     limit [ -h ] [ resource [ max-use ] ]
               Limit the consumption by the current process or
               any process it spawns, each not to exceed max-use
               on the specified resource. If max-use is omitted,
               print the current limit; if resource is omitted,
               display all limits.

               -h Use hard limits instead of the current lim-
                    its. Hard limits impose a ceiling on the
                    values of the current limits. Only the
                    super-user may raise the hard limits.

               resource is one of:


                    descriptors Maximum value for a file

You can't raise the hard limit above 256 in SunOS 4.1[.x] without the
aforementioned complete recompile from source, except by getting Sun's
DataBase Excelerator, or whatever "DBE" stands for, product, which
cranks it up to 1024.

In SunOS 5.x, the hard limit is 1024, and the Bourne and Korn shells let
you get and set the limit with the "ulimit" command. (The latter should
be true of all SVR4 systems; dunno what the hard limit is in other SVR4



Tim Goodwin |  or | Usenet will also be converted to OSI-based
PIPEX Ltd   | | services in the long term - B Plattner et al.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:02 CDT