Hide Forgot
Description of problem: On my HA cluster, I noticed that the cluster thought tomcat6 was running, but always failed when checking to see if it was a running service. The reason is that it never actually starts. Here's why: sudo rg_test test /etc/cluster/cluster.conf start service CDTG\ Tomcat blah blah blah /usr/sbin/tomcat6: line 30: ${2}: ambiguous redirect <debug> Starting Service tomcat-6:tomcat6 > Succeed Starting Service tomcat-6:tomcat6 > Succeed blah blah blah If you look at line 145 of /usr/share/cluster/tomcat-6.sh, you'll see that tomcat6 is started with *one* argument: /usr/sbin/tomcat6 start However, /usr/sbin/tomcat6 assumes *two* arguments! See line 35 of /usr/sbin/tomcat6 ... it needs $2 as well, without it, we are redirecting output to a non-existent file. This is why tomcat6 never starts. This is the first bug. The second bug is that while running the /usr/sbin/tomcat6 script without the 2nd arg, it never starts anything, and *still* reports an error code of 0. If nothing was started, it shouldn't return and error code of 0, right? Version-Release number of selected component (if applicable): tomcat6-6.0.24-33.el6.noarch resource-agents-3.0.12-22.el6.x86_64 RHEL 6.1, all updates
Moving to 6.3 since this came in after planning phase for a qa_ack.
Any test packages that I can verify are working? I'm happy to help
This is still broken in RHEL 6.2: $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 (Santiago) $ grep bin/tomcat /usr/share/cluster/tomcat-6.sh /usr/sbin/tomcat6 start $ rpm -qf /usr/share/cluster/tomcat-6.sh resource-agents-3.9.2-7.el6.x86_64
Looks like this is fixed in the tomcat6 package itself, not resource-agents: $ sdiff -s fedora16:/usr/sbin/tomcat6 rhel6.2:/usr/sbin/tomcat6 >> ${CATALINA_BASE}/logs/catalina.out 2>&1 & | >> ${2} 2>&1 & >> ${CATALINA_BASE}/logs/catalina.out 2>&1 & | >> ${2} 2>&1 & >> ${CATALINA_BASE}/logs/catalina.out 2>&1 | >> ${2} 2>&1 So, this is really a RHEL 6.2 tomcat6 bug.
This is fixed in package 6.0.24-37_el6 The work around: Replace "${2} 2>&1" with "${CATALINA_BASE}/logs/catalina.out 2>&1" diff -r1.3 -r1.4 39c39 < >> ${2} 2>&1 & --- > >> ${CATALINA_BASE}/logs/catalina.out 2>&1 & 55c55 < >> ${2} 2>&1 & --- > >> ${CATALINA_BASE}/logs/catalina.out 2>&1 & 67c67 < >> ${2} 2>&1 --- > >> ${CATALINA_BASE}/logs/catalina.out 2>&1
Awesome! Now where can I find package 6.0.24-37_el6? I'd be happy to test it out and report back.
VERIFIED on tomcat6-6.0.24-37.el6
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No tech notes required
I've looked at the tomcat6 package in RHEL 6.3 Beta, and it does appear to be fixed.
What tomcat6 version did you look in? There is an erratum for RHEL-6.3 in progress, which should contain fix for this issue. tomcat6-6.0.24-43.el6 contains the fix from comment#9, however there will most probably be a different (newer) build released in the erratum.
I looked at version 6.0.24-43.el6. Where can I get at newer versions... or do I have to wait for the official RHEL 6.3 release?
The version you have looked into should already contain the fix. I don't have your setup from comment#0 so I may be wrong. As I look in /usr/sbin/tomcat6 line 31, 55 and 67 from tomcat6-6.0.24-43.el6 I see: >> ${CATALINA_BASE}/logs/catalina.out 2>&1 & Based on that, /usr/share/cluster/tomcat-6.sh should no longer have problem with invocation of: /usr/sbin/tomcat6 start My observations are based on code inspection only, I don't have your setup to try it on. Is it still causing you troubles, or is there something else that I don't see? Thank you
Works fine by itself, but still causing issues with clustering, yes. No longer do I get "ambiguous redirect", but I get "no such file or directory: /logs/catalina.out". The clustering setup script somehow isn't seeing any value for ${CATALINA_BASE}
Thank you very much for the information, I think I now know where the problem is. Tomcat is one of the few linux services that support multiple instances. Therefore /usr/sbin/tomcat6 is service independent startup script for tomcat, which is meant to be wrapped in a service specific init script, such as /etc/init.d/tomcat6, which sets all the necessary environment variables /usr/sbin/tomcat6 needs. Because /usr/share/cluster/tomcat-6.sh runs /usr/sbin/tomcat6 directly, those variables are not set, therefore ${CATALINA_BASE} is not set. There is an implementation in /usr/sbin/tomcat6 that sources the default configuration file (/etc/tomcat6/tomcat6.conf) if the variables are not set, however it is commented out. I wonder what lead the developer to remove it, but I bet there was a good reason for it. David, do you mind giving some feedback on this please?
One should never run the /usr/sbin/tomcat6 script directly, consider it a private helper script used by the /etc/init.d/tomcat6 initscript. I can't explain why a private executable is located in a public bin directory, it's a packaging mistake. It should have been located in /usr/libexec/tomcat6 (or perhaps /var/lib/tomcat6). Be that as it may, the advice in comment #22 is correct, you should be invoking the initscript. Also you will find instructions at the top of /etc/sysconfig/tomcat6 for how to configure an instance, be sure to follow those rules.
Makes sense... thank you John and Michal. Looks like the tomcat6 packages themselves are now fine, it seems that the HA Clustering bits aren't interacting properly with /usr/sbin/tomcat6. Since this is now a resource-agents package bug in /usr/share/cluster/tomcat-6.sh, I've opened a new BZ 822244
Fixed in tomcat6-6.0.wrapper (/usr/sbin/tomcat6) Package tomcat6-6.0.24-45.el6 has passed sanity testing.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0945.html