- 论坛徽章:
- 0
|
请教系统错误信息,急!!!
调整 /etc/conf/pack.d/kernal/space.c
Look for:
if BULLSEYE
don't touch this one maxexecargs
else
unsigned int maxexecargs = <something * 1024>;;
set to 200 or other number.
Relink the kernal and reboot.
---------------------
or read the following:
I don't remember my exact words from back then, but I know what I meant.
First, I did not mean to imply that there is any part of the shipped
operating system which, by itself, triggers these messages. As far as I
know, you would have to be running add-on software (including programs
or scripts of your own devising).
Second, if I seemed to say that receiving this message was inevitable,
that was only in reference to some specific situation on *your* machine.
Third, the only *typical* cause that I'm aware of is in the `configure`
scripts for certain source-code software distributions (I don't know
which). These packages have shell code that attempts to learn how big
the environment is. They do so by breaking the limit and seeing what
happens. Here, for example, is some Korn shell code that figures out
the limit:
#!/bin/ksh
unset `env | sed 's/=.*//'`
i=0
toohigh=2147483647
for step in 100000 30000 10000 3000 1000 300 100 30 10 3 1; do
len=$i
while :; do
((i += step))
[ $i -ge $toohigh ] && break
len=$(/bin/echo "$(printf "%${i}.${i}s" test)\c" 2>;/dev/null | wc -c)
if [ $len -eq $i ]; then
echo $i: ok
else
echo $i: too high
toohigh=$i
break
fi
done
((i -= step))
done
echo "Looks like we can cram a maximum of about $i bytes into the environment."
On an OpenServer system with the default configuration (maxexecargs =
100*1024), this comes up with 102375. It also triggers 9 "WARNING ...
MAXEXECARGS" kernel messages.
Obviously, anything else that tries to jam too much into the environment
will trigger the same message. On most systems, for instance,
ls -l `find / -type f -print`
will generate a message, since the total length of the system's file
pathnames will be much larger than 100K. |
|