jts linux service fails
CLM 6.0.0 Patch 2
OS: Linux
I am trying to configure the JTS process as a service via Upstart. When starting the service with the command: sudo start JTS, I hit an error in catalina.out file:
java.util.zip.ZipException: Exception in opening zip file: /opt/IBM/JazzTeamServer/server/tomcat/work/Catalina/localhost/qm/eclipse/configuration/org.eclipse.osgi/bundles/418/1/bundlefile
BUT, if I run the process manually using server.startup it works like a charm.
My conf file is
description "JTS"
start on startup
start on runlevel [2345]
stop on runlevel [!2345]
post-start script
cd /opt/IBM/JazzTeamServer/server
exec ./server.startup
end script
post-stop script
cd /opt/IBM/JazzTeamServer/server
exec ./server.shutdown
end script
|
Accepted answer
I didn't figure it out, so I am running the command as root instead.
exec su root -c "ulimit -n 65536;ulimit -u 10000;/opt/IBM/JazzTeamServer/server/server.startup"
Ralph Schoon selected this answer as the correct answer
|
3 other answers
Fixed the problem. The service needs some environment variables to be set.
|
Please state which Environment variables had to be set so that Upstart could start your Jts service.
|
With Ubuntu's shift from Upstart to Systemd for system services management in 16.04, I refactored my Upstart script into a systemd script for JTS. Several useful capabilities in systemd that are lacking in Upstart are the ability to set resource limits for the monitored daemons and to track a daemon's claimed process identifier through its own pid file.
The result is that a short *.service file for JTS can better handle server.startup than could be done with Upstart and its "expect fork|daemon" stanza.
Note too that start-stop-daemon does not participate in PAM and both Upstart and systemd do not either. This means that as admins we have to figure out other ways to grant server.start and its children greater resource limits.
Here's the Service stanza from my working systemd jts.service file:
[Service] ExecStart=<%= @jtsPath %>/server/server.startup ExecStop=<%= @jtsPath %>/server/server.shutdown Type=forking PIDFile=<%= @jtsPath %>/server/liberty/servers/.pid/clm.pid User=vagrant Group=vagrant WorkingDirectory=<%= @jtsPath %>/server LimitNOFILE=65535:65535 LimitNPROC=10000:10000 Comments
Lonnie VanZandt
commented Sep 04 '16, 3:35 p.m.
(This is a template that vagrant chef populates, replacing jtsPath with the actual deployment path. Don't just copy the text above and expect that systemd will do anything with text like "<%= @someVar %>".)
Liora Milbaum
commented Sep 04 '16, 3:38 p.m.
Thanks the info. i am using chef as well.
Can you share the whole cookbook?
Lonnie VanZandt
commented Sep 04 '16, 3:47 p.m.
I can share parts of it but the entire "menu" of recipes is a Sodius service as product. For example, I have a public recipe to set up a DB2 server so that it is Jazz-ready but configuration of Jazz with DB2 is a product, not open source.
Lonnie VanZandt
commented Sep 04 '16, 3:48 p.m.
Here's the little routine chef template resource use that uses the above template to make a systemd service for a deployed JTS environment. (Getting to that deployed JTS environment takes a few more recipes and tearing of hair.)
Liora Milbaum
commented Sep 04 '16, 3:50 p.m.
Thanks. I will check it soon.
Let me know if you require any other routine. I am almost hairless :-)
Liora Milbaum
commented Sep 04 '16, 4:05 p.m.
Good to know. Where can I find more info about Sodius product?
Lonnie VanZandt
commented Sep 04 '16, 4:06 p.m.
You will likely want a chef "service" resource later in your recipe that starts this JTS service through the systemd methods. I am using:
Lonnie VanZandt
commented Sep 04 '16, 4:07 p.m.
Because I tell it which provider, it may no longer be necessary to tell it the start and stop commands; the Systemd provider SHOULD know how systemctl works.
Liora Milbaum
commented Sep 04 '16, 4:33 p.m.
Thanks Lonnie. Seems like a great job on your part.
showing 5 of 9
show 4 more comments
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Running server.startup as a root doesn't produce the errors