Orphaned shells

[James Mercer]

Hi,

We have had a large number of orphaned shells running a script over and over on our 11i computers. This script used to work fine on our old 11.0 systems.

The situation is this:
User logs in. In /etc/profile we have a line to start another script to limit the user's activities. When some users disconnect, their shell remains and is rapidly running through the script over and over again (it was set to refresh on bad input). I think the users might be shutting down their PCs with the connection open (rather than choosing exit/logout) when the looping occurs.

Since this didn't happen on our old systems using the same script, I'm assuming a telnetd, stty or ?? setting is not correct on our 11i system. I don't have the old systems to compare against. Any thoughts or directions?

Thanks,
James

[Chris Wilshaw]

James,

Does the script or profile contain a line to ignore some signal traps?

eg:

trap "" 1 2 3

I've seen issues with this in the past where users close down a terminal emulator - the trap of signal 3 (SIGQUIT) then gets ignored leaving scripts running on the system.

Sounds like the sort of thing you're seeing.

[Victor BERRIDGE]

Hi James,
I once had the same scenario, but found out that the dev team did modify something...
I would suspect in the users .profile a call to a new shell ( for calling a menu for exemple) instead of a exec instruction.

Or are you in X ?


All the best
Victor

[James Mercer]

Hi and thanks for the response.

Chris - yes, we do trap "" 1 2 3 so that the users cannot break out of the menus and get a command line.
Vince - we do an exec to the second script (from /etc/profile).

Here is the snippet of /etc/profile that calls the second script (the script that repeats endlessly):
stty intr "^-" quit "^-" kill "^-" eof "^-" eol "^-" susp "^-"
set -u
trap "echo 'logout'" 0
export TERM=vt220
exec /usr/utils/ourmenu

This was a direct copy from our old system as far as I remember.

We've used a work around, by counting the number of times /usr/utils/ourmenu loops and then dropping out if it exceeds 10. However, we still get a few orphaned shells/scripts and I was wondering if this could be a telnet communication setting, does -y make a difference on the telnetd server, could one of the stty settings be causing the problem? Or is this just a 'bug' in our 11i system?

Thanks

[Bill Hassell · Accepted solution]

Here's most likely the problem: Standard /etc/profile from HP starts with the statement: trap "" 1 2 3 at the top of the script. That disables signals 1 2 and 3 (SIGHUP, SIGINT and SIGQUIT respectively. SIGINT is the CTRL-C character (again, the HP default) and SIGQUIT is CTRL-\ which forces a core dump of the current process.

SIGHUP is likely the problem. HUP is short for hang-up and was originally designed for modems. Since the phone line is not always reliable, the modem signals carrier detect (CD) and modem ready (DTR) go false with loss of telephone connection and this in turn generates a SIGHUP to the session attached to the device file. Properly, the program terminates because there is no more connection.

The same thing happens with a telnet connection. Users (unfortunately) do not always properly logout. but instead just trash their terminal window by hitting the X button, or worse, turning off the power and going home. Telent protocol has the same SIGHUP mechanism and recognizes loss of connectivity and sends SIGHUP. But if trap "" 1 has been set, the action for SIGHUP is "" which means ignore.

You can most likely fix your problem by changing:

trap "" 1 2 3

to

trap "" 2 3

Since SIGHUP is not mapped to a special key (unlike CTRL-C and CTRL-\), this won't affect the restricted shell script.

[James Mercer]

Thanks Bill. I'll change the trap and see if it works. It usually takes a few days on our test system before I'll know if it has made a difference.

Thanks again for the help (and sorry Victor about responding to you with the wrong name...)