can not get back the terminal prompt

[jane zhang]

Hi all,

I recently move several users' home dir to from an HP 10.20 box to an HP 11.00 box and found out the strange thing.

Users can login from any hpux machines in our NIS domain but can not get the terminal prompt without a "ctrl + c".

User can login from any sun solaris machines without this problem.

We are using NIS/NFS/Automomt for user's home file system.

Thanks,
Jane

[Patrick Wallek]

It sounds as if some startup script is waiting on something. Are all needed resources available? Did you change the automount maps to point to the new HP-UX 11 box? Are permissions correct? When the users do a CTRL+C do they wind up in their home dir or somewhere else?

[jane zhang]

Patrick,

Yes, I have changed NIS/passwd file entries and pushed to all the slave server.

In our NIS domain, all the file server's homes has been exported and available to the nodes in netgroup.

I checked everywhere and all the scripts are available. I even made a .profile in one user's home dir, it first execute /etc/profile and then the user's .profile, after this, it stopped until I press CTRL-C to get the prompt back. Typing pwd and the user's home showed the new location. I chose another Sun solaris to login, everything is fine.

[Steven E. Protter]

If you run through /etc/profile an .profile line by line you should find the problem.

Don't do it as root, do it as the user. Perhaps but some echo statements in the .profile to track down where you hang.

SEP

[Bill Hassell]

Add this to the beginning of /etc/profile:

set -x

This will trace each step of the login profile. If the hang occurs after /etc/profile, it is likely in the user's .profile (this assumes standard POSIX shell /usr/bin/sh)

[jane zhang]

Hi all,

Added set -x in the begining of /etc/profile as well as $HOME/.profile, It just stopped after sourcing .profile and hang.

I renamed /etc/profile and $HOME/.profile so when I open the terminal console, those profile will not be sourced.

However when I echo $PATH. It is very long PATH with some applications executible there.

When and where this is set up in the $PATH

[Bill Hassell · Accepted solution]

Since the problem seems to be in .profile, I would move /etc/profile back to normal. A working version of both /etc/profile and .profile are both located in /usr/newconfig. If you are using NFS for $HOME and you have defined the HISTFILE variable to something like:

export HISTFILE=$HOME/.sh_history

then that is probably the problem. The shell history file requires file locking that is problematic in NFS. Change the HISTFILE value to a local filesystem such as: export HISTFILE=/var/tmp/$LOGNAME.sh.history

PATH is set by /etc/profile by reading the file: /etc/PATH

[jane zhang]

Bill,

Thanks for solving my problem, now that I added .profile to those user's home dir with the line:
export HISTFILE=/var/tmp/$LOGNAME.sh.history

I also add one more file .Xdefault so it can be sourced.

One thing still puzzled me is that the usr's HISTFILE is defind in a startup script sourced in /etc/profile
# HISTFILE
set -o vi
export HISTFILE=~/.sh_history${os}
So after I moved user's file to the new loc I also changed the account to point to the new loc. "~" should be able to point to the new loc. Why this is not working as it should be?

Your solution is working but the users' history files spreads all over the machines she/She login in our NIS instead of his/her home. Do you think we can improve this?

Thanks
Jane

[Bill Hassell]

The problem is with NFS file locking. The shell must handle the possibility of multiple logins of the same user, all typing commands at the same time. To prevent these shells from clobbering the shell history file (which contains some imbedded binary pointers), the shell uses record locking and NFS has big problems with rpc.lockd and rpc.statd in making this work correctly. If you are also using automounter, the problem is compounded.

Start by adding: LOCKD_OPTIONS="-p 4045" to the etc/rc.config.d/nfsconf, and MOST important, add ALL the latest NFS patches to boyh server and client. NFS is not nearly as stable as a local filesystem and if patching is not an option, you'll have to live with the local shell histories scattered around on all the systems.