|
Problem |
Apache/IBM V1.3 and 2.0 HTTP Web servers
can be configured with WebSphere® Application Server V4.0 V5.0, and V5.1
plug-in. Some customer cases have reported that overall performance
degraded, and lots of "Failed to stat plugin config file" errors were
observed within the plug-in trace. This technote explains how to correct
this problem. |
|
Cause |
Due to incorrect permissions, the WebSphere plugin module
is unable to stat() the plugin-cfg.xml file for possible refresh. |
|
Solution |
Following is the analysis and solution to the problem.
The example mentioned in the Abstract is from an AIX® platform, but it
applies to all Unix®, Linux®, and Windows® platforms running the
Apache/IHS Web server.
Background:
When the RefreshInterval expires and a new request is received, the
WebSphere plug-in first checks if it needs to reload the plugin-cfg.xml.
The plug-in has to stat() the plugin-cfg.xml file to see when the file was
last modified. If this fails, the plug-in continues the same check on each
subsequent request, because the RefreshInterval has expired and has not
successfully reloaded the plugin-cfg.xml file.
Solution:
For the stat() to succeed, the ID that runs IHS must read and execute
permissions on all the directories included in the path of plugin-cfg.xml,
and read and execute permissions on the plugin-cfg.xml itself. Normally,
the IHS parent process is started as root, but its children switch to
nobody/nobody (user/group). You have to verify that the user/group that
owns the IHS children processes have the correct permissions to stat()
plugin-cfg.xml. This eliminates the stat() error, and makes the plug-in
check only after the RefreshInterval has expired.
Customer case:
- After configuring a remote IHS 2.0.42.2 instance on an AIX
5.2 ML2 using the V4.0 plug-in, the WebSphere plug-in initialized properly
when IHS started up as root; however, after the RefreshInterval expired,
these events and errors were observed in the plug-in trace at every new
http request. Following is a snippet of a full plug-in trace, when
LogLevel directive was set to Trace:
TRACE: ws_common: websphereConfigIsNew: New config detected
TRACE: ws_common: websphereShouldHandleRequest: Attempting to reload the
config
TRACE: ws_common: websphereUpdateConfig: begin updating configuration
ERROR: ws_common: websphereUpdateConfig: Failed to stat plugin config
file: /opt/WebSphere/AppServer/config/plugin-cfg.xml
ERROR: ws_common: websphereShouldHandleRequest: Config reloading FAILED;
using old config
- WebSphere performance degraded due to repeated attempts to
stat() the plugin-cfg.xml file.
- IHS started as root and all children ran under
nobody/nobody. These directives were configured in IHS httpd.conf, which
caused IHS children to switch to nobody/nobody (user/group):
User nobody
Group nobody
- Plugin-cfg.xml was owned by root/other (user/group) and
was located in this directory:
opt/WebSphere/AppServer/config/plugin-cfg.xml
- These two plugin directives were configured in the IHS
httpd.conf:
LoadModule was_ap20_module
/opt/WebSphere/AppServer/bin/mod_was_ap20_http.so
WebSpherePluginConfig /opt/WebSphere/AppServer/config/plugin-cfg.xml
- The plugin-cfg.xml correctly had 755 permissions for
user/group/others:
rwxr-x-r-x
- All directories but one in the path to the plugin-cfg.xml
had correct 755 permissions:
rwxr-x-r-x
- The config directory had 754 permissions:
rwxr-x-r-x
- The missing execute permissions for user/nobody that
belonged to the others category caused IHS children running under
the user nobody to not stat() the plugin-cfg.xml file. After the
customer updated the config folder with 755 permissions, the
problem was resolved.
Notes:
Following is a test case you can use to confirm that the missing incorrect
permissions is the cause of the "Failed to stat plugin config file" errors
in the plug-in trace. It is not necessary to change permissions of the
folders in the path to the plugin-cfg.xml and the plug-in configuration
file.
- Create a folder (for example, /opt/plugintest) outside of the
WebSphere/IHS installation directory.
- Copy the plugin-cfg.xml into the /opt/plugintest folder.
- Set 755 permissions in the /plugintest directory and the
plugin-cfg.xml file.
- Update the IHS httpd.conf so that the WebSphere plug-in points to the
/plugintest folder; for example,
WebSpherePluginConfig/opt/plugintest/plugin-cfg.xml.
- Start IHS and perform the required tests.
If the problem does not occur, verify and update all
required permissions to the folder or folders in the path to the
real plugin-cfg.xml and the plug-in configuration file. If the problem
still persists, contact IBM Software support and provide the following
information:
- httpd.conf
- IHS access and error logs
- Full plug-in trace (LogLevel="Trace" in the plugin-cfg.xml)
- plugin-cfg.xml
- List of all directory permissions in the path to the plugin-cfg.xml
- Permissions of the plugin-cfg.xml
Conclusion
IBM recommends using IBM HTTP Server 2.0, rather than IBM HTTP Server 1.3,
whenever possible. IBM HTTP Server 2.0 is a thread-based Web server, with
the WebSphere Application Server plug-in fully tested and supported with
all current and future releases of V4.0, V5.0 and V5.1.
Review these documents if you plan to migrate from IBM HTTP Server 1.3 or
from any other third-party Web server, to IBM HTTP Server 2.0:
|
|
|
|
|
|
|
|