Checking all modules configured in OHS

That's something I've being looking for since I started working with OHS (a cousin of Apache web server in the case you don't know it).

Apache happily will tell you the modules it has running with by usage of apachectl (or httpd -M depending on the distribution you're using).

Well, that's not that easy for OHS, at least not while you're in the shell. Based on a tip that I found about /proc (see details here) I wrote this little Bash script for OHS 11g:

#!/bin/bash

PID=$1
full_path=$2

if [ -z $PID -o -z $full_path ]
then
    echo <<BLOCK
Usage:
iasenv.sh <PID> <path to httpd>
BLOCK
fi

temp_file=$(mktemp)
xargs --null --max-args=1 echo export < /proc/${PID}/environ > "${temp_file}"
source "$temp_file"
"${full_path}" -M
rm -v "$temp_file"

Then I call the shell script passing the PID of a running process of OHS and the complete pathname to the httpd.worker process (probably I should try to fetch this information from /proc too). Here is a sample of the output:

bash-3.2$ ./list_mods.sh 28377 /foobar/ias/product/OHS/ohs/bin/httpd.worker
Loaded Modules:
core_module (static)
mpm_worker_module (static)
http_module (static)
so_module (static)
oralog_module (static)
ohs_module (static)
ora_audit_module (static)
file_cache_module (shared)
vhost_alias_module (shared)
env_module (shared)
log_config_module (shared)
mime_magic_module (shared)
mime_module (shared)
negotiation_module (shared)
status_module (shared)
info_module (shared)
include_module (shared)
autoindex_module (shared)
dir_module (shared)
cgi_module (shared)
asis_module (shared)
imagemap_module (shared)
actions_module (shared)
speling_module (shared)
userdir_module (shared)
alias_module (shared)
authz_host_module (shared)
auth_basic_module (shared)
authz_user_module (shared)
authn_file_module (shared)
authn_anon_module (shared)
authn_dbm_module (shared)
proxy_module (shared)
proxy_http_module (shared)
proxy_ftp_module (shared)
proxy_connect_module (shared)
proxy_balancer_module (shared)
cern_meta_module (shared)
expires_module (shared)
headers_module (shared)
usertrack_module (shared)
unique_id_module (shared)
setenvif_module (shared)
context_module (shared)
rewrite_module (shared)
onsint_module (shared)
weblogic_module (shared)
plsql_module (shared)
swe_module (shared)
Syntax OK
«/tmp/tmp.hKZiBm6589» deleted
bash-3.2$

Impersonating a process on Linux

That's a short tip, but I would like to came across with it in the past earlier. It would avoid me having to put a lot of effort to do the same thing.

Sometimes, for a reason or another, you want to execute a program on Linux with a different set of environment variables set. This program might be using complex and/or hidden configurations that will you need to find and reproduce in order to execute the program properly.

The thing is, if you already have a instance of this program already running, /proc will do that for you easily. This is one of the possible implementations, with a good help from xargs:

temp_file=$(mktemp)
xargs --null --max-args=1 echo export < /proc/${PID}/environ > "${temp_file}"
source "$temp_file"
rm -v "$temp_file"

In this Bash script, I setup a temporary file to hold the environment configuration.

Then the script reads /proc/${PID}/environ, where ${PID} is the variable holding the process id that you're interested with.

This directory of /proc will hold every environment variable set for that process, separated by the NUL character. xargs will happily parse every entry in a loop, generating a single export <variable> for each item retrieved. And everything goes redirected to that temporary file.

That's it! No need to search around configuration files and/or debugging shell scripts to setup those variables. If the current configuration is working for the running program, it will certainly work for you too!