Bug 1080195
Summary: | tomcat-7.0.33-3.el6 won't start | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Patric Buskas <patric.buskas> |
Component: | tomcat | Assignee: | Ivan Afonichev <ivan.afonichev> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | el6 | CC: | adrien-xx-redhatbz, akurtako, chamill, elliot.kendall, ivan.afonichev, jagathvijayan, jakub, miguel.exposito, richard, richard, sgurnick, slp.vld, stevewarmerdam |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | tomcat-7.0.33-4.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-05-29 16:59:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Patric Buskas
2014-03-24 21:29:13 UTC
For the ease of people searching for this problem, here is what appears in /var/log/tomcat/tomcat-initd.log: /usr/sbin/tomcat: line 21: .: /etc/sysconfig/: is a directory /usr/sbin/tomcat: line 34: /usr/share/tomcat/logs/catalina.out: Permission denied Also, I don't believe the proposed fix in /usr/sbin/tomcat is correct. The problem is that $NAME is not set anywhere. Rather than fix that, though, the correct fix is probably to comment out all of the code involved with loading /etc/tomcat/tomcat.conf and /etc/sysconfig/$NAME. That's what's done in the official tomcat6 package, and the config in those files really only needs to be available in /etc/init.d/tomcat anyway. Same problem here on a Vanilla CentOS 6.5 with EPEL enabled. Tomcat 7 won't even start, I see exactly the same problems logged in /var/log/tomcat/tomcat-initd.log. Frankly, it's simply breathtaking that a broken package like this ended up in EPEL which "creates, maintains, and manages a high quality set of additional packages for Enterprise Linux". (In reply to Elliot Kendall from comment #1) > For the ease of people searching for this problem, here is what appears in > /var/log/tomcat/tomcat-initd.log: > > /usr/sbin/tomcat: line 21: .: /etc/sysconfig/: is a directory > /usr/sbin/tomcat: line 34: /usr/share/tomcat/logs/catalina.out: Permission > denied > > Also, I don't believe the proposed fix in /usr/sbin/tomcat is correct. The > problem is that $NAME is not set anywhere. Rather than fix that, though, the > correct fix is probably to comment out all of the code involved with loading > /etc/tomcat/tomcat.conf and /etc/sysconfig/$NAME. That's what's done in the > official tomcat6 package, and the config in those files really only needs to > be available in /etc/init.d/tomcat anyway. Thank you for adding the log messages to the bug report, it slipped my mind. The $NAME is set in the init script /etc/init.d/tomcat and that's why my change works. If it is the best/cleanest way of solving it I'm not able to say but it's working :) I successfully reproduced current bug and I am on my way to solving the problem. I committed the bugfix to my repository at https://github.com/ka2m/tomcat-centos As far as I understand there were no new commits to the upstream, so you are free to clone my version and assignee can push it update the repository. It worked out on my installation. ${NAME} was missing from the tomcat-7.0.wrapper file and the access right were error. So, thanks to Patric and Elliot for helping out with this. Assignee has contacted me and we agreed that the custom configuration section should be removed from tomcat-7.0.wrapper file as was added with systemd support. As long as this build does not support systemd, this section should not be implemented as well. Finally, you can acquire fixed version at https://github.com/ka2m/tomcat-centos or wait for confirmation. Hopefully, this is all. I used this build for my personal EC2 instance for the project I'm working on and have not faced any problems yet. Sincerely yours, Vlad Slepukhin tomcat-7.0.33-4.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/tomcat-7.0.33-4.el6 Package tomcat-7.0.33-4.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing tomcat-7.0.33-4.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1300/tomcat-7.0.33-4.el6 then log in and leave karma (feedback). Fixes the issue for me, thanks. Up'ed the update karma. Installed tomcat-7.0.33-4.el6 and it is failing to start due to missing tomcat-juli.jar lrwxrwxrwx. 1 root root 37 May 2 08:14 tomcat-juli.jar -> /usr/share/tomcat/bin/tomcat-juli.jar # rpm -qil tomcat-7.0.33-4.el6 | grep bin /usr/bin/tomcat-digest /usr/bin/tomcat-tool-wrapper /usr/sbin/dtomcat /usr/sbin/tomcat /usr/share/tomcat/bin/bootstrap.jar /usr/share/tomcat/bin/catalina-tasks.xml [vagrant@localhost ~]$ rpm -qf /usr/share/tomcat/bin/tomcat-juli.jar tomcat-lib-7.0.33-4.el6.noarch could it be that your deps are not up to date? Sorry. Yes, I had some dependency issues. I uninstalled everything and reinstalled this version and it went through fine. Thanks! This fix causes problems when you try to create/run multiple tomcat instances. Compared to the RHEL6 tomcat6 package, neither /etc/tomcat/tomcat.conf nor /etc/sysconfig/$NAME should be sourced in /usr/sbin/tomcat, as this is already done in the init script, and in that order. The change in 7.0.33-4 fixes the problem with $NAME being undefined in /usr/sbin/tomcat by no longer trying to source /etc/sysconfig/$NAME, but then some environment variables set in /etc/sysconfig/$NAME are redefined by sourcing /etc/tomcat/tomcat.conf. Removing these lines from /usr/sbin/tomcat: # Get the tomcat config (use this for environment specific settings) if [ -z "${TOMCAT_CFG}" ]; then TOMCAT_CFG="/etc/tomcat/tomcat.conf" fi if [ -r "$TOMCAT_CFG" ]; then . $TOMCAT_CFG fi would solve that problem. The /etc/sysconfig/tomcat config file documents how to create additional instances: # To change values for a specific service make your edits here. # To create a new service create a link from /etc/init.d/<your new service> to # /etc/init.d/tomcat (do not copy the init script) and make a copy of the # /etc/sysconfig/tomcat file to /etc/sysconfig/<your new service> and change # the property values so the two services won't conflict. Register the new # service in the system as usual (see chkconfig and similars). Which currently won't work. The below patch to the above init script is more in keeping with the old tomcat6 logic, just with the configuration directory moved from /etc/sysconfig/$NAME to /etc/tomcat/$NAME.conf: @@ -23,9 +23,10 @@ else exit 1 fi -# Get the tomcat config (use this for environment specific settings) +NAME=`basename $0` +# Get the tomcat process config (use this for environment specific settings) if [ -z "${TOMCAT_CFG}" ]; then - TOMCAT_CFG="/etc/tomcat/tomcat.conf" + TOMCAT_CFG="/etc/tomcat/${NAME}.conf" fi (In reply to Adrien Bustany from comment #11) > [vagrant@localhost ~]$ rpm -qf /usr/share/tomcat/bin/tomcat-juli.jar > tomcat-lib-7.0.33-4.el6.noarch > > could it be that your deps are not up to date? I'd likely categorise this as a bug. Due to the way that the epel package symlinks certain directories, if you install tomcat + tomcat-libs, then re-install the tomcat package, you end up with a broken tomcat-libs install. I'm not sure why you would move instance specific config from /etc/sysconfig/$NAME to /etc/tomcat/$NAME.conf? That just creates an extra step if you want to upgrade from the tomcat6 packages to the EPEL tomcat 7 packages. (In reply to Richard Davies from comment #16) > I'm not sure why you would move instance specific config from > /etc/sysconfig/$NAME to /etc/tomcat/$NAME.conf? > > That just creates an extra step if you want to upgrade from the tomcat6 > packages to the EPEL tomcat 7 packages. That's what the EPEL package does currently. I guess if you were doing things more the redhat way then I'd agree, environment vars would be better placed in /etc/sysconfig. The EPEL init script still reads from /etc/sysconfig/$NAME, and a comment in /etc/sysconfig/tomcat still refers to this method. For reasons of compatibility I don't see a reason to change this. Removing reading env vars from /usr/sbin/tomcat breaks this completely in release 7.0.33-4. Removing reading env vars from both /etc/tomcat/tomcat.conf and /etc/sysconfig/$NAME in /usr/sbin/tomcat is what the current tomcat6 packages in RHEL6 do. I don't know how this is handled in systemd/RHEL7 though - I think reading env vars from those files in /usr/sbin/tomcat might relate to that? oops, I mean removing reading env vars from /etc/sysconfig/$NAME breaks instances completely in 7.0.33-4, confusing myself now. *** Bug 1102179 has been marked as a duplicate of this bug. *** tomcat-7.0.33-4.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. I'm experiencing the same problems as Richard when trying to run multiple instances. In /usr/sbin/tomcat script, particular instance configurations in /etc/sysconfig/${NAME} are overwritten by general configuration in /etc/tomcat/tomcat.conf. Is there any planned action on this? Thanks I just installed tomcat-7.0.33-4.el6 and trying to set-up multiple instances. I'm not experiencing the same issue reported above where tomcat.conf is overriding /etc/sysconfig/{NAME} because I'm not able to get that far along in the init script. In the start function there is the following: ------- [ "$RETVAL" -eq "0" ] && touch $TOMCAT_LOG 2>&1 || RETVAL="4" if [ "$RETVAL" -eq "0" -a "$?" -eq "0" ]; then chown ${TOMCAT_USER}:${TOMCAT_USER} $TOMCAT_LOG fi ------- Based on the procedures provided in the /etc/sysconfig/{NAME} for setting-up a new tomcat instance, this will always result in an error and RETVAL being set to 4. At this point the new tomcat instance directory has not been created. Therefore the touch command will fail as the path defined in $TOMCAT_LOG does not yet exist. Then since RETVAL = 4 we never get into the if statement where the new instance directory is created. As a test I moved this block below the if statement where the new instance directory is created and I get further along. Is anyone else experiencing this same behavior? Thank you. Both the problem reported by 23 and by 22 remain in effect for tomcat-7.0.33-4.el6 (patching fix for 23 then reveals 22). NAME appears unavailable during execution of /usr/sbin/tomcat so I'm not able to patch that to support multiple instances. |