ctl+d or exit not exiting the session

[sreedhar2u]

Hi,

I am facing an issue in logout of the HP-UX (11.23) session. If I press ctl+d or run exit command, the login session is not completely terminated. it just hangs and the I need to close the putty session by clickeing on close(X) button. This is leaving the a session on the server. This is happening if I login with NIS user and the same is not happening if I login as local user or root user of the server.

Please assist in resolving the issue.

Regards,

[merieux]

Hi ,

When you use a nis account , what is the home directory of the user ? Is it a local directory ? Is it a remote directory ? How is used nis , only for account authentication ? Or also for use as home server ?

If it's use only for authentication , there is not reason that the log off is different from the login session ( i m not sure of my english :-) )

Probably nis allow you to access to a remote home server . In this case i guess when you log off your home is yet mounted . That could be explain why the process is hang .

Do you have some mesage in syslog about automunt or mount ?

Regards ,

[Laurent Menase]

I suppose your nis users have nfs mounted home dir.

Now, you probably need to look at mount command result, or dmesg

you may need to take a nettl trace.

[Bill Hassell]

Before you exit, type the command:

trap

If you see something like this:

trap -- '' QUIT
trap -- '' INT
trap -- '' HUP

then the trap statement at the end of /etc/profile is missing. It should read:

trap 1 2 3

Otherwise, you'll need to take a nettl (or Wireshark/Winpcap) trace of the logoff activity.

[TwoProc]

I suspect that something is being run as a background job during your session that is not being redirected elsewhere, so that when you exit, the fact that stdio and possibily stdin and stderr are still being used on your terminal is holding you up.

Review your jobs, etc, and make sure that anything left running in the background, or even stopped in the background is either finished before you attempt to exit, OR that those things left running have their input, outputs and error outputs well defined, specifically not defaulting the current login session.

suppose you put a job in the background from your terminal session.

myjob &

myjob is set to read from stdin, output to stdout, and push errors to stderr - even if in side of that command, you've already redirected those io areas. Because the io of the outer command itself, isn't redirected you would still need to redirect this.

a preferred way would be:

nohup myjob < infile > outfile 2>&1 &

Note: in the above outfile can be /dev/null
Note: infile can certainly be an empty file,
or a file with just a linefeed in it, if you think the command needs it.
Note: if you leave off nohup, then the job will terminate as soon as you logoff, or at least, it should.

Lastly, keep in mind even if it's not a command you've run yourself from the command line, it could be a script that is in your .profile, .kshrc, .cshrc, or any script that can set up your environment, if they aren't well done. I've seen this in the case where environment vars and subshells spin up based on your machine name, user name, group name, date, data base running on the machine, etc. and a series of shells call subshells that call subshells, etc.

[Dennis Handly]

>TwoProc: I suspect that something is being run as a background job during your session

You can look for those with:
UNIX95=EXTENDED_PS ps -H -fu $LOGNAME

The only complication is the above command gives an hierarchical dump for each process tree, if you have logged on more than once.