Starting Tomcat 8.5 using systemd on Centos 7
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
New contributor
add a comment |
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
New contributor
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? Theshutdown.sh
file is also inbin
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
add a comment |
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
New contributor
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
linux centos-7 systemd tomcat
New contributor
New contributor
edited 18 hours ago
New contributor
asked 19 hours ago
john
1094
1094
New contributor
New contributor
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? Theshutdown.sh
file is also inbin
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
add a comment |
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? Theshutdown.sh
file is also inbin
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
add a comment |
1 Answer
1
active
oldest
votes
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).
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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).
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
add a comment |
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).
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
add a comment |
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).
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).
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
add a comment |
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
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 inbin
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