I tried this out in CentOS 6.2 which right now has tomcat6.noarch 6.0.24-36.el6_2

It works but not in the way that I expected, indicating that the regression is something different than I described.

In that version, doing my steps to reproduce still results in installing with /var/log/tomcat6/catalina.out not having group write permissions.

The different, working, behavior is that when I start up tomcat6 the result is that /var/log/tomcat6/catalina.out is owned by testcat:testcat instead of remaining owned by tomcat:tomcat.

In other words, the startup script or code changes the owner of catalina.out

That makes the regression not a matter of permissions when catalina.out is made, but a matter of change of ownership of that file when tomcat6 is started.

I did a more careful comparison of what is done in RedHat's tomcat6.noarch 6.0.24-45.el6 and CentOS tomcat6.noarch 6.0.24-36.el6_2 to see what the difference is between the nonworking and the working versions.

In /etc/init.d/tomcat6

In CentOS, TOMCAT_LOG is set to /var/log/tomcat6/catalina.out
In RedHat, TOMCAT_LOG is set to /var/log/tomcat6/tomcat6-initd.log

In both, there is then code to set $TOMCAT_LOG's owner to ${TOMCAT_USER}

In the CentOS version tomcat is eventually called with a command line that expands to something like

 su - ${TOMCAT_USER} -c "/usr/sbin/tomcat6 start ${TOMCAT_LOG}" >> /var/log/tomcat6/initd.log 2>&1

In /usr/sbin/tomcat6 the second argument to the script is the path of the log file to which output is appended. Since it is /var/log/tomcat6/catalina.out and the owner has been changed to be TOMCAT_USER then the permissions are fine for that.

As you can see the output for running the su command itself is appended to /var/log/tomcat6/initd.log so that file is written by root.

In the RedHat version the log file name is not passed as an argument to /usr/sbin/tomcat6. Instead /usr/sbin/tomcat6 hard codes the file name catalina.out as the file to log to.

The script is invoked with a command like

 su - ${TOMCAT_USER} -c "/usr/sbin/tomcat6 start" >> ${TOMCAT_LOG} 2>&1

In this case, TOMCAT_LOG is used to log the result of the su command, and catalina.out is the hard coded name used in /usr/sbin/tomcat6. All of the code to chown TOMCAT_LOG to TOMCAT_USER is useless because the su command itself is being run as root. The chown is required for the file that is written by /usr/sbin/tomcat6 which is running as TOMCAT_USER. But the way this is written /etc/init.d/tomcat6 can't know what log file /usr/sbin/tomcat6 is using and so can't fix its ownership. That's why the older version of tomcat in CentOS has to pass the log file name as an argument to /usr/sbin/tomcat6, so that /etc/init.d/tomcat6 can set its owner and then tell /usr/sbin/tomcat6 to use it.

I found an additional problem from the same bug that happens when updating the rpm package if tomcat6 is already properly configured to run as a user other than the default "tomcat".

I downgraded to the earliest version of tomcat that was available and crested catalina.out with the proper ownership for my setup, as would be the correct state when running Tomcat as a user other than tomcat. With tomcat6 configured to run as the testcat user instead of tomcat as described above, I did:

yum downgrade tomcat6-6.0.24-15.el6 tomcat6-admin-webapps-6.0.24-15.el6 tomcat6-lib-6.0.24-15.el6 tomcat6-webapps-6.0.24-15.el6 tomcat6-docs-webapp-6.0.24-15.el6 tomcat6-servlet-2.5-api-6.0.24-15.el6 tomcat6-el-2.1-api-6.0.24-15.el6 tomcat6-jsp-2.1-api-6.0.24-15.el6

cd /var/log/tomcat6
rm catalina.out
gunzip < catalina.out-20120729.gz > catalina.out
chown testcat:testcat catalina.out

I then updated tomcat6 to demonstrate the problem

yum update tomcat6
ls -l /var/log/tomcat6/catalina.out

Expected result: catalina.out still owned by testcat:testcat

Actual result: catalina.out owned by tomcat:tomcat with permission 644 so that service tomcat6 start shows [OK] but does not actually start, showing a permission denied error in /var/log/tomcat6/tomcat6-initd.log

This has become quite urgent for me when I realized that any existing tomcat6 configuration that uses a TOMCAT_USER other than "tomcat" is broken by doing a yum update to this version even if I have worked around the problem during installation of my applications by changing ownership of /var/log/tomcat6/catalina.out.

Partial fix: This isn't a complete way to fix the problem, but it can serve as a compact statement of the problem and the kind of thing that needs to be done.

However it leaves something still wrong: /usr/sbin/tomcat6 now hard codes the name ${CATALINA_BASE/logs/catalina.out as the name of the log file, which means that setting TOMCAT_LOG in tomcat6.conf will not result in logging to someplace other than catalina.out. That will make the following not work if tomcat6.conf sets TOMCAT_LOG to anything other than ${CATALINA_BASE/logs/catalina.out which is why I am writing this as a way of talking about the problem rather than as a real solution.

In /etc/init.d/tomcat6 revert the setting of TOMCAT_LOG to be

TOMCAT_LOG="${TOMCAT_LOG:-/var/log/tomcat6/catalina.out}"

After that add the line

TOMCAT_INITD_LOG="${TOMCAT_INITD_LOG:-/var/log/tomcat6/${NAME}-initd.log}"

Change the four lines that contain >> ${TOMCAT_LOG} to instead say >> ${TOMCAT_INITD_LOG}

Leave all the other code that makes use of TOMCAT_LOG the same, so that the correct log file gets touched and given the proper owners.

Sorry for all the comments, but I just compared CentOS and RedHat versions of tomcat6-6.0.24-15.el6 and I think I see where the bug originated.

The RedHat version 6.0.24-15.el6 has the following bug that the current version seems to try and fail to fix: /etc/init.d/tomcat6 starts tomcat by invoking the script /usr/sbin/tomcat6 redirecting the output of the invoking command line to append to $TOMCAT_LOG which defaults to /var/log/tomcat6/catalina.out if it is not set in tomcat6.conf. But /usr/sbin/tomcat6 always redirects output to append to ${CATALINA_BASE}/logs/catalina.out which breaks in two different ways. 1) It does not respect the setting of TOMCAT_LOG in tomcat6.conf and 2) If TOMCAT_LOG or CATALINA_BASE are not set to their defaults and TOMCAT_USER is not tomcat, then the ownership and permissions of catalina.out will not get set in /etc/init.d/tomcat6 and so tomcat won't start.

CentOS tomcat6-6.0.24-15.el6 fixes both problems by passing $TOMCAT_LOG as an argument to /usr/sbin/tomcat6 so it can redirect to the same log file as is used in /etc/init.d/tomcat6.

RedHat tomcat6-6.0.24-45.el6 instead uses a different file for the log output of the command line that invokes /usr/sbin/tomcat6 and the log output by the java call inside /usr/sbin/tomcat6. That doesn't properly fix problem #1, because /usr/sbin/tomcat6 still does not respect the setting of TOMCAT_LOG in tomcat6.conf. It doesn't fix problem #2 either, because all the work of changing owners of the log file that is done in /etc/init.d/tomcat6 is not done to the file that needs it, which is the log file that is used by /usr/sbin/tomcat6.

I think the correct fix for this is to modify /etc/init.d/tomcat6 and /usr/sbin/tomcat6 the way it is done in CentOS.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Hi Sidney,

We appreciate this bugzilla and the testing that you have done regarding this issue, but at this time we do not plan to include a fix for it in RHEL 6. I've looked into this a good bit and it seems that in RHEL 7 (and Fedora) that it is a non-issue because the TOMCAT_USER variable is not respected and the tomcat user always owns the tomcat process.

If this issue is causing you a significant production issue, please open a support case in the Red Hat Customer Portal.

Thanks!