"Failed to stat plugin config file" error message in V4.0, V5.0, or V5.1 plug-in trace.
 Technote (FAQ)
 
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.
  1. Create a folder (for example, /opt/plugintest) outside of the WebSphere/IHS installation directory.

  2. Copy the plugin-cfg.xml into the /opt/plugintest folder.

  3. Set 755 permissions in the /plugintest directory and the plugin-cfg.xml file.

  4. Update the IHS httpd.conf so that the WebSphere plug-in points to the /plugintest folder; for example, WebSpherePluginConfig/opt/plugintest/plugin-cfg.xml.

  5. 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:
  1. httpd.conf

  2. IHS access and error logs

  3. Full plug-in trace (LogLevel="Trace" in the plugin-cfg.xml)

  4. plugin-cfg.xml

  5. List of all directory permissions in the path to the plugin-cfg.xml

  6. 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:
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Plug-in
Operating system(s): Windows
Software version: 5.1
Software edition:
Reference #: 1165469
IBM Group: Software Group
Modified date: Apr 7, 2004