Cleaning up unix user session

[Brian_71]

On our HP box HP 11.11, it seems that the machine is not always cleaning up interactive session and shells when users disconnect.
Any idea why HP-UX isn't shutting these processes down?

[Corthouts Carlo]

What processes aren't killed from the users session?

Maybe the user did start some apps with nohup and in the background.
This would explain why these processes stay alive.

[Craig Rants]

Do you mean that the user is still showing as logged in although you know that they are not... That is a common problem. If so, here is the solution:

1. cd /usr/lib/acct
2. ./fwtmp < /etc/utmp > /tmp/utmp
3. edit /tmp/utmp changing 5th column to 8 for ghost user
4. ./fwtmp -ic < /tmp/utmp > /etc/utmp


GL,
C

[John Strang]

Brian,

Run ps -ef | grep
to see if any processes remain.
Do this also when user logged in, and again after they log out to compare.

John

[Andrew R.]

You need to add Timeout to the shell
Try adding this line into /etc/profile

# TMOUT=3600
# export TMOUT

This will terminate the shell after 1 hour (3600sec.) automaticaly.
I hope that answres your question.

[Bill Hassell]

I suspect that these problem sessions are not just shell command lines, but are instead complex tasks like Xwindow apps, and the users are not terminating their sessions properly (their PC crashes perhaps?) The problem is that the destruction of the connection violates the protocol and there is no way for HP-UX to know that the computer is gone.

A well-written Xwindow application will use keep-alive or health-checks to see that the display still exists, but most do not. Make sure that the users have not disabled trap processing in their login profile (check /etc/profile too). Otherwise, you'll have to regularly cleanup the mess left behind.

[Brian_71]

i don't understand. All of the programs should be launched from the original session which is a ssh session there for all child processes should also be killed upless they were launched with nohup

[Klaus Crusius]

Hi,

when your session is terminated, all processes of the session, which do not ignore the SIGHUP (1) signal, will receive the signal.
You can check that with a test script you start in the background, containing the line

trap 'echo "$(date): received SIGHUP" >>/tmp/xxx' SIGHUP

When you send the signal (#kill SIGHUP pid) to the process, and also when the session ends, should create output in /tmp/xxx.

Regards, Klaus