[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

2556.0. "A: There is a problem with sup of ptaqa pool" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Sep 10 1996 19:03

Date Of Receipt: 	10-SEP-1996 17:51:52.15
From: 	ALPHA::aaron "Aaron Sawyer USG  10-Sep-1996 1748"
To: 	rll@DEC:.zko.alpha, odehelp@DEC:.zko.alpha
CC: 	lpr@DEC:.zko.alpha, aaron@DEC:.zko.alpha
Subj: 	A: There is a problem with sup of ptaqa pool

Hi, Rich, et. al.,

It would appear that the UNX ptaqa pool is out-of-sync w/r/t
the ZK3 ptaqa pool, especially the permissions on files that
Lynda Rice had requested be changed in the RCS pool and in the
ptaqa backing tree.  The original request & its file list are
'way below at the end of this message.

Does sup propagate a permissions change on a file when there
is no change to the file's content?  It would appear that 'no'
is the answer right now.

Short term:  Rich, you'll have to update the permissions in
the UNX ptaqa tree.

Long term:  a QAR should be entered against sup to have it
propagate permissions (& owner/group) changes on files.
odehelp, will you do this?

Thanks,
=Aaron

------- Forwarded Messages
From: Lynda Rice <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: Fixes needed for dxshutdown testsuite in ptaqa pool 
In-Reply-To: Your message of "Tue, 10 Sep 96 17:17:45 EDT."
             <[email protected]> 
Date: Tue, 10 Sep 96 17:25:56 -0400

Aaron,

It does look like a sup problem, based upon your feedback and what I am
seeing:

$ pwd
/usr/sde/osf1/build/ptaqa/src/test/SysMan/bin/int
$
$ df -k /usr/sde/osf1/build/ptaqa/src/test/SysMan/bin/int
Filesystem                1024-blocks        Used   Available Capacity  Mounted on
odie:/usr/sde/disks/disk2    10275840     8089917     1829888    82%    /usr/sde/disks/disk2
$

						Lynda

------- Forwarded Message 2
Message-Id: <[email protected]>
To: Lynda Rice <[email protected]>
Cc: [email protected]
Subject: Re: Fixes needed for dxshutdown testsuite in ptaqa pool 
In-Reply-To: Your message of "Tue, 10 Sep 96 17:08:10 EDT."
             <[email protected]> 
Date: Tue, 10 Sep 96 17:17:45 -0400
From: "One page shy of a working set" <[email protected]>

Lynda,

I suspect that there is a sup problem.  I looked at the ptaqa pool from my node
pram (which runs automount) and from alpha (the production server for pram's
subnet).  Here's what I see on alpha:

alpha% ls -lsiAF /usr/sde/osf1/build/ptaqa/src/test/SysMan/bin/int
total 10
600626 2 -r-xr-xr-x   1 devbld   staff       1674 Aug 29 16:33 init.ksh*
600624 5 -r-xr-xr-x   1 devbld   staff       4197 Aug 29 16:33 playback.ksh*
600625 3 -r-xr-xr-x   1 devbld   staff       2395 Aug 29 16:33 summarize.ksh*
alpha% 

alpha% df -k /usr/sde/osf1/build/ptaqa/src/test/SysMan/bin/int
Filesystem                               1024-blocks        Used   Available 
Capacity  Mounted on
fsecret:/share/secret/build/submits.dsk3     6165720     4028999     1755776    
70%    /tmp_mnt/fsecret/share/secret/build/submits.dsk3
alpha% 

What do you see on your end (for df -k) ?

Thanks,
=Aaron

------- Forwarded Message 3
> 
> It appears to still be a problem, from tar's point of view.  I just repeated
> the steps in the mail below and got the same results.
> 
> If I bco -u one of the files that I had requested execute privileges be added
> to, the file is checked-out with the correct/expected privileges:
> 
> $ pwd
> /expander/sb/auto/src/test/SysMan/bin/int
> $
> $ bco -u init.ksh
> 
> [ ./test/SysMan/bin/int/init.ksh ]
> [ ./test/SysMan/bin/int/init.ksh Rev 1.1.2.2 checked out unlocked ]
> $
> $ ls
> total 6
> drwxr-xr-x   2 lpr      system       512 Sep 10 17:04 .
> drwxr-xr-x   4 lpr      system       512 Sep 10 16:54 ..
> -r-xr-xr-x   1 lpr      system      1674 Sep 10 17:04 init.ksh
> lrwxr-xr-x   1 lpr      system        61 Sep 10 17:02 playback.ksh -> /expander/
> sb/auto/link/src/test/SysMan/bin/int/./playback.ksh
> lrwxr-xr-x   1 lpr      system        62 Sep 10 17:02 summarize.ksh -> /expander
> /sb/auto/link/src/test/SysMan/bin/int/./summarize.ksh
> $
> 
> Unfortunately, this is not the total solution.  tar should be able to follow
> the sandbox links and pick-up the files with the correct permissions.
> 
> Here is what the ode ptaqa disk shows; note the incorrect/unexpected privileges: 
> 
> $ pwd
> /usr/sde/osf1/build/ptaqa/src/test/SysMan/bin/int
> $
> $ ls
> total 26
> drwxr-xr-x   2 devbld   staff       8192 Aug 29 16:33 .
> drwxr-xr-x   4 devbld   staff       8192 Aug 29 16:33 ..
> -r--r--r--   1 devbld   staff       1674 Aug 29 16:33 init.ksh
> -r--r--r--   1 devbld   staff       4197 Aug 29 16:33 playback.ksh
> -r-xr-xr-x   1 devbld   staff       2395 Aug 29 16:33 summarize.ksh
> 
> 
> 						Lynda
------- Forwarded Message 4
> Message-Id: <[email protected]>
> To: Lynda Rice <[email protected]>
> Cc: [email protected]
> Subject: Re: Fixes needed for dxshutdown testsuite in ptaqa pool 
> In-Reply-To: Your message of "Fri, 06 Sep 96 13:52:25 EDT."
>              <[email protected]> 
> Date: Tue, 10 Sep 96 16:39:43 -0400
> From: "One page shy of a working set" <[email protected]>
> 
> Hi, Lynda,
> 
> Um, is this still an issue for you?  We chose not to close PTAQA last
> Friday, because PTBQA was only available  ~2hrs before the scheduled
> close.  I will send mail to steel_test announcing that PTAQA _will_
> close on Friday 13sep1996 @2pm EDT.
> 
> [time passes....]
> I just reconstructed my ptaqa sandbox and looked in src/test/SysMan/bin/int .
> The links are present and have proper permissions.  I cd'd to 
> src/../link/src/test/SysMan/bin/int (in the ptaqa backing tree) and looked
> at the files there.  They have execute permissions.
> 
> It is possible your tarball construction overlapped the sup-from-ZKO and/or
> updating-ptaqa-backing-tree-from-rcs .   Beats me.   8-)
> 
> =Aaron
> 
> > 
> > >> Actually, the instructions are incomplete, when this is done, it needs
> > >> to be done both on the rcs files in qaqc as well as the files you've
> > >> listed.  Without the rcs changes these modes would be 'lost' as changes
> > >> are made to the files.
> > >> 
> > >> -josh
> > 
> > I'm not sure what happened, but I just:
> > 
> > 	1) removed all the links in my ptaqa sandbox from src/test/SysMan down.
> > 	2) did an exit workon, followed by a new workon to my ptaqa sandbox
> > 	3) did a mklinks from src/test/SysMan
> > 	4) created a tarball, forcing tar to follow symbolic links, of
> > 	   src/test/SysMan
> > 
> > When I untar'd the SysMan testsuites area, I noticed that the files that I
> > requested to have execute permissions added to (mimicking bcreate -modex)
> > do not have the execute permissions.  For example, in the bin/int below,
> > init.ksh and playback.ksh were bcreate'd without -modex, but summarize.ksh
> > had been bcreate'd with -modex.  
> > 
> > bin/int:
> > total 12
> > drwxr-xr-x   2 lpr      develop      512 Sep  6 13:32 .
> > drwxr-xr-x   4 lpr      develop      512 Sep  6 13:32 ..
> > -r--r--r--   1 lpr      develop     1674 Aug 29 16:33 init.ksh
> > -r--r--r--   1 lpr      develop     4197 Aug 29 16:33 playback.ksh
> > -r-xr-xr-x   1 lpr      develop     2395 Aug 29 16:33 summarize.ksh
> > 
> > In the sandbox, the above directory listing looks like:
> > 
> > bin/int:
> > total 4
> > drwxr-xr-x   2 lpr      system       512 Sep  6 13:32 .
> > drwxr-xr-x   4 lpr      system       512 Sep  6 13:32 ..
> > lrwxr-xr-x   1 lpr      system        57 Sep  6 13:32 init.ksh -> 
> /expander/sb/auto/link/src/test/SysMan/./bin/int/init.ksh
> > lrwxr-xr-x   1 lpr      system        61 Sep  6 13:32 playback.ksh -> 
> /expander/sb/auto/link/src/test/SysMan/./bin/int/playback.ksh
> > lrwxr-xr-x   1 lpr      system        62 Sep  6 13:32 summarize.ksh -> 
> /expander/sb/auto/link/src/test/SysMan/./bin/int/summarize.ksh
> > 
> > Indeed, the execute permissions have been set in the links, wherein before
> > Grant made the changes for init.ksh and playback.ksh they were not.
> > 
> > I included a snippet above from Josh's mail which eludes to RCS changes tha
t 
> are
> > needed.  Was this done?
> > 
> > The ptaqa pool is scheduled to close today.  Is there anyway to correct thi
s
> > before the pool closes?
> > 
> > Do we need another cast of millions to be involved in this?  I hope not.  I
f
> > so...here we go again 8-(
> > 
> > 						tx...Lynda
> > 
[snip]
| > - ------- Forwarded Message
| > From: Lynda Rice <[email protected]>
| > Date: Wed, 4 Sep 1996 15:30:39 -0400
| > To: [email protected]
| > Subject: Fixes needed for dxshutdown testsuite in ptaqa pool
| > Cc: [email protected]
| > 
| > The following files were (apparently) bcreate'd without the -modex option.  I
| > have exhaustively read the ODE manpages for a command that I could execute
| > to change the privileges, to no avail.  Can you please make the necessary ODE
| > changes to add global execute permissions to these files so that they are
| > marked executable in the pools and when checked-out?  Sorry for all the
| > mistakes...this was a 104 file create/submit of various types of files.
| > 
| > 						tx...Lynda
| > 
| > Assuming that $ptaqa = /usr/sde/osf1/build/ptaqa:
| > 
| > $ptaqa/src/test/SysMan/bin/int/init.ksh
| > $ptaqa/src/test/SysMan/bin/int/playback.ksh
| > 
| > $ptaqa/src/test/SysMan/dxshutdown/xth/cleanup
| > $ptaqa/src/test/SysMan/dxshutdown/xth/init
| > $ptaqa/src/test/SysMan/dxshutdown/xth/rptgen
| > $ptaqa/src/test/SysMan/dxshutdown/xth/testsuite
| > 
| > $ptaqa/src/test/SysMan/dxshutdown/tests/appResources/appResources.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/gui/gui.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/halt/halt.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/help/help.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/messageOnly/messageOnly.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/minAsserts/minAsserts.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/minAsserts/minAsserts1.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/minAsserts/minAsserts2.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/nonRoot/nonRoot.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/nowWarning/nowWarning.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/otherOptions/otherOptions.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/reboot/reboot.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script1.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script10.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script11.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script12.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script2.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script3.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script4.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script5.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script6.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script7.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script8.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/script/script9.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/shared/procs.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/singleUser/singleUser.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/timer/timer.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/userMessage/userMessage.tcl
| > $ptaqa/src/test/SysMan/dxshutdown/tests/userMessage/userMessage1.tcl
| > 
| > - ------- End of Forwarded Message
| > ------- End of Forwarded Message

------- End of Forwarded Messages


T.RTitleUserPersonal
Name
DateLines
2556.1Re: A: There is a problem with sup of ptaqa poolAOSG::FILTERAutomatic Posting Software - mail to flume::puckWed Sep 11 1996 11:0815
Date Of Receipt: 	11-SEP-1996 09:35:42.93
From: 	SEAN::davidson "D. Sean Davidson  11-Sep-1996 0933"
To: 	"One page shy of a working set" <sean::aaron>
CC: 	sean::rll, sean::odehelp, sean::lpr, sean::jmf
Subj: 	Re: A: There is a problem with sup of ptaqa pool

sup would have found these files if the '-c' option had been used.  Normally sup
only checks the mtime (modification date) and the '-c' option checks the ctime
(time of last file status change) which happens when any inode modifications are
done.

Sean