Version 2.1.8. Running the Do Setup step on "9.1-Apply patch 7303029" and it seems to just be hanging and I'm not finding a way to find out why. The log file on the MW server has not been updated for close to 30 minutes and no log files have been created in the patch log folder on the application server. All that the MW log says is below but the process shows as still running. Have to admit I'm getting a little frustrated with having to open threads or SR's for each step. Any help would be appreciated. Thanks!
UID PID PPID C STIME TTY TIME CMD
oramwiz 32041 17353 0 07:17 ? 00:00:00 /usr/bin/ksh /u01/mwiz/mwizdb/10.....
Here is a summary of the log on the MW server (script_10735.sh.log)
OK - GENERIC patch appears on local machine
OK - copied 7303029 to apps
Trying to unzip patch: 7303029 on remote node: apps
Starts echoing the log file
Below is the last line in the log that has been there for over 30 minutes. Again, no log files are showing on the apps server and nothing is in the preinstall folder.
There are no tasks to be performed in this section.
In researching this further it looks like the script has moved to our 2nd app server (web/forms) and is hung trying to unzip the patch even though the patch was already unzipped successfully when it ran on the 1st app server (ccm/reports). Our R12 install is in a shared appltop environment so don't know why it is trying to unzip it again from the 2nd server but that appears to be why it is hanging. I'm guessing it sees that it is already unzipped and is probably prompting to overwrite or not and I can't responsd to it. Any ideas? Wonder if it is safe to just kill the process(s) and mark the step complete?
Processes on the MW server
/usr/bin/ksh /u01/mwiz/mwizdb/10.2.0/eof/bin/rundb.sh p_filename=/u01/mwiz/mwizdb/10.2.0/eof/log/INSTANCE_1704/script_10735.sh
/u01/mwiz/mwizdb/10.2.0/eof/scripts/COMMON/eof_patch12.sh patch h
ssh <2nd app server> -l <applowner> eof_upgrade/REMOTE12_FRM.env /nfs/demo/apps/apps_st/appl/patch/un_zip.sh p7303029_R12_.zip
Processes on the 2nd apps server
/bin/ksh eof_upgrade/REMOTE12_FRM.env /nfs/demo/apps/apps_st/appl/patch/un_zip.sh p7303029_R12_.zip
There are no MW related processes running on the 1st app server. It has completed its steps.
The concept for this is individual patch directories for each node. I will log an enhancement for this to work on shared appltops. You are correct that the unzip is hanging because it is prompting to overwrite and it can not. The unzip.sh does not use the -o option. Since this is a shared appltop environment and the patch has been applied in preinstall mode already you can safely kill the processes and continue.
Should I be seeing anything in my preinstall folder at this point or will that come from the 'Do Execute' step? Right now my preinstall is emtpy. I had manually backed it up, and cleaned it out, per the instructions on the step but also have a thread asking for clarification on this. So to make sure I understand, this step is actually complete and has not other actions to perform so if I kill the process on the 2nd app server to see if it complets I should be okay? If killing that process doesn't clean up the others on the MW server I assume I will kill them as well and then just mark the step as complete.
You are going to experience this issue on every patch that you apply - you could edit the un_zip.sh and add the -o but this will cause you to apply the same patch multiple times on the shared appltop. Your choice - kill when hung or add the -o and install patches twice.
Sorry you are having so many issues. Please do not give up on the tool.
Why haven't I hit this before? I've previously applied 11i and R12 patches via the wizard and it didn't hang on an unzip like this? From what I'm seeing this unzip code is in the eof_patch12.sh so I guess I could add a -o option to it and see if that resolves it. I'm just confused on why I have not hit this in previous steps. Thanks for all of the help!
I will look into it further - is your 11i shared appl top as well? It could just be that the patchit12.sh does not check to see if the patch is present and unzipped and tries to unzip it again.
If you open step 9 execute can you cut and paste the text from the application of the dba cup merge application so I can see if it applied to both nodes?
I think I now why I haven't hit this before. In checking some of the previous log files it looks like it removes the unzipped patch folder if it already exist and then unzips. Guess this step doesn't do that I it wouldn't have hung like this. You are also correct in that it is applying the patch from both servers even though it doesn't need to be doing this. I was wondering about this the other day and thought I saw in a log file where when it went to apply on the 2nd server it checked ad_bugs or something and just said it was already applied and didn't reapply it. The log I just looked at didn't do that, it actually applied the patch again. I'm trying very hard to keep going with this because I can see the value of having a consistant plan for migration to other instances. My battle right now is my boss and others asking why this is taking so much longer than when I did it manually before. I keep explaining that once we get through the wizard one time the value should be seen as we move forward. Hopefully that will be the case or I won't be able to seel using it if it ends up adding time to the process. Thanks again for all of the help.
Sorry, I was typing a response when you posted. As for your questions:
Our 11i installation is not in shared appltop mode. We are wanting to move to this with the R12 upgrade.
As noted in my previous update the CUP merge patch did apply twice but worked because it removed the unzipped patch folder before attempting to unzip it again from the other server.
Sorry but I still have a question on the recommendation to kill the processes and continue. Should patch 7303029 exist in the preinstall folder during this step? If so, then killing the process will not work since this patch has yet to be put in the preinstall folder.
Lets try this.
1. Kill the processes
2. Set the step "Setup" to REDO ACTION (open the already run step and click the REDO ACTION button.)
3. Fix the un_zip.sh to have a -o
4. Run setup again
I believe that since it is preinstall mode that only the driver file gets copied to the preinstall directory. You may want to verify if u7303029.drv is under the preinstall directory.
I'll try some things here in a bit..getting side tracked with other items right now. The 7303029 driver is not currently in the preinstall folder so it looks to me that staging to preinstall must be later in the logic so I assume killing this will not lave me in a valid state. I'm betting I will need to do this step and maybe any upcoming patching steps manually. I'll update once I know more. Thanks!
UPDATE: I killed the process step running the unzip command on the 2nd app server and it appears that it did continue and may have finished correctly. The 730329 driver is now in the preinstall folder and the patch is still unzipped in the patch location. Hopefully the unzipped patch is still valid. I'll need to dig through the log deeper and check files on the server to make sure things are still valid and I should proceed or not.
Edited by: user649511 on Mar 3, 2011 10:04 AM