SJS wrote: > begin quoting Carl Lowenstein as of Tue, Mar 25, 2008 at 12:10:44PM -0700: > [snip] >> You can have as many channels as you wish, limited only by the >> availability of file descriptors. (a small non-negative integer). >> >> Historically the first three channels, 0, 1, and 2, were given names >> stdin, stdout, and stderr, respectively. Use of other file >> descriptors is not standardized, so to speak. > > Don't the bourne shells allow for a greater number of streams than the > minimum? >
Try help ulimit $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 8183 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 8183 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited But, as I recall, the underlying limit is a files-descriptors per process limit of the kernel. Oh wait -- maybe the kernel limit has been removed? Root can set really high ulimit -n values. Although users can only reduce their settings. /etc/profile sets some ulimits. ==> Where are the "hard limits" that a user can set? <fuzzy> Max file descriptors was actually a serious problem for the inotify(7) facility -- maybe just in earlier incarnations?</fuzzy> Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
