充其量我可以用shell会话来描述这个问题：
这表明ulimit工作正常。 这是正常的ssh会话的开始：
$>ulimit -c 0 (ushanka:973:0) ~ $>ulimit -c unlimited (ushanka:974:0) ~ $>screen -t question <-- see next preformated section for screen session --> [screen is terminating] (ushanka:976:0) ~ $>ls -alh /usr/bin/screen -rwxr-sr-x 1 root screen 353K Dec 4 2006 /usr/bin/screen (ushanka:977:0) ~ $>ulimit -c unlimited 这是为核心设置了一个像硬限制0一样的突发行为的屏幕实例。
$>ulimit -c 0 (ushanka:973:0) ~ $>ulimit -c unlimited bash: ulimit: core file size: cannot modify limit: Operation not permitted (ushanka:974:0) ~ $>cat ~/.bashrc . $HOME/lbin/setenv (ushanka:975:0) ~ $>cat ~/lbin/setenv MACH=`uname -m` settve() { eval `/home/tv/tools/common/bin/settve $0 $@`; } export LD_LIBRARY_PATH=${HOME}/local/${MACH}/lib:$LD_LIBRARY_PATH export PATH=${HOME}/local/${MACH}/bin:$PATH (ushanka:976:0) ~ $>
所以在屏幕会话ulimit似乎有一个硬限制0集，我不明白为什么。 解决方法是使用su – 作为开始屏幕的命令，但是这并不实际。 我已经看到很多从屏幕内使用ulimit的例子，而不会发生这个问题。 有一件重要的事情可能是屏幕的组会话ID被设置为屏幕组。 但是，在/etc/security/limits.conf文件中没有限制。
有没有人知道发生了什么，我该如何解决这个问题？
我在系统范围的交互式非loginshell中find了一个脚本ulimit -c 0没有-S。 这是什么原因造成的问题，因为运行屏幕导致这些脚本运行透明的普通用户。 这是脚本中的一个错误，系统pipe理员修复了它。