Bug 165582

Summary:	Login hangs on NFS problems
Product:	Red Hat Enterprise Linux 3	Reporter:	Alexander Spanke <aspanke>
Component:	util-linux	Assignee:	Karel Zak <kzak>
Status:	CLOSED NOTABUG	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-08-29 10:53:13 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexander Spanke 2005-08-10 16:24:17 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Description of problem:
A cluster of 230+ nodes is sharing /usr/local/bin as a NFS share and this 
sharing of /usr/local/bin via NFS is mandatory. If we encounter NFS problems, 
login to the nodes for further analyses is not possible anymore out of the cause of the hardwired PATH=/usr/local/bin;/usr/local/sbin;... within the /bin/login binary.



Version-Release number of selected component (if applicable):
util-linux-2.11y-31.2

How reproducible:
Always

Steps to Reproduce:
1. Mount a NFS share under /usr/local/bin
2. Interrupt the NFS connection, i.e. stop the NFS server
3. Try to login to the Client host
  

Actual Results:  The login is hanging until the NFS share is back again ...

Expected Results:  We expect to be able to login to a system with NFS problems to start with investigations ...

Additional info:

Comment 1 Karel Zak 2005-08-29 08:37:30 UTC

Do you use mingetty as console tty handler? (See /etc/inittab). Are you sure
that you don't have anything important on NFS mount point? For example some
parts of PAM, log files, shells, things from shell profile or rc files or so.

Comment 2 Alexander Spanke 2005-08-29 09:05:56 UTC

(In reply to comment #1)
> Do you use mingetty as console tty handler? (See /etc/inittab). Are you sure
> that you don't have anything important on NFS mount point? For example some
> parts of PAM, log files, shells, things from shell profile or rc files or so.

With the mingetty, I will check ...
Regarding the important parts on NFS shares, we are working with a NFS share 
mounted under /usr/local/bin; there we only have our own scripts and 
applications, but during the login process, /usr/local/bin will be specified at 
the first position  of $PATH,and every lokkup, for  example for the 'id' 
command within startup scripts, will  end in a hanging situation, because the 
system trys to looks it up firstly in /usr/local/bin which is the NFS share. So 
with broken NFS servers, we are not even able tologin to the clients...

Comment 3 Karel Zak 2005-08-29 09:58:03 UTC

Yes, it's exactly what I've expected. You can try NFS mount with 'soft' option
instead 'hard' -- it will cause I/O error instead waiting on NFS. For details
see "man nfs". You can also change your PATH setting.

I think there it no bug. Your system only follows your settings :-)

Comment 4 Alexander Spanke 2005-08-29 10:03:43 UTC

Hi,

there is our problem, out of the applications enviroment, we cannot use soft 
mounts, we already discussed this :( 
For the path setup, we just changed it and removed the /usr/local/bin from the 
$PATH completely, but I didn't understand why /bin/login specified it directly 
in the beginning instead of adding /usr/local/... to the end, that's why I 
submitted this bug report.

Comment 5 Karel Zak 2005-08-29 10:34:08 UTC

It allows users to use their own programs from /usr/local/bin instead system
default things. I'm sure that we don't want to change it.

You can try define your own PATH on begin of /etc/profile.

Comment 6 Alexander Spanke 2005-08-29 10:53:13 UTC

Oh, that's the reason, I thought using the system binaries should be first ...

I will close the bug now, as it is not a bug at all;)

Thanks a lot for your help !!