Bug 1080195 - tomcat-7.0.33-3.el6 won't start
Summary: tomcat-7.0.33-3.el6 won't start
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: tomcat
Version: el6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Ivan Afonichev
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1102179 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-24 21:29 UTC by Patric Buskas
Modified: 2015-11-09 19:47 UTC (History)
13 users (show)

Fixed In Version: tomcat-7.0.33-4.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-29 16:59:44 UTC
Type: Bug


Attachments (Terms of Use)

Description Patric Buskas 2014-03-24 21:29:13 UTC
Description of problem:
After installation of tomcat-7.0.33-3.el6 on CentOS 6.5 it won't start

Version-Release number of selected component (if applicable):
7.0.33-3.el6

How reproducible:
Every time

Steps to Reproduce:
1. yum install tomcat
2. service tomcat start


Actual results:
The service won't start

Expected results:
The service starts

Additional info:
After some digging I found two major problems.

First the folder /var/log/tomcat has the file mode bits 0644 and needs to be changed to 0755. I assume that has to do with the tomcat.spec file, line 531: 

%attr(0644,root,tomcat) %dir %{logdir}

The second problem is the wrapper in /usr/sbin/tomcat, line 20, that need to be changed to this: 

if [ -r "/etc/sysconfig/$NAME" ]; then 

After those changes the service will start.

Thank You! /Patric

Comment 1 Elliot Kendall 2014-04-02 23:26:37 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.

Comment 2 Jakub Skoczen 2014-04-15 10:56:51 UTC
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".

Comment 3 Patric Buskas 2014-04-16 05:37:06 UTC
(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 :)

Comment 4 Vlad Slepukhin 2014-04-16 08:05:31 UTC
I successfully reproduced current bug and I am on my way to solving the problem.

Comment 5 Vlad Slepukhin 2014-04-28 19:21:20 UTC
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.

Comment 6 Vlad Slepukhin 2014-04-28 20:25:10 UTC
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

Comment 7 Fedora Update System 2014-04-30 21:27:05 UTC
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

Comment 8 Fedora Update System 2014-05-01 18:30:18 UTC
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).

Comment 9 Adrien Bustany 2014-05-02 08:34:26 UTC
Fixes the issue for me, thanks. Up'ed the update karma.

Comment 10 jagathvijayan 2014-05-02 08:41:48 UTC
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

Comment 11 Adrien Bustany 2014-05-02 08:47:08 UTC
[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?

Comment 12 jagathvijayan 2014-05-02 08:58:12 UTC
Sorry.  Yes, I had some dependency issues.  I uninstalled everything and reinstalled this version and it went through fine.  Thanks!

Comment 13 Richard Davies 2014-05-05 22:48:27 UTC
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.

Comment 14 Richard Clark 2014-05-08 09:30:29 UTC
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

Comment 15 Richard Clark 2014-05-08 09:34:41 UTC
(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.

Comment 16 Richard Davies 2014-05-08 09:47:42 UTC
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.

Comment 17 Richard Clark 2014-05-08 13:33:06 UTC
(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.

Comment 18 Richard Davies 2014-05-08 13:41:40 UTC
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?

Comment 19 Richard Davies 2014-05-08 13:43:01 UTC
oops, I mean removing reading env vars from /etc/sysconfig/$NAME breaks instances completely in 7.0.33-4, confusing myself now.

Comment 20 Ivan Afonichev 2014-05-28 16:04:58 UTC
*** Bug 1102179 has been marked as a duplicate of this bug. ***

Comment 21 Fedora Update System 2014-05-29 16:59:44 UTC
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.

Comment 22 Miguel Expósito 2015-02-14 10:03:08 UTC
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

Comment 23 Stephen Gurnick 2015-02-18 22:36:55 UTC
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.

Comment 24 stevewarmerdam 2015-11-09 19:47:39 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.