RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 989527 - service status command fails for some renamed tomcat6 based services
Summary: service status command fails for some renamed tomcat6 based services
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: tomcat6
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: David Knox
QA Contact: tomcat-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-29 12:52 UTC by Leticia Konno
Modified: 2018-12-03 19:27 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-21 23:52:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1721 0 normal SHIPPED_LIVE tomcat6 bug fix update 2013-11-20 21:51:34 UTC

Description Leticia Konno 2013-07-29 12:52:17 UTC
Description of problem:

service command status fails if multiple tomcats are configured as described in /etc/sysconfig/tomcat6  and the service name is different from the tomcat directory (CATALINA_BASE). 

/etc/sysconfig/tomcat6:

# To create a new service create a link from /etc/init.d/<your new service> to
# /etc/init.d/tomcat6 (do not copy the init script) and make a copy of the
# /etc/sysconfig/tomcat6 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).

Version-Release number of selected component (if applicable):

tomcat6

How reproducible:

Steps to Reproduce:
1. Create a softlink of the tomcat6 startup script:

cd /etc/rc.d/init.d  
ln -s tomcat6 tomcat6-custom

cd /etc/sysconfig  
cp tomcat6 tomcat6-custom

2. Edit /etc/sysconfig/tomcat6-custom 

CATALINA_BASE="/usr/share/tomcat6-dir"  
CATALINA_HOME="/usr/share/tomcat6"  
CATALINA_PID="/var/run/tomcat6-custom.pid"  

Actual results:

After start the service:

service tomcat6-custom status 
tomcat6-custom lockfile exists but process is not running  [FAILED] 

Expected results:

service tomcat6-custom status 
tomcat6-custom (pid 8400) is running...


Additional info:

function checklockfile()
{
   if [ -f /var/lock/subsys/${NAME} ]; then
      pid="$(/usr/bin/pgrep -u ${TOMCAT_USER} -f ${NAME})"
# The lockfile exists but the process is not running
      if [ -z "$pid" ]; then
         RETVAL="2"
      fi
   fi
}

pgrep will not return a pid as the ${NAME} is the service name and not the tomcat6 directory name. A suggestions is to use the CATALINA_BASE instead to assume that it is the same name of the service.

Comment 2 David Knox 2013-08-12 18:39:59 UTC
The full patch:

diff --git a/tomcat6-6.0.init b/tomcat6-6.0.init
index 3d59e7b..a1e7e83 100644
--- a/tomcat6-6.0.init
+++ b/tomcat6-6.0.init
@@ -66,6 +66,9 @@ TOMCAT_PROG="${NAME}"
 # Define the tomcat username
 TOMCAT_USER="${TOMCAT_USER:-tomcat}"

+# Define the tomcat group
+TOMCAT_GROUP="${TOMCAT_GROUP:-tomcat}"
+
 # Define the tomcat log file
 TOMCAT_LOG="${TOMCAT_LOG:-/var/log/${NAME}-initd.log}"

@@ -122,7 +125,7 @@ function start() {
     # fix permissions on the log and pid files
     touch $CATALINA_PID 2>&1 || RETVAL="4"
     if [ "$RETVAL" -eq "0" -a "$?" -eq "0" ]; then
-      chown ${TOMCAT_USER}:${TOMCAT_USER} $CATALINA_PID
+      chown ${TOMCAT_USER}:${TOMCAT_GROUP} $CATALINA_PID
     fi
     if [ "$?" != "0" ]; then
        RETVAL="4"
@@ -200,7 +203,7 @@ function status()
       if [ "$RETVAL" -eq "2" ]; then
          log_failure_msg "${NAME} lockfile exists but process is not running"
       else
-         pid="$(/usr/bin/pgrep -u ${TOMCAT_USER} -f ${NAME})"
+         pid="$(/usr/bin/pgrep -d , -u ${TOMCAT_USER} -G ${TOMCAT_GROUP} java)"
          if [ -z "$pid" ]; then
              log_success_msg "${NAME} is stopped"
              RETVAL="3"
@@ -215,7 +218,7 @@ function status()
 function checklockfile()
 {
    if [ -f /var/lock/subsys/${NAME} ]; then
-      pid="$(/usr/bin/pgrep -u ${TOMCAT_USER} -f ${NAME})"
+      pid="$(/usr/bin/pgrep -d , -u ${TOMCAT_USER} -G ${TOMCAT_GROUP} java)"
 # The lockfile exists but the process is not running
       if [ -z "$pid" ]; then
          RETVAL="2"
@@ -230,6 +233,7 @@ function checkpidfile()
       if [ -d "/proc/${kpid}" ]; then
 # The pid file exists and the process is running
           RETVAL="0"
+         return
       else
 # The pid file exists but the process is not running
          RETVAL="1"

Comment 6 mistkerl473 2013-10-23 10:17:14 UTC
The patch will solve the problem, but there's another one:
pgrep will catch all java processes running as user tomcat and group tomcat. So, if no PID file is available, you will not get the PID of your instance, but all running tomcat PIDs.

I think that the last directory of $CATALINA_BASE should be identical to the instance name $NAME, otherwise there's no chance to determine the correct PID if no PID file is available.

Assuming that the last directory of $CATALINA_BASE is the instance name ${NAME}, we can use pgrep with $NAME as the pattern.
The problem is: pgrep matches all processes that have the given pattern anywhere in between.
Example: You have two tomcat instances, tomcat6-custom and tomcat6-custom2.
A "service tomcat6-custom status" will return 2 PIDs, because pgrep matches both processes.

To solve this problem, I have replaced both occurences of pgrep:
-pid="$(/usr/bin/pgrep -u ${TOMCAT_USER} -f ${NAME})"
+pid="$(/usr/bin/pgrep -u ${TOMCAT_USER} -fx .*${NAME}\ .*)"

pgrep -x does an exact match.

Comment 7 errata-xmlrpc 2013-11-21 23:52:03 UTC
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-2013-1721.html


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