Title: | Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server |
Notice: | Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server |
Moderator: | CPEEDY::KENNEDY |
Created: | Fri Dec 18 1992 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 4319 |
Total number of notes: | 18478 |
A couple weeks ago one of our system admin folks tried to install PATHWORKS on a new node we are bringing into our existing cluster. Our current cluster consists of 2 7000 series Alphas (nodes MINNIE and DAISY). They share a common system disk and are at VMS V6.2. We've another Alpha 8400 (node BAMBI) that has its own system disk and its at VMS V6.2-1H3. We've applied a number of VMS patches as well. PATHOWRKS is V5.0D ECO3. Our new node is another 8400 (PLUTO) with its own system disk at V6.2-1H3. The person who attempted the install of PATHWORKS on PLUTO started the install during normal working hours, thinking since PLUTO had its own system disk he could do the install without affecting the other active cluster members. He unfortunately did not realize that the PATHWORKS install needed to shutdown PAHTWORKS on the other cluster members. Attempting to re-start PATHWORKS was not successful since the other members required re-booting before PATHWORKS could be re-started. Why is that neccessary? I'm confused why the install on the 4th cluster member warrants a re-boot of all the other PATHWORKS Cluster members? MINNIE and DAISY were not re-booted for 2 days after the install. BAMBI was not re-booted till a week later. Could this cause us problems? About a week after the install. they needed to shut down PLUTO, the newly installed system. The VMS Shutdown or PLUTO hung and they forced a crash on PLUTO. We then experienced a suspended PWRK$LMSRV process on node MINNIE which alos impacted PATHWORKS access on all cluster. We were forced to then re-boot MINNIE. MINNIE re-booted fine and PATHWORKS access was ok on the cluster. An analysis of the system dump file inidciated and outstanding lock could not be resolved when PLUTO tried to dismount a disk device that had locks taken out on by the LMSRV process on node MINNIE. Unfortunately the system dump file was not large enough and they could not get a better look at what the LMSRV process was doing. Could we run into some sort of locking problem caused by the incomplete PATHWORKS install on PLUTO? We also found out that when PLUTO hung trying to shutdown, PATHWORKS was not active on it however we subsequently did another VMS shutdown on PLUTO with PATHWORKS active and PLUTO shutdown normally. When the tried another VMS shutdown of PLUTO with PATHWORKS not active and we experienced the same hung VMS shutdown. My thought is that somehow the incomplete install of PATHWORKS may be causing problems. All of this is documented with the CSC under log numbers C970429-122 and C970508-3859, but they are scratching their heads also. I know this is kind of vague, but thats all I have for now and of course the customer wants answers. Any input would be appreciated. Thanks, Barry A
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
4296.1 | Separate system disks unsupported | CPEEDY::VATNE | Peter Vatne, Advanced Server for Digital Unix Engineering | Mon May 19 1997 13:03 | 25 |
I can only give you some answers for the install questions: > The person who attempted the install of PATHWORKS on PLUTO started the > install during normal working hours, thinking since PLUTO had its own > system disk he could do the install without affecting the other active > cluster members. He unfortunately did not realize that the PATHWORKS > install needed to shutdown PAHTWORKS on the other cluster members. I'm not sure why the installer didn't realize this. The PATHWORKS install procedure explicitly warns the installer that PATHWORKS must be shut down on the other cluster members, and gives the installer the option to exit out of the install procedure if the installer doesn't want to do this. > Attempting to re-start PATHWORKS was not successful since the other > members required re-booting before PATHWORKS could be re-started. > Why is that neccessary? I'm confused why the install on the 4th cluster > member warrants a re-boot of all the other PATHWORKS Cluster members? > MINNIE and DAISY were not re-booted for 2 days after the install. BAMBI > was not re-booted till a week later. Could this cause us problems? You and I know that the new system has a separate system disk, but the PATHWORKS install procedure doesn't. Technically, separate system disks is unsupported, except for mixed VAX and Alpha clusters, and then only for one system disk for each architecture type. Rebooting several days after the install should cause no problems. |