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 1201409 - Fix the broken tomcat-jsvc service unit
Summary: Fix the broken tomcat-jsvc service unit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tomcat
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Coty Sutherland
QA Contact: fgoldefu
Lucie Vařáková
URL:
Whiteboard:
Depends On:
Blocks: 1298191 1313485
TreeView+ depends on / blocked
 
Reported: 2015-03-12 16:25 UTC by Enrico Tagliavini
Modified: 2019-12-16 04:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
Fix for the *tomcat-jsvc* service unit to create two independent Tomcat servers When trying to start multiple independent Tomcat servers, the second server failed to start due to the jsvc service returning an error. This update fixes the *jsvc* systemd service unit as well as the handling of the TOMCAT_USER variable.
Clone Of:
Environment:
Last Closed: 2016-11-03 21:08:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
avoid PID file name collision by adding $NAME to the file name (1.26 KB, patch)
2015-03-12 16:25 UTC, Enrico Tagliavini
no flags Details | Diff
service patch to remove ref to sysd (555 bytes, patch)
2016-01-19 17:08 UTC, Coty Sutherland
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2599 0 normal SHIPPED_LIVE Moderate: tomcat security, bug fix, and enhancement update 2016-11-03 12:12:12 UTC

Internal Links: 1341850 1341852

Description Enrico Tagliavini 2015-03-12 16:25:00 UTC
Created attachment 1001058 [details]
avoid PID file name collision by adding $NAME to the file name

Description of problem:

at the top of /usr/lib/systemd/system/tomcat-jsvc.service file it is described how to create a clone of the default tomcat-jsvc service should the user need to start multiple independent tomcat servers. If doing so starting the second server will throw an error due to jsvc PID file name collision between the two instances but each one needs its own unique PID file. The default PID file location is /var/run/jsvc.pid. Looking into /usr/sbin/tomcat-jsvc reveals no -pidfile option is passed to jsvc command and thus all instances will use the same default PID file.


Version-Release number of selected component (if applicable): tomcat-jsvc-7.0.42-8.el7_0


How reproducible: always


Steps to Reproduce:
1. yum install tomcat-jsvc
2. create a new CATALINA_BASE directory different from the default one in /usr/share/tomcat, populate the config directoy by copy the default. Change the listening port to something different from default (easiest, increment by one)
3. copy file /etc/sysconfig/tomcat in /etc/sysconfig/tomcat-example, adjust CATALINA_BASE, CATALINA_TMPDIR and CATALINA_PID
4. Copy /usr/lib/systemd/system/tomcat-jsvc.service in /etc/systemd/system/tomcat-example.service and add

Environment="SERVICE_NAME=tomcat-example"

to the [Service] section
5. Reload systemd configuration
6. start tomcat.service
7. start tomcat-example.service

Actual results:
The second service will fail to start due to jsvc throwing an error about the PID file. Sorry no exact log output for this, I'll explain later why.

Expected results:
The second service should start without errors

Additional info:
I updated the test system where I experienced the issue to RHEL 7.1 (tomcat-jsvc-7.0.54-1.el7) and /usr/sbin/tomcat-jsvc* files have been removed, however the systemd unit file referencing them still exist (I guess this was a mistake?), so I'm not able to reproduce the issue right now given the lack of the two original files. I meant to report this earlier but I got cough in a lot of other things as well.

Attached there is a copy and paste of the patch I used (be aware this might have space issues in it, and again I cannot test / fix it since the original files are missing now) to solve the problem. With such a patch applied I'm able to start two independent tomcat servers on the same virtual machine.

Comment 3 Enrico Tagliavini 2015-11-02 09:12:25 UTC
Few things changes since I reported the bug.

/usr/sbin/tomcat-jsvc-sysd and /usr/sbin/tomcat-sysd have been removed. For the latter /usr/libexec/tomcat/server is the replacement. The jsvc however still lacks a replacement and currently the service is still broken out of the box since the tomcat-jsvc.service files still references /usr/sbin/tomcat-jsvc-sysd.

I found that /usr/libexec/tomcat/functions defines run_jsvc() already and it avoids the PID collision file collision since $NAME is used in the pid file name.

What's missing is a /usr/libexec/tomcat/server-jsvc calling run_jsvc() instead of run() and a tmpfiles.d to create the reference tomcat-jsvc${NAME}.pid pidfile.

Comment 4 Enrico Tagliavini 2015-11-09 10:57:44 UTC
Small correction: it is sufficient to set USE_JSVC=true in either the systemd service file or in the sysconfig file to get JSVC.

This has one major downside with the current implementation though (didn't had it in the original red hat 7.0 implementation): it is not possible to choose the user, it is forced to be tomcat in /usr/libexec/tomcat/functions

It also has a downside compared to the current normal (non JSVC) way of starting tomcat: when using the normal startup console logs are sent to syslog journal. With JSVC it is forced to be -outfile ${CATALINA_BASE}/logs/catalina.out -errfile ${CATALINA_BASE}/logs/catalina.out

As a side note: I like the logs to be in the syslog, however it can be handy for the developers to have it in catalina.out as well so I send it in both locations using tee

    run start |& tee -a "${CATALINA_BASE}"/logs/catalina.out

Comment 5 Coty Sutherland 2016-01-19 17:08:01 UTC
Created attachment 1116275 [details]
service patch to remove ref to sysd

This patch will fix the service by removing the reference to sysd, however it still has an issue starting due to org/apache/commons/daemon/support/DaemonLoader missing. Still looking into that.

Comment 6 Coty Sutherland 2016-01-19 17:10:32 UTC
At this point, the original issue isn't relevant, but the systemd unit provided for jsvc is broken. I can fix that, but it will not change the concerns that are there for:

1) it is not possible to choose the user, it is forced to be tomcat in /usr/libexec/tomcat/functions
2) With JSVC it is forced to be -outfile ${CATALINA_BASE}/logs/catalina.out -errfile ${CATALINA_BASE}/logs/catalina.out

Once I get the service working, I can look into addressing the concerns mentioned above.

Comment 7 Ryan Sawhill 2016-05-13 18:35:36 UTC
With regards to:

  > it is not possible to choose the user, it is forced to be tomcat in /usr/libexec/tomcat/functions

This is definitely a bug. It should only set TOMCAT_USER conditionally, e.g., instead of:

  TOMCAT_USER="tomcat"

It could do:

  : ${TOMCAT_USER:="tomcat"}

(There are of course multiple ways to do that in bash; that's my personal favorite, though it's not very widely-used.)

That way, if TOMCAT_USER is changed to something else in the environment (I have a customer wanting to do this), then the run_jsvc() function will honor it.

With regards to:

  > With JSVC it is forced to be -outfile ${CATALINA_BASE}/logs/catalina.out -errfile ${CATALINA_BASE}/logs/catalina.out

Funny -- I have a customer who actually prefers this.

Comment 9 Coty Sutherland 2016-06-01 20:43:31 UTC
This bug got a little out of hand, so I've updated the title to reflect my purpose for it; this comment is also meant to refocus on the issue. The original problem that Enrico raised is no longer relevant after the unit file is fixed, so this bug is just to fix the jsvc systemd service unit and correct the hard-coding of the TOMCAT_USER variable.

As for the outfile/errofile settings, I will open a bug for it to be addressed separately. The tomcat-functions used in RHEL are the same as Fedora, so I'll check with the upstream maintainer and come up with a plan for that change, and also push the TOMCAT_USER fix upstream.

Comment 10 Coty Sutherland 2016-06-01 21:33:33 UTC
TOMCAT_USER upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1341850
outfile/errfile upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1341852

Comment 11 Enrico Tagliavini 2016-06-02 07:26:06 UTC
Thank you Coty, I appreciate

Comment 17 errata-xmlrpc 2016-11-03 21:08:19 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.

https://rhn.redhat.com/errata/RHSA-2016-2599.html


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