Wednesday, April 1, 2015

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.

3 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. I like the Idea behind the wrapper script/ psuedo code.
    Regards,
    WebLogic Training.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete

Blurb about this blog

Blurb about this blog

Essential Middleware Administration takes in-depth look at the fundamental relationship between Middleware and Operating Environment such as Solaris or Linux, HP-UX. Scope of this blog is associated with beginner or an experienced Middleware Team members, Middleware developer, Middleware Architects, you will be able to apply any of these automation scripts which are takeaways, because they are generalized it is like ready to use. Most of the experimented scripts are implemented in production environments.
You have any ideas for Contributing to a Middleware Admin? mail to me wlatechtrainer@gmail.com
QK7QN6U9ZST6