NIS account is unable to login using ksh shell.

[venkatakrishna]

Hi,
My system is a NIS client.
NIS account with /bin/csh shell are able to login, but NIS account with /bin/ksh shell are not able to login. No error are seen in syslog.log file.
Local user with /bin/ksh shell are able to login.
/etc/shells file exists with proper shell entries.

Please help.

[Steven E. Protter]

Shalom,

Somewhere there must be a problem.

On the NIS master, check the shell entry and make sure it points to a valid shell on the system being logged into.

Check permissions (local) on the system of the shell itself. If its invisible to the user then it can cause this problem.

If the screen is showing an error message, please post it to the thread.

SEP

[blah2blah]

i think ksh likes to put a lock on some files that are in the users home directory.

being your using nis, maybe your using nfs for the users home directories.

so check that the stat and lock daemons are running

[F Verschuren]

ad the shell to /etc/shells

if the file does not exist create one
example:
/sbin/sh
/usr/bin/sh
/usr/bin/rsh
/usr/bin/ksh
/usr/bin/rksh
/usr/bin/csh
/usr/bin/keysh
#
/bin/sh
/bin/rsh
/bin/ksh
/bin/rksh
/bin/csh
/bin/keysh
/usr/bin/false
#
/usr/local/bin/zsh
/usr/local/bin/rzsh
/usr/local/bin/ftponly

[F Verschuren]

sorry dint reat the question corect, is there a error in /var/adm/syslog/syslog.log then the user tryes to login?

[Dave Olker]

What is the exact symptom here?

Does the login fail with an error message? Does the login attempt hang? Is the user kicked off immediately?

Are the home directories NFS mounted? If so, does the same problem occur for users with home directories in local filesystems?

Regards,

Dave

[venkatakrishna]

HI,
Thanks for the reply..
1. Following info available in /etc/shells file.
/bin/csh
/bin/ksh
/sbin/sh
/usr/bin/sh
/usr/bin/rsh
/usr/bin/ksh
/usr/bin/rksh
/usr/bin/csh
/usr/bin/keysh
#
/bin/sh
/bin/rsh
/bin/ksh
/bin/rksh
/bin/csh
/bin/keysh
/usr/bin/false
#
/usr/local/bin/zsh
/usr/local/bin/rzsh
/usr/local/bin/ftponly

2. User login hangs, after running /etc/profile and ~/.profile files.

3. User home directory is mounted, but does not get shell prompt.

4. Local user with /bin/ksh shell is able to login successfully.

5. No errors found in /var/adm/syslog/syslog.log.

Please suggest.

Krishna.

[Robert-Jan Goossens · Accepted solution]

Hi,

Try changing the .sh_history file location in the user home .profile to /tmp/.sh_history and try to login again.

Robert-Jan

[Venkatesh BL]

Do the user get the login prompt when he does a 'Ctrl+c' during the hang after login?

[Dave Olker]

Please clarify whether the user's home directories on the hanging login are NFS mounted. If they are then this is the classic Ksh lock hang problem and it indicates your NFS client is unable to successfully lock files on the server.

99% of these NFS file lock issues are configuration related (i.e. the server can't resolve the client's IP address properly, resolves the wrong address, etc.).

Robert-Jan Goossens has already given you the "workaround" for this problem, which is to redirect the HISTFILE environment variable in these users' .profiles to point to a local filesystem. This doesn't resolve the underlying issue of the client not being able to lock files on the NFS filesystem, but it will allow these users to log in without hanging.

If you're interested in actually fixing the problem, rather than just working around it, there is data you can collect to determine the underlying cause.

Regards,

Dave

[venkatakrishna]

Thanks Robert-Jan and Dave for providing solution.
Yes Dave, i would like to get into root cause of this problem. Please let me know what type of data i have to collect.

Thanks
Krishna.

[Dave Olker]

Hi Krishna,

The best data to collect is a debug rpc.lockd and rpc.statd log file from both NFS client and server as well as a network trace taken on the client and the server.

Are both systems running HP-UX? If so, what version?

If both systems are running HP-UX, the way to turn on debug rpc.lockd/statd logging is to send the running daemons a SIGUSR2. This trick should work on any HP-UX system running 11.0, 11.11 or 11.23 (11.31 the procedure is different)

# kill -17 $(ps -e | grep -E 'rpc.statd|rpc.lockd' | awk '{print $1}')

This will toggle debug logging to the /var/adm/rpc.lockd.log and /var/adm/rpc.statd.log files. Reproduce the lock hang while logging is running and then use the same kill command to toggle the debug logging off.

We can start with the debug logfiles first and if they don't tell us what we need to know we can collect the network traces.

If you're running 11.31 (i.e. 11i v3) let me know and I can tell you how to collect the debug logging for that system.

Regards,

Dave