Bug 1201409
| Summary: | Fix the broken tomcat-jsvc service unit | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Enrico Tagliavini <enrico.tagliavini> | ||||||
| Component: | tomcat | Assignee: | Coty Sutherland <csutherl> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | fgoldefu | ||||||
| Severity: | unspecified | Docs Contact: | Lucie Vařáková <lmanasko> | ||||||
| Priority: | medium | ||||||||
| Version: | 7.0 | CC: | mbabacek, rhatlapa, rsawhill | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| 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.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-11-03 21:08:19 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: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1298191, 1313485 | ||||||||
| Attachments: |
|
||||||||
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.
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
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.
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.
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.
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. 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 Thank you Coty, I appreciate 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 |
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.