27 February 2012

IBM HTTP Server not starting - http_plugin.log excess size

I just happened to come across the following error:
I'm using IBM HTTP Server 7 with WAS Plugin configured. the following behavior was observed - after attempting to start IHS with 

<IHS_INSTALL_ROOT>/bin/apachectl start

control returns to shell, as it should. But when I checked if IHS is up and running with

nestat -an | grep <portnumber>

it didn't show desired port listening, however when looking for httpd processes with:

ps -ef | grep httpd

showed all necessary httpd jobs (namely, 4 of them). That is a problem symptom.

This was the second time I came across that, so I knew what to do. The clue is http_plugin.log file size: when it grows over 2147483647 bytes (on Linux), OS is no longer able to write to it, and despite seemingly successful startup of the server. So, you just need to remove (or move to other place if you need it) this file, and try to start IHS again, it will recreate it and work fine. The log file is located in <PLUGIN_ROOT>/logs/<Servername>/http_plugin.log

If you happen to see this malfunction, review your WAS plugin LogLevel settings. Remeber that on Trace or Detail level it generates fairly lot of entries and log grows very quickly. If your system is working fine and you don't have any sophisticated file log monitoring implemented, just change it to Info or Warn - it will be sufficient and your log file won't clog up.

Good luck,  thanks for comments and feedback!

13 February 2012

Installation Manager java.lang.UnsatisfiedLinkError: Could not load SWT library

IBM Installation Manager is more and more widely used to deploy number of IBM products, so it may be useful to know a little about possible problems when running this tool.
My today's accomplishment is that I overcame following issue with installation on a lightweight SuSE 11 distribution (eg. stripped from almost every non-necessary package).
First, when trying to install IM itself I was knocked by:

JVMDUMP010I Snap dump written to /tmp/was/IM/Snap.20120213.121315.11358.0003.trc
libgcc_s.so.1 must be installed for pthread_cancel to work

This one was tackled by adding libgcc43-32bit package to the system. After successful silent installation, I tried to actually run IM to install WAS 7. Shell showed nothing after issuing:

./install or ./IBMIM

It was all I got:

prep2def:/opt/ibm/InstallationManager/eclipse # ./launcher
prep2def:/opt/ibm/InstallationManager/eclipse # cd /tmp/

Looking into configuration/datestamp.log files I found this error:

!ENTRY org.eclipse.osgi 4 0 2012-02-13 13:32:15.756
!MESSAGE Application error
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
        /opt/ibm/InstallationManager/eclipse/configuration/org.eclipse.osgi/bundles/454/1/.cp/libswt-pi-gtk-3659.so (libgthread-2.0.so.0: cannot open shared object file: No such file or directory)
        swt-pi-gtk (Not found in java.library.path)
        /tmp/swtlib-32/libswt-pi-gtk-3659.so (libgthread-2.0.so.0: cannot open shared object file: No such file or directory)
        /tmp/swtlib-32/libswt-pi-gtk.so (/tmp/swtlib-32/liblibswt-pi-gtk.so.so: cannot open shared object file: No such file or directory)

And finally, installing:

DejaVu Truetype Fonts


helped, and I was able to successfully run Installation Manager. Hope it helps. Good luck.

07 February 2012

SECJ0053E and AWXJR0044E: PolicyConfiguration exists = false

If you are working on WAS with JACC configured against Tivoli Access Manager (or other external authorization provider, but I assume TAM is the most popular) in your application development cycle you may stumble upon the following error sequence:
[2/7/12 11:24:45:304 CET] 000000c8 SecurityColla A   SECJ0053E: Authorization failed for defaultRealm/username while invoking (Bean)XyEAR-2.2#XyzBean.jar#soapAction:5 JACC Authorization failed for bean: xyzvBean
[2/7/12 11:24:45:660 CET] 0000003d AMWASJACCMess I   com.tivoli.pd.as.jacc.TAMPolicy implies(ProtectionDomain, Permission): permission = perm.toString()
AWXJR0044E   The access decision for Permission, (javax.security.jacc.EJBMethodPermission xyz), was denied because either the PolicyConfiguration or RoleConfiguration objects did not get created successfully at application installation time.  RoleConfiguration exists = true, PolicyConfiguration exists = false.

It is more probable to occur right after application update (new version deployed, for instance).

Here are the things you may do to steer out of this trouble:


  1. Ensure all necessary protected object exist in TAM policy database (use pdadmin or WPM - TAM console deployed on WAS)
  2. Update role definition in your authorization provider with:

    Global security > External authorization providers

    choosing "Update with application names listed" and typing in your application name (as appears in Enterprise Applications tab), then Apply

  3. If point 2. fails, follow this sequence: stop application, remove application from server, stop application server, clean temp directories for this server, start server and redeploy application. It should bind with TAM properly this time. After that, restart the server again.
 Good luck.