> 6526924 kernel syscall Dis setrlimit(2)/getrlimit(2) should support
> RLIMIT_LOCKS, *_MEMLOCK and *_PTHREAD
Out of curiosity, I did a truss on a not-too-old ksh93 binary (s+), and saw the
following while
doing a ulimit -a:
[address space limit]
25539/1: getrlimit(RLIMIT_VMEM, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = RLIM64_INFINITY max = RLIM64_INFINITY
[core file size]
25539/1: getrlimit(RLIMIT_CORE, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = RLIM64_INFINITY max = RLIM64_INFINITY
[cpu time]
25539/1: getrlimit(RLIMIT_CPU, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = RLIM64_INFINITY max = RLIM64_INFINITY
[data size]
25539/1: getrlimit(RLIMIT_DATA, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = RLIM64_INFINITY max = RLIM64_INFINITY
[file size]
25539/1: getrlimit(RLIMIT_FSIZE, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = RLIM64_INFINITY max = RLIM64_INFINITY
[nofile]
25539/1: getrlimit(RLIMIT_NOFILE, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = 256 max = 65536
25539/1: sysconfig(_CONFIG_CHILD_MAX) = 29995
[pipe buffer size]
25539/1: pathconf("/", _PC_PIPE_BUF) = 5120
[?]
25539/1: getrlimit(RLIMIT_CPU, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = RLIM64_INFINITY max = RLIM64_INFINITY
[socket buffer size?]
25539/1: pathconf("/", _PC_PIPE_BUF) = 5120
[stack size]
25539/1: getrlimit(RLIMIT_STACK, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = 8388608 max = RLIM64_INFINITY
[process size]
25539/1: getrlimit(RLIMIT_VMEM, 0xFFFFFFFF7FFFD0B8) = 0
25539/1: cur = RLIM64_INFINITY max = RLIM64_INFINITY
Which is to say, as that binary does things, the address space and process size
limits look to be one
and the same on Solaris, as do the pipe buffer size and socket buffer size (and
AFAIK, pipe buffer
size is _not_ settable, unlike some OSs). On another trace, I saw something
reasonable for
the nproc limit (sysconfig(_CONFIG_CHILD_MAX)), although again, that's clearly
not going to
be something the individual process can set even a soft limit for.
Now, I can see _why_ the address space limit and process size limit are one and
the same:
$ grep RLIMIT_AS /usr/include/sys/resource.h
#define RLIMIT_AS RLIMIT_VMEM
but at the shell level, I wonder if it's not a little misleading to have them
both; it leaves the
impression that they can be set individually.
Perhaps it might help if the output of ulimit -a at the very least indicated
the limits that
were inherently read-only on a given platform; and in the case of limits that
were synonyms
on a particular platform (such as address space and process size on Solaris),
indicated that also.
And it's not at all clear to me what the sense of treating pipe buffer size and
socket buffer size
as the same is; maybe on some *BSD systems, pipe() is really socketpair(), but
on Solaris, real
pipe() calls result in a STREAMS based entity (onto which one can push STREAMS
modules,
use the STREAMS rather than the socketpair() method of passing file
descriptors, etc). OTOH,
I see that at least sometimes the ksh93 code maps pipe() to socketpair(); not
sure what the
heck it's doing on Solaris. Still, if it isn't mapping pipe() to socketpair(),
then by using
pathconf("/", _PC_PIPE_BUF) it's lying about the socket buffer size, and if it
is, it's lying about both.
So in addition to adding some other limits, rationalizing what ksh93 does with
the existing ones
on Solaris might not be a bad idea. (and the limit that some systems have,
RLIMIT_RSS, also
sounds rather tempting if one's going to be thinking of adding limits; I'd
think it would be
much more useful in most cases than RLIMIT_LOCKS, for example)
This message posted from opensolaris.org
