If you're like me and you prefer to run a distro other than CentOS or RedHat Enterprise on your laptop or workstation, you may have run into problems trying to install and run ArcSight Console. So here are a couple of quick hack/fix tips that can get you up and running.
1) The problem: The installer won't run. It gives the following error:
error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
The fix:
sed -i 's/export LD_ASSUME_KERNEL/#xport LD_ASSUME_KERNEL/g' ArcSight-4.0.0.5206.0-Console-Linux.bin
2) The problem: When I try to run the installer or a previously installed console, I get the following error:
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
The fix:
sed -i 's/XINERAMA/FAKEEXTN/g' $HOME/arcsight/Console/current/jre/lib/i386/xawt/libmawt.so
3) The problem: Some windows don't draw correctly or at all when running the nvidia X11 video driver. I run 'arcsight console' and it hangs.
The fix: Switch back to the lame, non-AIGLX nv driver.
The hack: For some reason, if you run Java inside of strace, it works. (I suspect this has to do with Java threading.) Edit the execjava.sh script in the current/bin/scripts directory. The very last line begins with "$JAVA_HOME/bin/java". Put 'strace' at the beginning of that line. Now run 'arcsight console' like you normally would. Using 'strace' generates a lot of overhead, and will slow the console down, but it runs, which is more than you had before. And if you just can't give up compiz's wobbly windows, this may work for you.
There is a easier way. you can modify blacklist excludes and deal with this issue, without the overhead of strace.
ReplyDeletePlease elaborate. I'm not sure what you mean by 'blacklist excludes' in the context of launching Java apps.
ReplyDeleteRe: 1), are you sure you've got the libc libraries linked properly? Sounds like it could be a simple library linking issue. I would be hesitant to proceed after simply commenting the dependency out.
ReplyDelete@Anton:
ReplyDeleteThe issue is that ld looks for libc6 on a machine that's only got glibc2. The only thing we're changing is the InstallAnywhere script/wrapper for the console. The actual offending code is this:
if [ $linux_LD_ASSUME_KERNEL_hack -eq 1 ]; then
LD_ASSUME_KERNEL=2.2.5
export LD_ASSUME_KERNEL
fi
And all we're doing is preventing ld from getting an erroneous kernel version during installation. I'm positive that there are no linked library problems with these machines.