Starting Tomcat 8.5 using systemd on Centos 7












0














I installed Tomcat 8.5 and I am able to start it successfully manually, for example:



su tomcat startup.sh


works properly and tomcat is able to serve on port 8080.



I need to automate the startup, so I created the file /etc/systemd/system/tomcat-prod.service:



[Unit]
Description=Tomcat 8.5 servlet container - Production
After=network.target

[Service]
Type=forking

ExecStart=/opt/appservers/production/apache-tomcat-8.5.37/bin/startup.sh
ExecStop=/opt/appservers/production/apache-tomcat-8.5.37/bin/shutdown.sh

User=tomcat
Group=tomcat

[Install]
WantedBy=multi-user.target


The file is bare on purpose, all my env variables are in setenv.sh. I tried running it using:



# systemctl daemon-reload
# systemctl start tomcat-prod


For some reason above results in Tomcat exiting just after startup. I get no log anywhere that explains why. Tomcat creates an empty catalina.out file on startup and systemctl status tomcat-prod gives only the following:




tomcat-prod.service - Tomcat 8.5 servlet container - Production
Loaded: loaded (/etc/systemd/system/tomcat-prod.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2019-01-04 08:08:27 UTC; 3s ago
Process: 3583 ExecStop=/opt/appservers/production/apache-tomcat-8.5.37/shutdown.sh (code=exited, status=203/EXEC)
Process: 3569 ExecStart=/opt/appservers/production/apache-tomcat-8.5.37/bin/startup.sh (code=exited, status=0/SUCCESS)
Main PID: 3581 (code=exited, status=0/SUCCESS)



Jan 04 08:08:27 *.net startup.sh[3569]: Existing PID file found during start.
Jan 04 08:08:27 *.net startup.sh[3569]: Removing/clearing stale PID file.




Can someone point me in the right direction?










share|improve this question









New contributor




john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • I love down votes without a comment to explain why ...
    – john
    19 hours ago










  • Can you please try it with the envs added to the .service file? Does the same error occur? The shutdown.sh file is also in bin directory, if you haven't moved it.
    – Aulis Ronkainen
    19 hours ago










  • @AulisRonkainen the /bin was a typo above, corrected. It was correct in the actual script. I tried moving the env into the script but the result is the same. No log and it does not start.
    – john
    18 hours ago
















0














I installed Tomcat 8.5 and I am able to start it successfully manually, for example:



su tomcat startup.sh


works properly and tomcat is able to serve on port 8080.



I need to automate the startup, so I created the file /etc/systemd/system/tomcat-prod.service:



[Unit]
Description=Tomcat 8.5 servlet container - Production
After=network.target

[Service]
Type=forking

ExecStart=/opt/appservers/production/apache-tomcat-8.5.37/bin/startup.sh
ExecStop=/opt/appservers/production/apache-tomcat-8.5.37/bin/shutdown.sh

User=tomcat
Group=tomcat

[Install]
WantedBy=multi-user.target


The file is bare on purpose, all my env variables are in setenv.sh. I tried running it using:



# systemctl daemon-reload
# systemctl start tomcat-prod


For some reason above results in Tomcat exiting just after startup. I get no log anywhere that explains why. Tomcat creates an empty catalina.out file on startup and systemctl status tomcat-prod gives only the following:




tomcat-prod.service - Tomcat 8.5 servlet container - Production
Loaded: loaded (/etc/systemd/system/tomcat-prod.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2019-01-04 08:08:27 UTC; 3s ago
Process: 3583 ExecStop=/opt/appservers/production/apache-tomcat-8.5.37/shutdown.sh (code=exited, status=203/EXEC)
Process: 3569 ExecStart=/opt/appservers/production/apache-tomcat-8.5.37/bin/startup.sh (code=exited, status=0/SUCCESS)
Main PID: 3581 (code=exited, status=0/SUCCESS)



Jan 04 08:08:27 *.net startup.sh[3569]: Existing PID file found during start.
Jan 04 08:08:27 *.net startup.sh[3569]: Removing/clearing stale PID file.




Can someone point me in the right direction?










share|improve this question









New contributor




john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • I love down votes without a comment to explain why ...
    – john
    19 hours ago










  • Can you please try it with the envs added to the .service file? Does the same error occur? The shutdown.sh file is also in bin directory, if you haven't moved it.
    – Aulis Ronkainen
    19 hours ago










  • @AulisRonkainen the /bin was a typo above, corrected. It was correct in the actual script. I tried moving the env into the script but the result is the same. No log and it does not start.
    – john
    18 hours ago














0












0








0







I installed Tomcat 8.5 and I am able to start it successfully manually, for example:



su tomcat startup.sh


works properly and tomcat is able to serve on port 8080.



I need to automate the startup, so I created the file /etc/systemd/system/tomcat-prod.service:



[Unit]
Description=Tomcat 8.5 servlet container - Production
After=network.target

[Service]
Type=forking

ExecStart=/opt/appservers/production/apache-tomcat-8.5.37/bin/startup.sh
ExecStop=/opt/appservers/production/apache-tomcat-8.5.37/bin/shutdown.sh

User=tomcat
Group=tomcat

[Install]
WantedBy=multi-user.target


The file is bare on purpose, all my env variables are in setenv.sh. I tried running it using:



# systemctl daemon-reload
# systemctl start tomcat-prod


For some reason above results in Tomcat exiting just after startup. I get no log anywhere that explains why. Tomcat creates an empty catalina.out file on startup and systemctl status tomcat-prod gives only the following:




tomcat-prod.service - Tomcat 8.5 servlet container - Production
Loaded: loaded (/etc/systemd/system/tomcat-prod.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2019-01-04 08:08:27 UTC; 3s ago
Process: 3583 ExecStop=/opt/appservers/production/apache-tomcat-8.5.37/shutdown.sh (code=exited, status=203/EXEC)
Process: 3569 ExecStart=/opt/appservers/production/apache-tomcat-8.5.37/bin/startup.sh (code=exited, status=0/SUCCESS)
Main PID: 3581 (code=exited, status=0/SUCCESS)



Jan 04 08:08:27 *.net startup.sh[3569]: Existing PID file found during start.
Jan 04 08:08:27 *.net startup.sh[3569]: Removing/clearing stale PID file.




Can someone point me in the right direction?










share|improve this question









New contributor




john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I installed Tomcat 8.5 and I am able to start it successfully manually, for example:



su tomcat startup.sh


works properly and tomcat is able to serve on port 8080.



I need to automate the startup, so I created the file /etc/systemd/system/tomcat-prod.service:



[Unit]
Description=Tomcat 8.5 servlet container - Production
After=network.target

[Service]
Type=forking

ExecStart=/opt/appservers/production/apache-tomcat-8.5.37/bin/startup.sh
ExecStop=/opt/appservers/production/apache-tomcat-8.5.37/bin/shutdown.sh

User=tomcat
Group=tomcat

[Install]
WantedBy=multi-user.target


The file is bare on purpose, all my env variables are in setenv.sh. I tried running it using:



# systemctl daemon-reload
# systemctl start tomcat-prod


For some reason above results in Tomcat exiting just after startup. I get no log anywhere that explains why. Tomcat creates an empty catalina.out file on startup and systemctl status tomcat-prod gives only the following:




tomcat-prod.service - Tomcat 8.5 servlet container - Production
Loaded: loaded (/etc/systemd/system/tomcat-prod.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2019-01-04 08:08:27 UTC; 3s ago
Process: 3583 ExecStop=/opt/appservers/production/apache-tomcat-8.5.37/shutdown.sh (code=exited, status=203/EXEC)
Process: 3569 ExecStart=/opt/appservers/production/apache-tomcat-8.5.37/bin/startup.sh (code=exited, status=0/SUCCESS)
Main PID: 3581 (code=exited, status=0/SUCCESS)



Jan 04 08:08:27 *.net startup.sh[3569]: Existing PID file found during start.
Jan 04 08:08:27 *.net startup.sh[3569]: Removing/clearing stale PID file.




Can someone point me in the right direction?







linux centos-7 systemd tomcat






share|improve this question









New contributor




john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 18 hours ago





















New contributor




john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 19 hours ago









john

1094




1094




New contributor




john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






john is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • I love down votes without a comment to explain why ...
    – john
    19 hours ago










  • Can you please try it with the envs added to the .service file? Does the same error occur? The shutdown.sh file is also in bin directory, if you haven't moved it.
    – Aulis Ronkainen
    19 hours ago










  • @AulisRonkainen the /bin was a typo above, corrected. It was correct in the actual script. I tried moving the env into the script but the result is the same. No log and it does not start.
    – john
    18 hours ago


















  • I love down votes without a comment to explain why ...
    – john
    19 hours ago










  • Can you please try it with the envs added to the .service file? Does the same error occur? The shutdown.sh file is also in bin directory, if you haven't moved it.
    – Aulis Ronkainen
    19 hours ago










  • @AulisRonkainen the /bin was a typo above, corrected. It was correct in the actual script. I tried moving the env into the script but the result is the same. No log and it does not start.
    – john
    18 hours ago
















I love down votes without a comment to explain why ...
– john
19 hours ago




I love down votes without a comment to explain why ...
– john
19 hours ago












Can you please try it with the envs added to the .service file? Does the same error occur? The shutdown.sh file is also in bin directory, if you haven't moved it.
– Aulis Ronkainen
19 hours ago




Can you please try it with the envs added to the .service file? Does the same error occur? The shutdown.sh file is also in bin directory, if you haven't moved it.
– Aulis Ronkainen
19 hours ago












@AulisRonkainen the /bin was a typo above, corrected. It was correct in the actual script. I tried moving the env into the script but the result is the same. No log and it does not start.
– john
18 hours ago




@AulisRonkainen the /bin was a typo above, corrected. It was correct in the actual script. I tried moving the env into the script but the result is the same. No log and it does not start.
– john
18 hours ago










1 Answer
1






active

oldest

votes


















2














Systemd keeps track of the "main process" of every service, so that it could accurately know whether the service is still alive or not. When the main process exits, the service manager assumes that the service has crashed or just stopped on its own. And when the service has stopped, all its leftover processes are automatically killed, to provide a clean state for future starts.



For Type=forking services, determining which is the "main" process can be somewhat difficult, especially when it's hidden behind layers and layers and layers of shell scripts. The default heuristics in systemd work well for regular daemons, but in your case they likely misdetect one of those shellscript layers as the main process, instead of tomcat itself. So as soon as the script ends, the service is assumed to have stopped and its leftovers (including the real daemon) are killed.



You have two options:




  • Explicitly specify the main process using a "pidfile". This is the traditional method used by SysVinit. Your startup scripts already store the Tomcat daemon's process ID in some file, so your tomcat.service unit needs to reference it using the PIDFile= option. With this, the service manager will not need autodetection heuristics and will just track the provided PID as the main process.


  • Get rid of the shellscripts entirely and start Tomcat directly from the ExecStart= option. This is the recommended method for systemd, and you can find example .service units already written by various distributions' packagers. For example, Arch Linux (Tomcat 8 with Jsvc).







share|improve this answer























  • All this makes sense, thx. First time i encountered systemd, upgrading from old distribution with chkconfig.
    – john
    18 hours ago










  • Well, that solved it.
    – john
    18 hours ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});






john is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1390419%2fstarting-tomcat-8-5-using-systemd-on-centos-7%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














Systemd keeps track of the "main process" of every service, so that it could accurately know whether the service is still alive or not. When the main process exits, the service manager assumes that the service has crashed or just stopped on its own. And when the service has stopped, all its leftover processes are automatically killed, to provide a clean state for future starts.



For Type=forking services, determining which is the "main" process can be somewhat difficult, especially when it's hidden behind layers and layers and layers of shell scripts. The default heuristics in systemd work well for regular daemons, but in your case they likely misdetect one of those shellscript layers as the main process, instead of tomcat itself. So as soon as the script ends, the service is assumed to have stopped and its leftovers (including the real daemon) are killed.



You have two options:




  • Explicitly specify the main process using a "pidfile". This is the traditional method used by SysVinit. Your startup scripts already store the Tomcat daemon's process ID in some file, so your tomcat.service unit needs to reference it using the PIDFile= option. With this, the service manager will not need autodetection heuristics and will just track the provided PID as the main process.


  • Get rid of the shellscripts entirely and start Tomcat directly from the ExecStart= option. This is the recommended method for systemd, and you can find example .service units already written by various distributions' packagers. For example, Arch Linux (Tomcat 8 with Jsvc).







share|improve this answer























  • All this makes sense, thx. First time i encountered systemd, upgrading from old distribution with chkconfig.
    – john
    18 hours ago










  • Well, that solved it.
    – john
    18 hours ago
















2














Systemd keeps track of the "main process" of every service, so that it could accurately know whether the service is still alive or not. When the main process exits, the service manager assumes that the service has crashed or just stopped on its own. And when the service has stopped, all its leftover processes are automatically killed, to provide a clean state for future starts.



For Type=forking services, determining which is the "main" process can be somewhat difficult, especially when it's hidden behind layers and layers and layers of shell scripts. The default heuristics in systemd work well for regular daemons, but in your case they likely misdetect one of those shellscript layers as the main process, instead of tomcat itself. So as soon as the script ends, the service is assumed to have stopped and its leftovers (including the real daemon) are killed.



You have two options:




  • Explicitly specify the main process using a "pidfile". This is the traditional method used by SysVinit. Your startup scripts already store the Tomcat daemon's process ID in some file, so your tomcat.service unit needs to reference it using the PIDFile= option. With this, the service manager will not need autodetection heuristics and will just track the provided PID as the main process.


  • Get rid of the shellscripts entirely and start Tomcat directly from the ExecStart= option. This is the recommended method for systemd, and you can find example .service units already written by various distributions' packagers. For example, Arch Linux (Tomcat 8 with Jsvc).







share|improve this answer























  • All this makes sense, thx. First time i encountered systemd, upgrading from old distribution with chkconfig.
    – john
    18 hours ago










  • Well, that solved it.
    – john
    18 hours ago














2












2








2






Systemd keeps track of the "main process" of every service, so that it could accurately know whether the service is still alive or not. When the main process exits, the service manager assumes that the service has crashed or just stopped on its own. And when the service has stopped, all its leftover processes are automatically killed, to provide a clean state for future starts.



For Type=forking services, determining which is the "main" process can be somewhat difficult, especially when it's hidden behind layers and layers and layers of shell scripts. The default heuristics in systemd work well for regular daemons, but in your case they likely misdetect one of those shellscript layers as the main process, instead of tomcat itself. So as soon as the script ends, the service is assumed to have stopped and its leftovers (including the real daemon) are killed.



You have two options:




  • Explicitly specify the main process using a "pidfile". This is the traditional method used by SysVinit. Your startup scripts already store the Tomcat daemon's process ID in some file, so your tomcat.service unit needs to reference it using the PIDFile= option. With this, the service manager will not need autodetection heuristics and will just track the provided PID as the main process.


  • Get rid of the shellscripts entirely and start Tomcat directly from the ExecStart= option. This is the recommended method for systemd, and you can find example .service units already written by various distributions' packagers. For example, Arch Linux (Tomcat 8 with Jsvc).







share|improve this answer














Systemd keeps track of the "main process" of every service, so that it could accurately know whether the service is still alive or not. When the main process exits, the service manager assumes that the service has crashed or just stopped on its own. And when the service has stopped, all its leftover processes are automatically killed, to provide a clean state for future starts.



For Type=forking services, determining which is the "main" process can be somewhat difficult, especially when it's hidden behind layers and layers and layers of shell scripts. The default heuristics in systemd work well for regular daemons, but in your case they likely misdetect one of those shellscript layers as the main process, instead of tomcat itself. So as soon as the script ends, the service is assumed to have stopped and its leftovers (including the real daemon) are killed.



You have two options:




  • Explicitly specify the main process using a "pidfile". This is the traditional method used by SysVinit. Your startup scripts already store the Tomcat daemon's process ID in some file, so your tomcat.service unit needs to reference it using the PIDFile= option. With this, the service manager will not need autodetection heuristics and will just track the provided PID as the main process.


  • Get rid of the shellscripts entirely and start Tomcat directly from the ExecStart= option. This is the recommended method for systemd, and you can find example .service units already written by various distributions' packagers. For example, Arch Linux (Tomcat 8 with Jsvc).








share|improve this answer














share|improve this answer



share|improve this answer








edited 17 hours ago

























answered 18 hours ago









grawity

233k36492547




233k36492547












  • All this makes sense, thx. First time i encountered systemd, upgrading from old distribution with chkconfig.
    – john
    18 hours ago










  • Well, that solved it.
    – john
    18 hours ago


















  • All this makes sense, thx. First time i encountered systemd, upgrading from old distribution with chkconfig.
    – john
    18 hours ago










  • Well, that solved it.
    – john
    18 hours ago
















All this makes sense, thx. First time i encountered systemd, upgrading from old distribution with chkconfig.
– john
18 hours ago




All this makes sense, thx. First time i encountered systemd, upgrading from old distribution with chkconfig.
– john
18 hours ago












Well, that solved it.
– john
18 hours ago




Well, that solved it.
– john
18 hours ago










john is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















john is a new contributor. Be nice, and check out our Code of Conduct.













john is a new contributor. Be nice, and check out our Code of Conduct.












john is a new contributor. Be nice, and check out our Code of Conduct.
















Thanks for contributing an answer to Super User!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1390419%2fstarting-tomcat-8-5-using-systemd-on-centos-7%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

is 'sed' thread safe

How to make a Squid Proxy server?