Starting, Stopping, and Restarting Tomcat - Tomcat - The Definitive Guide, 2nd Edition (Book)
Starting, Stopping, and Restarting Tomcat - Tomcat - The Definitive Guide, 2nd Edition (Book)
See everything available through the O’Reilly learning platform and s Search
Tomcat: The Definitive Guide, 2nd Edition by Jason Brittain, Ian F. Dar…
about each of these package-specific cases are given in the next several sections.
Request a Demo ▶️
If you installed Tomcat by downloading the binary release archive (.zip or .tar.gz)
from the Tomcat downloads page—what we'll callThis
the generic installation case—
chat may be recorded for quality assurance. You
can view our privacy policy here
you should use the command-line scripts that reside in the CATALINA_HOME/bin
directory.
There are several scripts in the bin directory that you will use for starting and
SIGN IN TRY NOW
stopping Tomcat. All the scripts you will need to invoke directly are provided
both as shell script files for Unix (.sh) and batch files for Windows (.bat). Table 1-1
lists these scripts and describes each. When referring to these, we have omitted
the filename extension because catalina.bat has the same meaning for Microsoft
Windows users that catalina.sh[3] has for Unix users. Therefore, the name in the
table appears simply as catalina. You can infer the appropriate file extension for
your system.
Script Purpose
catalina The main Tomcat script. This runs the java command to invoke
the Tomcat startup and shutdown classes.
cpappend This is used internally, and then only on Windows systems, to ap-
pend items to Tomcat classpath environment variables.
set‐ This is also only used internally and sets the Tomcat classpath and
class‐ several other environment variables.
path
Script Purpose SIGN IN TRY NOW
version This runs the catalina version, which outputs Tomcat's version
information.
The main script, catalina, is invoked with one of several arguments. The most
common arguments are start, run, or stop. When invoked with start (as it is
when called from startup), it starts up Tomcat with the standard output and stan-
dard error streams directed into the file CATALINA_HOME/logs/catalina.out. The
run argument causes Tomcat to leave the standard output and error streams
where they currently are (such as to the console window) useful for running from
a terminal when you want to see the startup output. This output should look sim-
ilar to Example 1-1.
If you use catalina with the start option or invoke the startup script instead of
using the run argument, you see only the first few Using... lines on your con-
sole; all the rest of the output is redirected into the catalina.out logfile. The
shutdown script invokes catalina with the argument stop, which causes Tomcat to
connect to the default port specified in your Server element (discussed in
Chapter 7) and send it a shutdown message. A complete list of startup options is
listed in Table 1-2.
start This starts up Tomcat, with standard output and errors going to
the Tomcat logfiles.
Environment variables
This will run a class file called MyProg with a maximum memory size of 256 MB
for the entire Java runtime process.
These options become important when using Tomcat, as running servlets can be-
gin to take up a lot of memory in your Java environment. To pass this or any other
option into the java command that is used to start Tomcat, you can set the op-
tion in the environment variable JAVA_OPTS before running one of the Tomcat
startup scripts.
Windows users should set this environment variable from the Control Panel, and
Unix users should set it directly in a shell prompt or login script:
$ export JAVA_OPTS="-Xmx256M" # Korn and Bourne shell
SIGN IN TRY NOW
C:\> set JAVA_OPTS="-Xmx256M" # MS-DOS
$ setenv JAVA_OPTS "-Xmx256M" # C-shell
Other Tomcat environment variables you can set are listed in Table 1-3.
If you have installed Tomcat via an Apache binary release archive (either a .zip file
or a .tar.gz file), change directory into the directory where you installed Tomcat:
$ cd apache-tomcat-6.0.14
Echo your $JAVA_HOME environment variable. Make sure it's set to the absolute
path of the directory where the Java installation you want Tomcat to use resides.
If it's not, set it and export it now. It's OK if the java interpreter is not on your
$PATH because Tomcat's scripts are smart enough to find and use Java based on
your setting of $JAVA_HOME.
Make sure you're not running a TCP server on port 8080 (the default Tomcat
HTTP server socket port), nor on TCP port 8005 (the default Tomcat shutdown
server socket port). Try running telnet localhost 8080 and telnet localhost 8005 to
see if any existing server accepts a connection, just to be sure.
$ bin/startup.sh
Using CATALINA_BASE: /home/jasonb/apache-tomcat-6.0.14
Using CATALINA_HOME: /home/jasonb/apache-tomcat-6.0.14
Using CATALINA_TMPDIR: /home/jasonb/apache-tomcat-6.0.14/temp
Using JAVA_HOME: /usr/java/jdk1.6.0_02
You should see output similar to this when Tomcat starts up. Once started, it
should be able to serve web pages on port 8080 (if the server is localhost, try
http://localhost:8080 in your web browser).
$ bin/shutdown.sh
Using CATALINA_BASE: /home/jasonb/apache-tomcat-6.0.14
Using CATALINA_HOME: /home/jasonb/apache-tomcat-6.0.14
Using CATALINA_TMPDIR: /home/jasonb/apache-tomcat-6.0.14/temp
Using JAVA_HOME: /usr/java/jdk1.6.0_02 SIGN IN TRY NOW
If you've installed Tomcat via the RPM package on Linux, you can test it out by is-
suing a start command via Tomcat's init script, like this:
# /etc/rc.d/init.d/tomcat start
Starting tomcat: [ OK ]
Or, on some Linux distributions, such as Fedora and Red Hat, to do the same
thing, you may instead type the shorter command:
If you installed the JPackage.org Tomcat RPM package, the name of the init
script is tomcat55, so the command would be:
# /etc/rc.d/init.d/tomcat55 start
You should see several Java processes scroll by. Another way to see whether
Tomcat is running is to request a web page from the server over TCP port 8080.
Tip
If Tomcat fails to startup correctly, go back and make sure that the
/opt/tomcat/conf/tomcat-env.sh file has all the right settings for your server computer (in
the JPackage.org RPM installation case, it's the /etc/tomcat55/tomcat55.conf file). Also
check out the "Common Errors" section, later in this chapter. SIGN IN TRY NOW
# /etc/rc.d/init.d/tomcat stop
Or (shorter):
# /etc/init.d/cswtomcat5 start
# /etc/init.d/cswtomcat5 stop
Apache Tomcat/6.0.14
^C
Stopping service Tomcat-Standalone
C:\>
If the graceful shutdown does not work, you need to find the running process and
terminate it. The JVM running Tomcat will usually be identified as a Java process;
be sure you get the correct Java if other people or systems may be using Java.
Use Ctrl-Alt-Delete to get to the task manager, select the correct Java process,
and click on End Task.
Mac OS X sets all your paths for you so all you need to do is ensure that there are
no TCP services already running on port 8080 (the default Tomcat HTTP server
socket port), nor on port 8005 (the default Tomcat shutdown port). This can be
done easily by running the netstat command:
You should see no output. If you do, it means another program is listening on
port 8080, and you should shut it down first, or you must change the port num-
bers in your CATALINA_HOME/conf/server.xml configuration file. Do the same for
port 8005.
Because the user nobody is an unprivileged user, a lot of folders on your disk are
not accessible to it. This is of course a good thing, but because the scripts for
starting and stopping Tomcat attempt to determine the current directory, you
will get errors if the scripts are not being called from a folder to which the user
nobody has read access. To avoid this, the above commands consist of three sub-
commands. First, they change to the root folder (/), next they call script to start
or stop Tomcat as the user nobody, and finally they return to the folder they
started in. If you are running the commands from a folder to which the user no‐
body has read access (e.g., /), you can shorten the commands by leaving out the
first and last parts as follows:
Later in the "Automatic Startup on Mac OS X" section, we show you how to create
and install init scripts via Apple's launchd, as you see in the Linux RPM installa-
tions and the BSD port installs, to allow you to not only start and stop Tomcat,
but also to automatically start Tomcat on boot—the Mac OS X way!
# /usr/local/etc/rc.d/tomcat60.sh start
Starting tomcat60.
This will only work if you have added this line to your /etc/rc.conf file:
tomcat60_enable="YES"
You may use the tomcat60.sh script to start, stop, and restart Tomcat 6.
By default, this FreeBSD port of Tomcat 6.0 sets Tomcat's default HTTP port to
be 8180, which is different than the default that is originally set (for all operating
systems) in the Apache Software Foundation's distribution of Tomcat (which is
8080). Try accessing your FreeBSD Tomcat port via the URL
http://localhost:8180/.
Common Errors
Several common problems can result when you try to start up Tomcat. While
there are many more errors that you can run into, these are the ones we most of-
ten encounter.
Ensure that you don't have Tomcat already started. If you don't, check
to see if other programs, such as another Java application server or
Apache Web Server, are running on these ports.
Remember that not only must the HTTP port of different Tomcat in-
stances (JVMs) be different, every port number in the Server and
Connector elements in the server.xml files must be different between
instances. For more information on these elements, consult Chapter 7.
Restarting Tomcat
SIGN IN TRY NOW
At the time of this writing, there is no restart script that is part of the Tomcat 6.0
distribution because it is tough to write a script that can make sure that when
Tomcat stops, it shuts down properly before being started up again. The reasons
outlined below for Tomcat shutdowns being unreliable are almost exclusively
edge conditions. That means they don't usually happen, but that they can occur in
unusual situations. Here are some reasons why shutdowns may be unreliable:
The Java Servlet Specification does not mandate any time limit for how long
a Java servlet may take to perform its work. Writing a servlet that takes for-
ever to perform its work does not break compliance with the Java Servlet
Specification, but it can prevent Tomcat from shutting down.
The Java Servlet Specification also dictates that on shutdowns, servlet con-
tainers must wait for each servlet to finish serving all requests that are in
progress before taking the servlet out of service, or wait a container-spe-
cific timeout duration before taking servlets out of service. For Tomcat 6,
that timeout duration is a maximum of a half-second per servlet. When a
servlet misbehaves and takes too long to finish serving requests, it's up to
Tomcat to figure out that the servlet has taken too long and forcibly take it
out of service so that Tomcat can shut down. This processing takes time,
though, and slows Tomcat's own shutdown processing.
If your Tomcat instance has run completely out of memory (as evidenced by
the dreaded "Permgen memory" error in the logs), it will usually be unable
to accept new connections on its web port or on its shutdown port.
To fix some of the problems, you may want to configure and use a security man-
ager. See Chapter 6 for more information on how to place limits on webapps to
guard against some of these problems.
1. Change directory into the root of the Tomcat installation directory (com-
monly known as the CATALINA_HOME directory):
$ cd apache-tomcat-6.0.14
3. Decide how long you want to wait for Tomcat to shut down gracefully, and
wait that period of time. Reasonable maximum shutdown durations depend
on your web application, your server computer's hardware, and how busy
your server computer is, but in practice, Tomcat often takes several seconds
to completely shut down.
4. Query your operating system for java processes to make sure it shut down.
On Windows, hit Ctrl-Alt-Delete to get to the task manager, and scroll
through the list to look for it. On all other operating systems, use the jps
command to look for any remaining Tomcat processes that are your
Tomcat's Java virtual machine. The jps command comes with Java. Try this:
7. Once you're sure that Tomcat's JVM is no longer running, start a new
Tomcat process:
$ bin/startup.sh
Usually, the shutdown process goes smoothly and Tomcat JVMs shut down
quickly. But, because there are situations when they don't, the above procedure
should always suffice. We realize this is not a very convenient way to restart
Tomcat; however, if you try to cut corners here, you will likely not always shut
down Tomcat and get errors due to the new Tomcat JVM bumping into the exist-
ing Tomcat JVM when you go to start it again. Luckily, for most operating sys-
tems, there are scripts that automate this entire procedure, implemented as a
"restart" command. You'll find these integrated into most OS-specific Tomcat in-
stallation packages (Linux RPM packages, the FreeBSD port, etc.).
The following outlines how to reliably restart Tomcat on Linux. If you have in-
stalled Tomcat via an RPM package, either the one from this book or the one from
JPackage.org, restarting Tomcat is easy. If you installed the RPM package from
this book, do:
which should reliably restart Tomcat. Be sure to check your logfiles for any
startup problems.
# /etc/init.d/cswtomcat5 restart
That should restart Tomcat. Be sure to check your logfiles for any startup
problems.
As of this writing, the Blastwave package's init script does not contain any code
to reliably restart Tomcat—it does not watch the processes to make sure that
they came down all the way, nor does it try to force the processes down if they
do not come down on their own. Read the init script source and you'll see what
we mean. So, it is up to the Solaris administrator to ensure (by hand) that the
restart actually occurred.
If you have Tomcat running as a Windows Service, you can restart it from the con-
trol panel. Either right-click on the service and select Restart from the pop-up
menu or, if it exists on your version of Windows, use the Restart button near the
upper-right corner of the dialog box (see Figure 1-6).
SIGN IN TRY NOW
If you have chosen to use the generic way to start Tomcat, there is no easy way to
restart Tomcat in Mac OS X and the best solution is to call shutdown.sh. Then,
just as described in the Linux section of this chapter, you would decide how long
you will wait for Tomcat to shut down and take the appropriate steps, as outlined
above.
You should see no output, meaning that Tomcat has shut down. Then, you may
start it back up again, like this:
After waiting some seconds, check to make sure that Tomcat is running and lis-
tening on port 8080 again:
If you have chosen to use the automatic startup and shutdown scripts for Tomcat
via Apple's launchd (see the section "Automatic Startup on Mac OS X," later in
this chapter, for details about how to set that up), it's very easy to restart Tomcat
simply by unloading the service and reloading it into launchd:
$ sudo launchctl unload /Library/LaunchDaemons/tomcat.plist
SIGN IN TRY NOW
$ sudo launchctl load /Library/LaunchDaemons/tomcat.plist
# /usr/local/etc/rc.d/tomcat60.sh restart
That should reliably restart Tomcat. Be sure to check your logfiles for any startup
problems.
[3] * Linux, BSD, and Unix users may object to the .sh extension for all of the scripts. However, renaming these to your preferred conventions is only temporary, as the .sh ver-
sions will reappear on your next upgrade. You are better off getting used to typing catalina.sh.
An urban legend about developing Java webapps says that according to the Java Servlet Specification, servlets in webapps are not allowed to spawn any Java threads.
[4] *
That is false. The servlet specification does not preclude doing this, so it is OK to spawn one or more threads as long as the thread(s) are well behaved. This is often the rub,
since webapp developers often report bugs against Tomcat that turn out to be caused by their own code running in a separate thread.
Get Tomcat: The Definitive Guide, 2nd Edition now with the O’Reilly
learning platform.
Community partners
WATCH ON YOUR BIG SCREEN
Affiliate program
View all O’Reilly videos, Superstream events, and Meet
Submit an RFP
the Expert sessions on your home TV.
Diversity
SUPPORT
Contact us
DO NOT SELL MY PERSONAL INFORMATION
Newsletters
Privacy policy
INTERNATIONAL
India
Indonesia
Japan
© 2025, O’Reilly Media, Inc. All trademarks and registered trademarks appearing on oreilly.com are the property of their respective
owners.
We are a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us
to earn fees by linking to Amazon.com and affiliated sites.
Terms of service • Privacy policy • Editorial independence