Tested on Tru64 5.1.
Users are forced into an application by an exec command placed in their ksh
shell's .profile. The .profile files are the default with an "exec
/some/path/foo" command and an "exit" added at the end.
Problem: I noticed on occasion that users would be troubled with immediate
disconnects after authentication. The disconnect would occur at the "exec"
line with a message: "You have running jobs".
Trial and error and employing "set -x", "jobs -l", etc. against .profile
files leads me to this boiled down example of a .profile that will reproduce
the problem:
#start of .profile
sleep 5 &
exec ./foo
exit
#end of .profile
The above snippet mirrors the failure that you get from:
#start of default .profile
#... some stuff
echo $PATH | /bin/grep -q "$HOME/bin" ||
{
PATH=$HOME/bin:${PATH:-/usr/bin:.}
export PATH
}
exec ./foo
exit
#end of .profile
Namely, the echo and grep command are still hanging about as background jobs
when the exec command is attempted... for reasons that I am unsure of...
this causes the exec command to fail for login shells. If you put a "sleep
1" after the PATH block, the race condition seems to go away (echo and grep
have time to die) and the exec is always successful.
Work arounds are easy. I am curious if anyone understands why this is the
case for login shells, i.e. why does exec fail if background procs exist?
Further why are echo and grep "hanging around"--shouldn't they be dead and
gone by the time the exec call is attempted?
ajgarsha1_at_charter.net
Received on Sat Jan 04 2003 - 20:08:56 NZDT