[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

Title:USG buildhelp questions/answers
Moderator:SMURF::FILTER
Created:Mon Apr 26 1993
Last Modified:Mon Jan 20 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2763
Total number of notes:5802

1291.0. "sandboxes and intermittant machine access" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Thu Feb 23 1995 14:34

Date Of Receipt: 	23-FEB-1995 14:07:05.20
From: 	SMURF::FLAMBE::"[email protected]" "23-Feb-1995 1405"
To: 	[email protected]
CC: 	
Subj: 	sandboxes and intermittant machine access

I have a number of sandboxes and one of them resides on a test machine.
This test machine is not always up and this is causing me a problem.
When the test machine is down, I cannot do a "workon" or even a "build"
if I have a "workon" shell already started.  I could understand this if
I was trying to access the sandbox on the test machine, but I am not.
I have the problem even when I attempt to access a local sandbox.  Even
if I comment out all references to the sandbox on the remote machine in
my .sandboxrc.  Why is this?  Is there something I can do about it?
Do I need to hide the test sandbox behind links and then change the link
when the test machine is unavailable?

Mike Schloss
T.RTitleUserPersonal
Name		DateLines
1291.1Re: sandboxes and intermittant machine accessAOSG::FILTERAutomatic Posting Software - mail to flume::puckThu Feb 23 1995 19:5767
Date Of Receipt: 	23-FEB-1995 18:53:48.94
From: 	SMURF::FLAMBE::"[email protected]" "Joshua M. Friedman OSF/UNIX SDE"
To: 	[email protected], [email protected]
CC: 	
Subj: 	Re:  sandboxes and intermittant machine access

Mike, if your test sandbox is not your default sandbox (listed at 
the top of ~/.sandboxrc) then that removes any ODE dependency.

There can be an NFS dependency which can cause hangs if your test
sandbox is NFS mounted in the same directory as your other sb's.  You
can have different sandboxes in totally different directories and
filesystems; if your not doing this, then change the test sandbox to
mount at a different location, and have a special .sandboxrc entry for
it, like the following.  You'll have to fix the variable definition of
sandbox_base in the file test/rc_files/shared, accordingly.

If this doesn't address the problem, there's something else going on.
(Please continue to mail to odehelp, not me; I'll be unavailable for a
week.)

-josh

sample ~/.sandboxrc file:
------------------------------------
	# default sandbox
default something_other_than_test

base test /special-mnt-path 	<====== for your test sandbox only
base * /home/schloss/sb      	<====== for your default sandboxes

sb test
sb something_other_than_test
sb etc
------------------------------------

> From [email protected]  Thu Feb 23 14:05:52 1995
> Delivery-Date: Thu, 23 Feb 95 14:05:56 -0500
> Return-Path: [email protected]
> Received: from decvax.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM)
> 	id AA14538; Thu, 23 Feb 1995 14:05:52 -0500
> Received: from mhs.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92)
> 	id AA27179; Thu, 23 Feb 1995 14:05:16 -0500
> Received: from localhost by mhs.zk3.dec.com; (5.65/1.1.8.2/21Feb95-0638PM)
> 	id AA11257; Thu, 23 Feb 1995 14:05:13 -0500
> Message-Id: <[email protected]>
> To: [email protected]
> Subject: sandboxes and intermittant machine access
> Date: Thu, 23 Feb 95 14:05:12 -0500
> From: [email protected]
> X-Mts: smtp
> 
> I have a number of sandboxes and one of them resides on a test machine.
> This test machine is not always up and this is causing me a problem.
> When the test machine is down, I cannot do a "workon" or even a "build"
> if I have a "workon" shell already started.  I could understand this if
> I was trying to access the sandbox on the test machine, but I am not.
> I have the problem even when I attempt to access a local sandbox.  Even
> if I comment out all references to the sandbox on the remote machine in
> my .sandboxrc.  Why is this?  Is there something I can do about it?
> Do I need to hide the test sandbox behind links and then change the link
> when the test machine is unavailable?
> 
> Mike Schloss
> 
>
1291.2Re: sandboxes and intermittant machine accessAOSG::FILTERAutomatic Posting Software - mail to flume::puckFri Feb 24 1995 12:2190
Date Of Receipt: 	24-FEB-1995 11:17:33.08
From: 	SMURF::FLUME::schloss "Mike Schloss usg  24-Feb-1995 1116"
To: 	odehelp@DEC:.zko.flume
CC: 	
Subj: 	Re: sandboxes and intermittant machine access

> Mike, if your test sandbox is not your default sandbox (listed at 
> the top of ~/.sandboxrc) then that removes any ODE dependency.

My test sandbox is NOT my default sandbox

> There can be an NFS dependency which can cause hangs if your test
> sandbox is NFS mounted in the same directory as your other sb's.  You
> can have different sandboxes in totally different directories and
> filesystems; if your not doing this, then change the test sandbox to
> mount at a different location, and have a special .sandboxrc entry for
> it, like the following.  You'll have to fix the variable definition of
> sandbox_base in the file test/rc_files/shared, accordingly.
> 
> If this doesn't address the problem, there's something else going on.
> (Please continue to mail to odehelp, not me; I'll be unavailable for a
> week.)
> -josh

Something else must be going on.  Here is my .sandboxrc :

        # sandbox rc file created by mksb

        # default sandbox
default sb

        # base directories to sandboxes
base sb_tmp /net/shm/mike/schloss
base * /work

        # list of sandboxes
sb sb_tmp
sb sbx
sb sb

        # mksb config specific
mksb -dir /work
mksb -tools b
mksb -obj b /
mksb -src b /

> sample ~/.sandboxrc file:
> ------------------------------------
> 	# default sandbox
> default something_other_than_test
> 
> base test /special-mnt-path 	<====== for your test sandbox only
> base * /home/schloss/sb      	<====== for your default sandboxes
> 
> sb test
> sb something_other_than_test
> sb etc
> ------------------------------------
> 
>> From [email protected]  Thu Feb 23 14:05:52 1995
>> Delivery-Date: Thu, 23 Feb 95 14:05:56 -0500
>> Return-Path: [email protected]
>> Received: from decvax.zk3.dec.com by flambe.zk3.dec.com; 
(5.65/1.1.8.2/30Mar94-0502PM)
>> 	id AA14538; Thu, 23 Feb 1995 14:05:52 -0500
>> Received: from mhs.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92)
>> 	id AA27179; Thu, 23 Feb 1995 14:05:16 -0500
>> Received: from localhost by mhs.zk3.dec.com; (5.65/1.1.8.2/21Feb95-0638PM)
>> 	id AA11257; Thu, 23 Feb 1995 14:05:13 -0500
>> Message-Id: <[email protected]>
>> To: [email protected]
>> Subject: sandboxes and intermittant machine access
>> Date: Thu, 23 Feb 95 14:05:12 -0500
>> From: [email protected]
>> X-Mts: smtp
>> 
>> I have a number of sandboxes and one of them resides on a test machine.
>> This test machine is not always up and this is causing me a problem.
>> When the test machine is down, I cannot do a "workon" or even a "build"
>> if I have a "workon" shell already started.  I could understand this if
>> I was trying to access the sandbox on the test machine, but I am not.
>> I have the problem even when I attempt to access a local sandbox.  Even
>> if I comment out all references to the sandbox on the remote machine in
>> my .sandboxrc.  Why is this?  Is there something I can do about it?
>> Do I need to hide the test sandbox behind links and then change the link
>> when the test machine is unavailable?
>> 
>> Mike Schloss
1291.3Re: sandboxes and intermittant machine accessAOSG::FILTERAutomatic Posting Software - mail to flume::puckFri Feb 24 1995 15:38124
Date Of Receipt: 	24-FEB-1995 14:48:27.22
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	odehelp schloss
CC: 	
Subj: 	Re: sandboxes and intermittant machine access

This does not sound like an ODE-"proper" problem, but a network and/or
NFS related problem.

Can you provide more information about what happens (or doesn't) when
you say:
  > I cannot do a "workon" or even a "build"

Thanks.   p.s.  I won't be available to help with this problem next week;
either DECwest or ZK ODE or ZK network/admin should help out here.

-josh

	From schloss  Fri Feb 24 11:16:24 1995
	Delivery-Date: Fri, 24 Feb 95 11:16:58 -0500
	Return-Path: schloss
	Received: from mhs.zk3.dec.com by flume.zk3.dec.com; (5.65/1.1.8.2/16Jan95-0946AM)
		id AA09349; Fri, 24 Feb 1995 11:16:24 -0500
	Received: from localhost by mhs.zk3.dec.com; (5.65/1.1.8.2/23Feb95-0329PM)
		id AA20601; Fri, 24 Feb 1995 11:16:22 -0500
	Message-Id: <[email protected]>
	X-Mailer: exmh version 1.5.3 12/28/94
	To: odehelp
	Subject: Re: sandboxes and intermittant machine access 
	In-Reply-To: Your message of "Thu, 23 Feb 95 18:52:06 EST."
	             <[email protected]> 
	Mime-Version: 1.0
	Content-Type: text/plain; charset="us-ascii"
	Date: Fri, 24 Feb 95 11:16:22 -0500
	From: schloss
	X-Mts: smtp
	
	
	> Mike, if your test sandbox is not your default sandbox (listed at 
	> the top of ~/.sandboxrc) then that removes any ODE dependency.
	
	My test sandbox is NOT my default sandbox
	
	> There can be an NFS dependency which can cause hangs if your test
	> sandbox is NFS mounted in the same directory as your other sb's.  You
	> can have different sandboxes in totally different directories and
	> filesystems; if your not doing this, then change the test sandbox to
	> mount at a different location, and have a special .sandboxrc entry for
	> it, like the following.  You'll have to fix the variable definition of
	> sandbox_base in the file test/rc_files/shared, accordingly.
	> 
	> If this doesn't address the problem, there's something else going on.
	> (Please continue to mail to odehelp, not me; I'll be unavailable for a
	> week.)
	> -josh
	
	Something else must be going on.  Here is my .sandboxrc :
	
	        # sandbox rc file created by mksb
	
	        # default sandbox
	default sb
	
	        # base directories to sandboxes
	base sb_tmp /net/shm/mike/schloss
	base * /work
	
	        # list of sandboxes
	sb sb_tmp
	sb sbx
	sb sb
	
	        # mksb config specific
	mksb -dir /work
	mksb -tools b
	mksb -obj b /
	mksb -src b /
	
	> sample ~/.sandboxrc file:
	> ------------------------------------
	> 	# default sandbox
	> default something_other_than_test
	> 
	> base test /special-mnt-path 	<====== for your test sandbox only
	> base * /home/schloss/sb      	<====== for your default sandboxes
	> 
	> sb test
	> sb something_other_than_test
	> sb etc
	> ------------------------------------
	> 
	>> From [email protected]  Thu Feb 23 14:05:52 1995
	>> Delivery-Date: Thu, 23 Feb 95 14:05:56 -0500
	>> Return-Path: [email protected]
	>> Received: from decvax.zk3.dec.com by flambe.zk3.dec.com; 
	(5.65/1.1.8.2/30Mar94-0502PM)
	>> 	id AA14538; Thu, 23 Feb 1995 14:05:52 -0500
	>> Received: from mhs.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92)
	>> 	id AA27179; Thu, 23 Feb 1995 14:05:16 -0500
	>> Received: from localhost by mhs.zk3.dec.com; (5.65/1.1.8.2/21Feb95-0638PM)
	>> 	id AA11257; Thu, 23 Feb 1995 14:05:13 -0500
	>> Message-Id: <[email protected]>
	>> To: [email protected]
	>> Subject: sandboxes and intermittant machine access
	>> Date: Thu, 23 Feb 95 14:05:12 -0500
	>> From: [email protected]
	>> X-Mts: smtp
	>> 
	>> I have a number of sandboxes and one of them resides on a test machine.
	>> This test machine is not always up and this is causing me a problem.
	>> When the test machine is down, I cannot do a "workon" or even a "build"
	>> if I have a "workon" shell already started.  I could understand this if
	>> I was trying to access the sandbox on the test machine, but I am not.
	>> I have the problem even when I attempt to access a local sandbox.  Even
	>> if I comment out all references to the sandbox on the remote machine in
	>> my .sandboxrc.  Why is this?  Is there something I can do about it?
	>> Do I need to hide the test sandbox behind links and then change the link
	>> when the test machine is unavailable?
	>> 
	>> Mike Schloss
1291.4Re: sandboxes and intermittant machine accessAOSG::FILTERAutomatic Posting Software - mail to flume::puckFri Feb 24 1995 15:49151
Date Of Receipt: 	24-FEB-1995 15:26:58.52
From: 	SMURF::WASTED::schloss "Mike Schloss usg  24-Feb-1995 1524"
To: 	Joshua M. Friedman OSF/UNIX SDE <jmf@DEC:.zko.wasted>
CC: 	odehelp@DEC:.zko.wasted
Subj: 	Re: sandboxes and intermittant machine access

> This does not sound like an ODE-"proper" problem, but a network and/or
> NFS related problem.
> 
> Can you provide more information about what happens (or doesn't) when
> you say:
>   > I cannot do a "workon" or even a "build"

Sorry about that.  The problem is that there is an NFS message followed by
a hang.

mhs (12:47pm) build
NFS3 server shm not responding still trying
[ HANG UNTIL TEST MACHINE IS BOOTED ]

This problem has also occured when the test machine was taken down in the
middle of a build.  And no, my PATH nor my CWD go through anything on SHM.

Mike

> Thanks.   p.s.  I won't be available to help with this problem next week;
> either DECwest or ZK ODE or ZK network/admin should help out here.
> 
> -josh
> 
> 	From schloss  Fri Feb 24 11:16:24 1995
> 	Delivery-Date: Fri, 24 Feb 95 11:16:58 -0500
> 	Return-Path: schloss
> 	Received: from mhs.zk3.dec.com by flume.zk3.dec.com; (5.65/1.1.8.2/16Ja
>n95-0946AM)
> 		id AA09349; Fri, 24 Feb 1995 11:16:24 -0500
> 	Received: from localhost by mhs.zk3.dec.com; (5.65/1.1.8.2/23Feb95-0329
>PM)
> 		id AA20601; Fri, 24 Feb 1995 11:16:22 -0500
> 	Message-Id: <[email protected]>
> 	X-Mailer: exmh version 1.5.3 12/28/94
> 	To: odehelp
> 	Subject: Re: sandboxes and intermittant machine access 
> 	In-Reply-To: Your message of "Thu, 23 Feb 95 18:52:06 EST."
> 	             <[email protected]> 
> 	Mime-Version: 1.0
> 	Content-Type: text/plain; charset="us-ascii"
> 	Date: Fri, 24 Feb 95 11:16:22 -0500
> 	From: schloss
> 	X-Mts: smtp
> 	
> 	
> 	> Mike, if your test sandbox is not your default sandbox (listed at 
> 	> the top of ~/.sandboxrc) then that removes any ODE dependency.
> 	
> 	My test sandbox is NOT my default sandbox
> 	
> 	> There can be an NFS dependency which can cause hangs if your test
> 	> sandbox is NFS mounted in the same directory as your other sb's.  You
> 	> can have different sandboxes in totally different directories and
> 	> filesystems; if your not doing this, then change the test sandbox to
> 	> mount at a different location, and have a special .sandboxrc entry fo
>r
> 	> it, like the following.  You'll have to fix the variable definition o
>f
> 	> sandbox_base in the file test/rc_files/shared, accordingly.
> 	> 
> 	> If this doesn't address the problem, there's something else going on.
> 	> (Please continue to mail to odehelp, not me; I'll be unavailable for 
>a
> 	> week.)
> 	> -josh
> 	
> 	Something else must be going on.  Here is my .sandboxrc :
> 	
> 	        # sandbox rc file created by mksb
> 	
> 	        # default sandbox
> 	default sb
> 	
> 	        # base directories to sandboxes
> 	base sb_tmp /net/shm/mike/schloss
> 	base * /work
> 	
> 	        # list of sandboxes
> 	sb sb_tmp
> 	sb sbx
> 	sb sb
> 	
> 	        # mksb config specific
> 	mksb -dir /work
> 	mksb -tools b
> 	mksb -obj b /
> 	mksb -src b /
> 	
> 	> sample ~/.sandboxrc file:
> 	> ------------------------------------
> 	> 	# default sandbox
> 	> default something_other_than_test
> 	> 
> 	> base test /special-mnt-path 	<====== for your test sandbox only
> 	> base * /home/schloss/sb      	<====== for your default sandboxes
> 	> 
> 	> sb test
> 	> sb something_other_than_test
> 	> sb etc
> 	> ------------------------------------
> 	> 
> 	>> From [email protected]  Thu Feb 23 14:05:52 1995
> 	>> Delivery-Date: Thu, 23 Feb 95 14:05:56 -0500
> 	>> Return-Path: [email protected]
> 	>> Received: from decvax.zk3.dec.com by flambe.zk3.dec.com; 
> 	(5.65/1.1.8.2/30Mar94-0502PM)
> 	>> 	id AA14538; Thu, 23 Feb 1995 14:05:52 -0500
> 	>> Received: from mhs.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/
>19/92)
> 	>> 	id AA27179; Thu, 23 Feb 1995 14:05:16 -0500
> 	>> Received: from localhost by mhs.zk3.dec.com; (5.65/1.1.8.2/21Feb95-0
>638PM)
> 	>> 	id AA11257; Thu, 23 Feb 1995 14:05:13 -0500
> 	>> Message-Id: <[email protected]>
> 	>> To: [email protected]
> 	>> Subject: sandboxes and intermittant machine access
> 	>> Date: Thu, 23 Feb 95 14:05:12 -0500
> 	>> From: [email protected]
> 	>> X-Mts: smtp
> 	>> 
> 	>> I have a number of sandboxes and one of them resides on a test machi
>ne.
> 	>> This test machine is not always up and this is causing me a problem.
> 	>> When the test machine is down, I cannot do a "workon" or even a "bui
>ld"
> 	>> if I have a "workon" shell already started.  I could understand this
> if
> 	>> I was trying to access the sandbox on the test machine, but I am not
>.
> 	>> I have the problem even when I attempt to access a local sandbox.  E
>ven
> 	>> if I comment out all references to the sandbox on the remote machine
> in
> 	>> my .sandboxrc.  Why is this?  Is there something I can do about it?
> 	>> Do I need to hide the test sandbox behind links and then change the 
>link
> 	>> when the test machine is unavailable?
> 	>> 
> 	>> Mike Schloss
> 	
> 	
>
1291.5Re: sandboxes and intermittant machine accessAOSG::FILTERAutomatic Posting Software - mail to flume::puckFri Feb 24 1995 17:5711
Date Of Receipt: 	24-FEB-1995 17:33:07.26
From: 	SMURF::WASTED::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	schloss@DEC:.zko.wasted
CC: 	odehelp@DEC:.zko.wasted
Subj: 	Re: sandboxes and intermittant machine access

You might check to see you have uninterruptible hard mounts - if so, change
to interruptible soft mounts (?) -- I dunno - NFS experts would know more.

-josh
1291.6Re: sandboxes and intermittant machine accessAOSG::FILTERAutomatic Posting Software - mail to flume::puckFri Feb 24 1995 17:5822
Date Of Receipt: 	24-FEB-1995 17:44:14.74
From: 	SMURF::FLUME::schloss "Mike Schloss usg  24-Feb-1995 1743"
To: 	Joshua M. Friedman OSF/UNIX SDE <jmf@DEC:.zko.flume>
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re: sandboxes and intermittant machine access

> You might check to see you have uninterruptible hard mounts - if so, change
> to interruptible soft mounts (?) -- I dunno - NFS experts would know more.

I use the sutomounter so I have no idea what type of mount it is.

The problem seems to me more basic.  Why is NFS getting involved at all?
The sandbox I am trying to access is local.  The remote node in question
does not appear in my PATH.  No other command that I use causes this problem.
Deleting all references to the remote node (and sandbox) from my .sandboxrc
does not make the problem go away.  Issuing a bogus command name from a
shell without command hashing still doesn't casue the problem so where the
command resides in the search path doesn't matter.  Is there some data
that ode squirrels away somewhere as a cache?  Where do I go from here?

Mike