Memory Issues with Oracle WebLogic Smart Update

Oracle WebLogic Smart Updater splash screen

If you need to update Oracle WebLogic 10.3.6 on Solaris / UNIX / Linux with a security patch or service pack, you will likely find yourself using the Oracle Smart Update program. 

This program, which is run by executing the script bsu.sh, is usually found in the utils/bsu folder underneath the BEA Home folder. For example, if your BEA Home folder is “/u01/app/bea64/middleware”, you would change directory to “/u01/app/bea64/middleware/utils/bsu”, and execute bsu.sh, after uploading the required patch files to the cache_dir directory.

{user@server:/:}# cd /u01/app/bea64/middleware/utils/bsu
{user@server:/u01/app/bea64/middleware/utils/bsu:}# ./bsu.sh

Officially, this is how you would execute the program. Except that, for whatever reason, it seems that this script has not provided nearly enough memory for the program to run. Unfortunately, you will likely not find this out for almost an hour, while you get the splash screen above and your server attempts to run the program.

One Eternity Later

After the interminable wait is up, your program has crashed, and you finish pulling what’s left of your hair out, you can begin to troubleshoot the problem. Or, hopefully, you will have found this post before trying any of this!

Let’s look at the source of the problem. Literally.

{user@server:/u01/app/bea64/middleware/utils/bsu:}# cat bsu.sh
#!/bin/sh
JAVA_HOME="/usr/jdk/instances/jdk1.8.0"
MEM_ARGS="-Xms256m -Xmx512m"
"$JAVA_HOME/bin/java" ${MEM_ARGS} -jar patch-client.jar $*
{user@server:/u01/app/bea64/middleware/utils/bsu:}#

See that MEM_ARGS variable? This isn’t 1999 anymore, so let’s change the memory allocation, shall we? Oh, I should mention that if you’re still using a 32-bit version of Java, you’ll be constrained by that pesky 2 GB limit and will have to adjust accordingly.

Let’s see how much memory we have. I’m running Solaris, so this is what I ran:

{user@server:/u01/app/bea64/middleware/utils/bsu:}# prtconf | grep Memory
prtconf: devinfo facility not available
Memory size: 131072 Megabytes
{user@server:/u01/app/bea64/middleware/utils/bsu:}#

Also, I ran “java -d64” just to ensure that I am indeed running a 64-bit JVM.

Using everyone’s favorite editor (vi, of course), I increased the JVM memory allocations and saved the script as a new file: bsumem.sh.

#!/bin/sh
JAVA_HOME="/usr/jdk/instances/jdk1.8.0"
MEM_ARGS="-Xms32255m -Xmx64510m"
"$JAVA_HOME/bin/java" ${MEM_ARGS} -jar patch-client.jar $*

After saving the file, I executed it: “./bsumem.sh”

Oracle Smart Update loading...

At this point, go pop some popcorn and watch an episode of something on Netflix or Amazon Prime. Don’t worry, the program will still be loading when you finish. (You might actually want to check every 15 minutes or so just to make sure that no other errors crashed the app!)

Once your show is over, you can come back and if you held your mouth right when executing the last command, the program will be ready to load the patch. Or you may have to wait another 15-20 minutes, but it should be relatively soon.

I have yet to figure out why this program takes so long to run, though from what I’ve read, it’s a common – if not universal – experience. 

Mailing Attachments from the Terminal Prompt in UNIX and Linux

UNIX logo

Transferring files from a UNIX or Linux server when FTP is not installed can be tricky. In my case, there was a set of log files that I needed to send to someone for analysis. After discovering that FTP was not set up on the server, I decided to try another route: zipping the logs into a single file and emailing the file to me.

First, I had to zip the files. The zip command was easy enough:

zip <zipped filename> <files to be zipped>

zipping files in UNIX

Next, I had to mail the zipped file. Fortunately, mailx was installed! Using this in conjunction with uuencode, and the file would be on its way.

uuencode <original filename> <final filename> | mailx -s <subject of email – put in quotes> <email address>

mailx example

Be sure to check your junk or spam folder, as email from the server could end up there.