Weird bash behavior

[Marie-Josee Cormier]

On our production box.. We have most of our users loging in a simple bash menu box. At the end of the menu, a simple read comment to input the menu choice.

# bash --version
GNU bash, version 3.00.0(3)-release (hppa2.0w-hp-hpux11.11)
Copyright (C) 2004 Free Software Foundation, Inc.

If a user do not exit this simple menu, and shuts down his PC, or other reason and do not log off.. I see bash hitting the CPU hard, and creating some child processes.

Is this normal? If in one night, I have two of three bash session behaving this way, it has a big impact on our machines, hitting our CPU hard..

Any input on this?

Thanks

[Steven E. Protter]

Shalom,

bash for HP-UX is not exactly mainstream software. You may wish to migrate those uses that can tolerate it to korn shell or posix.

Or look for a newer version of bash. I've not seen this, however most of my users that use bash use it while connected to a Linux server, not an HP-UX server.

SEP

[Elmar P. Kolkman]

Try setting traps to logout if the connection does a hangup.

[Bill Hassell · Accepted solution]

This is a classic problem when a PC user crashes or simply walks away without a logout. It doesn't matter whether the shell is bash, ksh or POSIX-sh. Menu programs must handle two conditions: traps and a timeout. First check that /etc/profile has TWO trap statements. The first turns off trap conditions at the top of the script. This prevents the user from escaping to a shell prompt before the menu script starts. The second is at the bottom and is almost identical but it turns traps back on again. If this trap statement is missing, you will indeed get CPU loops.

Here are the two traps:

trap "" 1 2 3 15
trap 1 2 3 15

The first trap disables signals 1,2,3 and 15. The "" is a do-nothing action and the numbers are signals. For instance, a CTRL-C generates a signal 15 and it will do nothing after this trap is run.

The second trap restores normal operation and CTRL-C now terminates the current process. The hang occurs when signal 1 (also known as SIGHUP or hangup) is disabled. A session, whether connected by a LAN or a modem will generate a SIGHUP signal it the connection is severed (as in hang up the telephone).

So when a connection is terminated by a PC crash, the hangup signal will terminate the process tree for that terminal -- unless SIGHUP is disabled. When a session is disconnected but the processes are still attached if the hangup signal does not occur. This creates an indeterminate state and the shell starts talking to itself. Thus the excess CPU usage. Defunct processes can occur when child processes do not get become orphans due to parent problems.

So in your script, whether it is run from /etc/profile or is the actual shell for the user, be sure trap 1 is run at the start of the script. You will probably want to disable 2,3 and 15 so something like this at the start:

trap 1
trap "" 2 3 15

As far as a timeout goes, this gets a bit trickier. It's not practical to change every input line in the script, so you may need to write a parent script to watch the activity on the line. The who -u command will show the idle time for the current session. You'll need to evaluate an appropriate idle time (minutes, hours) and then terminate the menu program.

[Ken Martin_3]

Since you are still in the profile and are concerned with users terminating the session unexpectedly you may want to try adding the following at the top of the profile

trap exit 1 2 3 15

Then should an event occur the script should exit (terminate).

[Marie-Josee Cormier]

With all your help, I think I found it..

my profile is set up correctly.. But I did some debuging, and on BASH.. the command "trap 1 2 3" does not work.. It works on posix tho..

Look...Running on posix
# trap 1 2 3
# trap
trap -- 'echo '\''logout root'\' EXIT

Running on bash
# /usr/local/bin/bash
# trap 1 2 3
# trap
trap -- '1' SIGINT
trap -- '1' SIGQUIT

It mapped 1 to SIGINT and SIGQUIT...
I'll fix this and should fix our problems..

Thanks!!