WebLogic Wrapper Scripts

Administrators with automation skill would perform than many admins. Requirement makes you to write automation scripts. I was working on Oracle Virtual Box, which is running SSH service. Hence I am able to connected thru PUTTy to the ubuntu Guest Linux server. By making Static IP configuration on the additional network adapter this was happen to possible.

 Everything going good! when I ran the WebLogic server from the PuTTY. It is working until when it is connected and alive. Once I went for break/Lunch the Windows system went to sleep then WebLogic server stopped due to PuTTY session inactive. To avoid this we can use the Wrapper start scripts.

 Idea behind the wrapper script/ psuedo code

1. Using the startWebLogic.sh script in background using &
2. use the nohup -- no hungup to run the process even the PuTTY inactive or closed
3. The log file generated by starting WebLogic server redirected to a separate file.
4. The Standard error file also merged with standard output log 
5. Display the tail command after doing the above
6. Additionally you can add back up of old WebLogic file with a time stamp this can be applicable in Production environments.

Startup Wrapper Scripts

Start WebLogic Admin Server with wrapper script

Here is the nohup usage sample:

$ nohup /domain/path/startscript.sh &

No hangup

The nohup UNIX command only writes to nohup.out if the output is otherwise to the terminal. If you redirect the output of the command somewhere else - including /path/redirect or some casees you can use /dev/null - that's where it goes instead.

nohup startWebLogic.sh >/path/redirect 2>&1   # doesn't create nohup.out

In modern bash and zsh (but not ksh) SHELLs you can shorten that to >&/path/redirect.

You can also use as follows:

nohup startWebLogic.sh >/path/redirect 2>&1&

Applying the above ideas into the wrapper scripts you can write a sample startAdmin.sh script in your WebLogic Domain.

New thoughts implemented that is logs path would be automatically created by the script now. I had this for long time but today 01-April-2015 came to improved version as 0.2 as published now!

#!/bin/bash
# Purpose : WebLogic AdminServer wrapper script which redirects logs to admin.out
# Author : Pavan Devarakonda  ver 0.2
# Category  : WebLogic Best Practices
# Override  : Yes, You can modify LOGDIR, LOGPATH values 

clear
DOMAIN_HOME=${PWD}
SERVER_NAME=`ls $DOMAIN_HOME/servers/|grep -i adm`
echo $SERVER_NAME
LOGDIR=$DOMAIN_HOME/$SERVER_NAME/logs
LOGPATH=$LOGDIR/$SERVER_NAME.log


if [ -d $LOGDIR ]; then
 nohup bash -c "$DOMAIN_HOME/startWebLogic.sh 2>&1 >>$LOGPATH" &
 echo .
 echo "Starting admin server..."
 echo "tail -f $LOGPATH"
 exit 0
else
 echo "Log path doesn't exists... creating directory now!!"
 mkdir -p $LOGDIR
 ./$0
fi 

Similarly you can write the wrapper codes for WebLogic Managed servers, NodeManager start scripts, so that you keep running your WebLogic related services without any hangs :)

 ii. Customized start managed server script

The above wrapper scripts there must inclusion of domain name recommended for non-production or multiple domains running on the same machines. There is a need to specify speparate standard output file path, if it is pre-production or Performance load testing environment you must also include GC logs path. Some of the WebLogic managed servers must include PRE_CLASSPATH that need to be processed before weblogic.jar in the CLASSPATH and some of the library jar files must be processed after the weblogic.jar, set them in a separate directories pre and post. Add them to CLASSPATH and it must be exported before startWebLogic.sh or startManagedWebLogic.sh called.

The following start wrapper script saved as "startms.sh" assuming that you might need few instance specific properties need to refer in startWebLogic.sh script. 

#==================================================
# The managed server name as argument for this script
# File : startms.sh  
# Usage: ./startms.sh mymanaged01  
#====================================================
INSTANCE=$1
export INSTANCE # not mandatory 
SOURCE=$(cd -P -- "$(dirname -- "$0")" && pwd -P)
cp $INST_HOME/$INSTANCE/logs/$INSTANCE.out $INST_HOME/$INSTANCE/logs/$INSTANCE.out.bkp
nohup $SOURCE/startManagedWebLogic.sh $INSTANCE >$INST_HOME/$INSTANCE/logs/$INSTANCE.out 2>&1 &
echo tail -f $INST_HOME/$INSTANCE/logs/$INSTANCE.out

Here $INST_HOME is defined in the user profile script.

These customized start scripts for admin server and managed servers. In the script make a copy of the last server instance log to instance.out_bkp. Some times due to some panic situations servers might crashed, after monitoring you found that it happen so restarting server should not loss that lost logs. If you maintain the backup of logs file automatically before starting the instance, then you are saved with that backup log file for further analysis about that crash.

Here in the above script, most of the UNIX/Linux environments it would work fine. Your script could use "nohup" that means no hung up when the remote machine is accessed with tools like SSH/PuTTY.

Some older environments (before WebLogic 12c) using JRockit as Java vendor. Better you include the following lines in the wrapper scripts will run in JRockit JVM.

JAVA_VENDOR="BEA"
export JAVA_VENDOR

If you create this script in development/QA environment same script can be used for UAT/PRE-Production or Production because keeping it more portable and flexible with SDIR (source directory path).

WebLogic NodeManager log generation

Node manager gives standard out file which can be collected by redirecting to a file nm.out.

#!/bin/bash
clear
nohup ./startNodeManager.sh  >> nm.out 2>&1 &
tail -f nm.out

# To run the NodeManger wrapper script give permissions
chmod +x startNM.sh

#Run the NM
./startNM.sh

Keep writing us your comments for betterment in this blog.

Looking into Middleware server logs made simple

Middleware Admin means the day runs with Emergency calls or On-calls, supporting team task always under high pressure cooker -- many of them feel tension tension due to heat in the head many got into hair-fall!!! ...

Its a challenging task, only those who can handle the jobs under pressure can do this with tricks. But When you don't have calls you might think to reduce your stress in the work with smart automation scripting to make life more easier.

Best Practices for WebLogic Logs

If the environment is shorter let say it is size of 10 - 20 managed servers, then the best idea is to implement is that all these managed server logs, JMS stores must shared a common mount point. When application support team run into issues, this will give you the flexibility to search the logs easily and faster way to get rid of issues with this unique log location.

In most of your project environments you might find the multiple logs such as application reated, JMS message stores or some transactional logs. In some critical situations, where you might need to look-up for a particular phrase of text in the WebLogic managed server generated logs. If you already follows best practices for collecting logs all together. It is easy to search in the sub sequant sub directories.

#FileName: CheckLogs.sh
#This script is used to find the given pharse in all logs available in the machine

INST_HOME="/home/wlusr/instances"
INSTANCES=`ls $INST_HOME|grep c`
phrase=$1
for instance in $INSTANCES
do
        echo 'Checking for the :' $instance
        cd $INST_HOME/$instance/logs
        egrep -i $phrase c*log*
        egrep -i $phrase c*out
done

If you keep above script in the general accessible path, such a way that it can be run from any directory on your machine. The Best practices for every WebLogic Middleware server running machines uses JAVA_HOME in their PATH. The best option to store this script is $JAVA_HOME/bin you can run from any path in your user.

Suppose you want to find all the WebLogic Servers which got RUNNING state on a machine. The search pattern you can give as bea-000360.

$ logverify bea-000360
Checking for the : cmgdserver01