coreadm - core file administration

coreadm command for Solaris:

You must be wondering what this coreadm command does. It is really a powerful tool that helps the administrator to look at the cores generation way.

Actually there are times when we found that our core files is getting generated with the name "core" in the process running directory. And if the process is generating cores in quick succession than the same file is getting overwritten all the time.

Thus it will become tough for us to debug the core..............

So in such cases we can actually make the core file get generated with a name pattern and this can be possible with the coreadm command in Solaris OS (x86 or SPARC).

Execute the command without any option will display the current settings done for the core files generation.

bash-3.2$ coreadm
     global core file pattern:
     global core file content: default
     init core file pattern: core
     init core file content: default
     global core dumps: disabled
     per-process core dumps: enabled
     global setid core dumps: disabled
     per-process setid core dumps: disabled
     global core dump logging: disabled

When i executed the command on my Solaris Sparc box above output is shown. It shows that core file generation per-process is enabled but the core file name pattern (in init core file pattern) is "core" only. Thus with this setting the same file will be overwritten all the time.

So as to set the name pattern for per-process, follwoing is the command:

• bash-3.2$ coreadm -i core.%f.%p.%t

Here %f - file/process name
         %p - process pid
         %t - default timestamp

To confirm above made settings, execute below mentioned command:

• bash-3.2$ coreadm $$

          27756:  core.%f.%p.%t   default
It shows the set core file name pattern.

Thus now-onwards you will notice that core files will be generated with a name pattern.
Like - "core.httpd.worker.4298.1404300544"

So coreadm makes our life easy....................

Enjoy :-)

Lock Files in OAM 11g R2PS2

Don't play with Lock Files in OAM 11g:

You must have had noticed that there are some files present in diagnostics folder or in webgate profile folder with an extension .lck.

Eg: 

polltracking.lck

oblog.log.lck

ObAccessClient.xml.lck

Basically these lock files are required by the server process so as to perform the read/write lock operations.

In case they are unable to do so, it might cause an issue.

So what could be the reason that the process is not able to acquire lock on a file and what can happen in that case.

Scenario:

1) In the Oracle Webtier instance directory we have a diagnostics folder where the logging info is captured.

Path: <MiddlewareHome>/<Oracle_WebTier>/instances/<instance_name>/diagnostics/logs/OHS/ohs1

In the above mentioned directory we have another directory having some numeric name like ->  2517662326/

So what this contains & how come this name?

• Basically this folder contains lock files which are as follows:
• polltracking.lck
• oblog.log.lck
• ObAccessClient.xml.lck

• And the name of this folder is the result of Hash done on the instance_name absolute path i.e. /scratch/ckukreja/OracleNew/Middleware/Oracle_WT1/instances/instance1/diagnostics/logs/OHS/ohs1
• So the hash of above path is 2517662326 this.

Now at the time server process is coming up, it checks for the directory path where the .lck file can be created or lock can be acquired.

As we know that webgate is integrated to the web-server like OHS, OTD, DOMINO, IIS, APACHE etc, So like in case of OHS server, the httpd.worker process looks for the directory path in following sequence:

1) Webgate Lock Directive mentioned in webgate.conf

2) Lock Directive mentioned in httpd.conf

3) Default Lock Directive

This sequence info can be found in webgate.conf file present in <MiddlewareHome>/<Oracle_WebTier>/instances/<instance_name>/config/OHS/ohs1/webgate.conf

Abstract from webgate.conf:

# WebGateLockFileDir: Optional directive specifying the location to create

# webgate lock files.

#

# If configured, then all webgate lock files will be created under

# <WebGateLockFileDir>/<Hash of WebGateInstancedir>. The hash subdir is to

# ensure uniqueness for each webserver instance and avoid locking conflicts

# if two different instances have configured the directive with same value.

#

# If the dir does not exist before, will try to create it first. If dir

# creation failed or the directive not configured, for Apache based web

# servers, will check web server's LockFile directive (also optional), extract

# its dir and use <LockFile's dir>/<Hash of WebGateInstancedir> if exists or

# created successfully.

#

# If none of above is defined or exists, then webgate falls back to old model,

# i.e. use same location as original file that lock is based upon.

#

# This directive is useful when webgate instance is located on NFS mounted

# disks and performance greatly impacted. Configure it to local dir will solve

# the issue.

#

# WebGateLockFileDir "<some_local_dir>"

So lets say we have specified the entry in the httpd.conf file:

• Under mpm worker module 
• LockFile ${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME}/http_lock"

Thus from here the location is identified & webgate will initialize & read-write lock to this directive only for its task.

Problem:

So what if while the server is up & running and some one tries to play with these locks intentionally or unintentionally. In that case its a problem.........!!!!!!!

Usually what we do is that we specify the lock file location to some /tmp or other directive which is listed in some cron job. And the time cron job executes it deletes the directory.

Thus while the process is running & such tampering is done, so when some user request lands to the web server, it will result in failure of user requests.

WebGate will again create this directory and subsequent calls will be success.

Precaution:

Always specify the lock file directory to such a place where it is a surety that the directory won't gets deleted while the server is running and catering users requests............................

Enjoy :-)