3

At best I can describe this issue with a shell session:

This shows that ulimit works fine. This is the start of a normal ssh session:

$>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

This is the screen instance which ulimit all of the sudden acts like a hard limit of 0 is set for core.

$>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) ~
$>

So inside of the screen session ulimit seems to have a hard limit of 0 set and I cannot figure out why. A work around is to use su - as the command to start screen, however that isn't going to be practical. I've seen many examples of using ulimit from within screen without this issue occurring. One thing of importance might be that the group session id for screen is set to the screen group. However, there are no restrictions in the /etc/security/limits.conf file.

Does any one know what is going on and how I can fix this?

James
  • 151
  • 5
  • 1
    I found a script buried in the bowls of the system wide non login shell setting ulimit -c 0 without the -S. This is what was causing the issue I'm seeing. I can't answer my own question for at least 7 more hours, so I'm adding it as a comment for now. – James Aug 31 '11 at 21:26

1 Answers1

2

I found a script inside of the system wide interactive non-login shell setting ulimit -c 0 without the -S. This is what was causing the issue because running screen causes those scripts to run transparent to a regular user. It was a bug in the script, the sysadmin has fixed it.

James
  • 151
  • 5