Well, I have to say this list is really great.
Many thanks to the following which have been the first to reply:
"Brion Leary" <brion@dia.state.ma.us>
djohnson@nbserv2.dseg.ti.com (Danny Johnson)
Casper Dik <casper@holland.Sun.COM>
"Bruce Rossiter" <AROSSITE@us.oracle.com>
Ray Trzaska <rtrzaska@uk.mdis.com>
Briefly:
yes, the problem is due to raising the *soft* limit above 1024 -
otherwise anything using select can get confused.
I will try to lower the limit to that level next time I have a chance
to reboot the box.
BTW, I think that the effect I am seeing (filemgr, mailtool & Co. happily
coredumping) is possibly spectacular enough to deserve a mention in the FAQ.
Many have suggested (as the FAQ does) that going above 256 is also bad, as it
could adversely affect the stdio system calls.
BUT, the original reason that forced me to raise the fd limit was that
in.named was running out of file descriptors & refusing to complete a
zone transfer (the machine is primary NS for several domains ). Since,
AFAIK, 256 is the default value for the fd number, that would appear
to be too low (*sigh*).
The ulimit solution outlined below is a real pain, as it requires
having specially hacked versions of named (and httpd in the near
future ...)
Following are some of the answers I received, as well as my original message.
Cheers,
Alessandro Forghieri
--- From: Casper Dik <casper@holland.Sun.COM>This is not supported. All applications using select may die if you increase the soft limit past 1024.
You are advised not to increase the soft limit past 256 because of stdio. As you now noticed, past 1024 doesn't work at all.
The hard limit is of no consequence.
Casper
----
From: "Bruce Rossiter" <AROSSITE@us.oracle.com>
[...]
Yes, your problem is due to raising these limits. Set them back down to 256 and you should be fine. If you really, really, really, must have a single process with more than 250 open files, change only the hard limit to a higher value, and have your process call ulimit to raise the soft limit to the hard limit before it runs.
1. Stdio routines are limited to using file descriptors 0 - 255. Even though you can set the limit higher than 256, if fopen() cannot get a file descriptor lower than 256, the fopen() fails. This can be a problem if you have other routines using open() directly. For example, if you open 256 files with open() without closing any, you won't be able to open any files at all with fopen(), because all the low-numbered file descriptors have been used up.
2. It is somewhat dangerous to set the fd limits higher than 1024. There are some structures defined in the system (like fd_set in <sys/select.h>) that assume that the maximum fd is 1023. If the program uses an fd larger than this with the macros and routines that access this structure (like FD_SET()), it will corrupt its memory space because it will modify memory outside the bounds of the structure. This structure is used specifically by the select() routine, and indirectly by many library calls that use select().
---And this is my original message:
Hello, everybody. After increasing the hard/soft file limit on a :
SunOS alpha 5.5 Generic sun4m sparc SUNW,SPARCstation-5
I found out that filemgr, cmdtool, mailtool, textedit, etc. now dump core shortly after start up ( a second or so, at best - just enough for the window to appear)
Luckily, my terminal of choice is xterm - or I'd be stumped for good.
Using truss did not help much, except all of the commands appear to terminate nearly the same way, namely:
ioctl(3, FIONREAD, 0xEFFFEC3C) = 0 read(3, "1C\0\0C602C0\00F\0\0\0C7".., 32) = 32 ioctl(3, FIONREAD, 0xEFFFEC3C) = 0 Incurred fault #6, FLTBOUNDS %pc = 0xEF6CCDE0 siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
where the third argument of ioctl and the second to read are variable.
Does anyone know how to fix this? Is it really due to the changes I made to /etc/system?
[ i.e. - from the FAQ:
* set hard limit on file descriptors set rlim_fd_max = 4096 * set soft limit on file descriptors set rlim_fd_cur = 2048
]
Advanced thanks to all who'll bother - I will summarize.
Cheers, Alessandro Forghieri
---- Alessandro Forghieri Sitemaster-Nouvelle srl voice: +39-59-345767 Via Giardini 460 http://www.orion.it/~alf 41100 Modena ITALY "We're all mad around here.I'm mad.You're mad. "How do you know I'm mad?" said Alice. "You must be" said the cat, "or you would'nt have come here"