I am trying to use ulimit to set a maximum vmem value
to keep wayward user apps from trashing my server.
The host is an IBM eServer BladeCenter, 64bit with 16 GB RAM and 2 dual-core
Xeon CPUs running Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
with a 2.6.9-68.9 kernel.
When I use ulimit in ksh prior to starting my app,
it produces strange and incorrect results.
The first try used ksh93r (Version M 1993-12-28 r)
which the file command reported as
93r/bin/ksh: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not
stripped
Odd ksh93 behaviors observed:
a) Running "ulimit --vmem 8192000" causes it to be set to 3997696
*and* cpu limit to be set to -201326592 (previous value was unlimited).
b) Running "ulimit 1819200" causes process limit to be left at
unlimited but file size limit to be set to 1414784 (was umlimited).
When I realized this was a 32bit ksh and I was running it on a 64 bit host
starting a 64 bit app, I figured there were some internal integer overflow
issues or corruption of an internal C data structure.
My second try used ksh93t (Version M 93t 2008-11-04)
93t/bin/ksh: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV),
for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
Setting --vmem on this release also caused --cpu to be set, possibly
to some nonsense value. So it looks like overflow/corruption
was still in play even with the 64bit ksh.
My 3rd and final try used the stock Red Hat /bin/ksh (Version M
1993-12-28 q)
/bin/ksh: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV),
for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
This gave me the same results as my second try.
Is this a known issue with these older ksh releases?
If there are bounds issues with the 32 bit ksh, shouldn't there be some
checking of the input strings to prevent user error from causing overflow?
Is it possible that the 'AMD x86-64' as shown by the 'file' command
indicates an incompatibility with the Intel Xeon CPU?
Mario DeFazio
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
