How to Find Tomcat Version in Linux

Eric DawsonByEric Dawson Computers & Software

To find the Tomcat version in Linux, run the installation’s bin/version.sh script and read the Server version line. The script can display the server version even when Tomcat is not running. Apache Tomcat’s Manager documentation also identifies Diagnostics as an interface section that displays information about Tomcat, the host operating system, the Java Virtual Machine, and the server’s primary hostname.

The Apache Tomcat Maven Plugin page concerns the Tomcat 6.x source repository rather than checking an installed server version. That page lists Version 2.2 and says it was last published on November 7, 2013.

Read the Server Version Line, Not OS or JVM Details

Tomcat’s Server version line is the output field that names the installed server release. By contrast, OS Version and JVM Version describe the Linux host and Java runtime, not Tomcat itself.

An example from a Debian 12 system prints Server version: Apache Tomcat/10.1.52. Separate lines in that output show OS Version: 6.1.0-10-amd64 and JVM Version: 17.0.18+8-Debian-1deb12u1. Readers seeking a computer operating system detail should use the OS field, while the release answer remains on the server line.

Use the Label Before the Number

Release numbers need context because the same output contains several versioned components. Look for the literal Server version: label, then read the product string following it as one value. Text before the colon names the category, while text after it supplies the reported product and release.

A server string formatted Apache Tomcat/10.1.52 identifies Apache Tomcat and its release together. Neither the kernel-style OS string nor the Java build string answers a Tomcat version request. Slashes join the Tomcat product name with its release in the example, rather than indicating an operating-system release.

Understand the Catalina Script Relationship

Tomcat version catalina.sh refers to a relationship inside the installation scripts: version.sh calls catalina.sh behind the scenes. Running the version script therefore produces server information without making catalina.sh a separately established version-check procedure. The script can report the version while the server is stopped, unlike a check that reaches a live web interface.

A Docker invocation using /usr/local/tomcat/bin/version.sh reported Server version: Apache Tomcat/9.0.52. That command’s /usr/local/tomcat location belongs to the illustrated container, while Linux installation directories differ between deployments. Shell output remains readable by field: first identify the server label, then ignore host and JVM values when the sole question is the Tomcat release.

Build information is separate from the release field as well. The container example records Server built: Jul 31 2021 04:12:17 UTC after its version value. That timestamp gives a build time in UTC, whereas Apache Tomcat/9.0.52 is the release identifier.

Find the Tomcat Installation Directory

Begin by checking the shell path before assuming a Tomcat location. If Tomcat’s bin directory is already on $PATH, the version script is available without writing its filesystem location, Stack Overflow contributors report. Linux has no single established Tomcat directory, so a fixed path is unsafe. The supplied examples place version.sh in bin.

Check the Shell Path

Run echo $PATH to display the shell path variable. Review the listed directories for a Tomcat bin directory already exposed to the shell. A bare version.sh command works only when that directory is on $PATH. That check avoids assuming a filesystem location before examining the local command environment.

  1. Open a Linux shell and enter echo $PATH.
  2. Look through the displayed directories for a Tomcat bin location.
  3. Reserve a bare version.sh command for shells where that directory is already present.

A Docker example places the script at /usr/local/tomcat/bin/version.sh, but that path belongs to one container example. Searches under /usr/local/, /opt/, and /usr/share/ failed to find a Tomcat folder in another Linux case. Those contrasting locations make local inspection the starting point.

Container paths therefore identify a local arrangement rather than a universal Linux convention. Product packaging and platform conventions also change installation roots, as an OpenVMS product uses TOMCAT$ROOT by default. Platform-specific layouts reinforce that distinction.

Service status serves a different purpose from finding the bin directory. The command sudo systemctl status tomcat appears in Ubuntu 18.04 discussion as a way to see whether Tomcat is running when installed. Ubuntu 18.04 is the operating-system context named in that discussion. Running status alone does not provide the local script path.

How to Find Tomcat Version in Linux

Run bin/version.sh from a Tomcat installation to display the installed server version. The script also reports operating system and Java Virtual Machine details in its output, and it works when the server is not running.

On Debian 12, version.sh also lists OS Version: 6.1.0-10-amd64 and JVM Version: 17.0.18+8-Debian-1deb12u1, separate from the server version.

Compare Host and Container Output

Docker containers use the same version script, but the command runs inside the container. Running docker exec -it c63c819668d4 /usr/local/tomcat/bin/version.sh returns Server version: Apache Tomcat/9.0.52.

Environment Command or Script Server Version Output Other Reported Details
Docker container docker exec -it c63c819668d4 /usr/local/tomcat/bin/version.sh Apache Tomcat/9.0.52 Server built: Jul 31 2021 04:12:17 UTC
Debian 12 host bin/version.sh Apache Tomcat/10.1.52 OS Version: 6.1.0-10-amd64; JVM Version: 17.0.18+8-Debian-1deb12u1

Version output labels the Tomcat release separately from the Linux kernel and JVM release. Reading the line beginning Server version: avoids confusing the operating system version or Java version with the installed Tomcat version.

Shell access can shorten the command when the Tomcat bin directory is already available through $PATH. Otherwise, use the version script from the installed Tomcat directory rather than treating /usr/local/tomcat as a universal Linux location.

Check a Running Web Interface

A reachable Tomcat web page can provide another version view because the page title may show the server version. The cited example uses that title. That route depends on a live web interface, unlike version.sh, a startup log, or a local release-notes file.

The example address is http://localhost:8080, where port 8080 is described as Tomcat’s default server port. A default port is not a promise that every deployment listens there.

Apache’s Manager documentation describes six sections: Message, Manager, Applications, Deploy, Diagnostics, and Server Information. Diagnostics displays that information.

The primary hostname shown in Diagnostics may differ from the hostname used to access Tomcat. Treat the screen as a running-server view rather than a replacement for inspecting files in the installation directory. A stopped application can return HTTP error 404 in the Manager interface, and that response is not a version result.

Browser-based checks suit a reachable instance; local script checks remain useful when no HTTP endpoint is available.

Check Startup Logs and ServerInfo

Startup logs reveal a Tomcat version from the message written when the servlet engine starts. ServerInfo offers a Java-based alternative that returns server information through a class stored in Tomcat’s catalina.jar file.

Search the Startup Log

Search ./logs/catalina.out with grep “Starting Servlet engine” ./logs/catalina.out | tail -1 to locate the engine-start record. A matching example reads Starting Servlet engine: [Apache Tomcat/10.1.52]. That line records Apache Tomcat/10.1.52 as the server version at startup.

Logs preserve a version entry from an earlier server start rather than requiring a current request to Tomcat. Relevant engine-start entries must exist in catalina.out for the search to return a version line. The tail -1 portion selects the final matching entry when the log contains several startup records.

Run the ServerInfo Class

Run java -cp /opt/tomcat/lib/catalina.jar org.apache.catalina.util.ServerInfo to invoke the Java-based ServerInfo check. The /opt/tomcat portion is an example installation path within that command. Its class name is org.apache.catalina.util.ServerInfo, while the classpath points Java to catalina.jar.

ServletContext supplies an application-level option through its getServerInfo() method. A servlet obtains the server name and version through that interface. Application code therefore has a programmatic route alongside the shell command.

Use Release Notes as a Fallback

RELEASE-NOTES is a fallback for confirming a Tomcat release after the relevant Tomcat home directory is available. That file-based check answers a release-confirmation question rather than a live-service question. Live-service results concern an instance responding when queried, while a local document records information distributed with the installation.

Access to the directory is required for this route. Run grep “Apache Tomcat Version” ./RELEASE-NOTES to retrieve the release-notes version line. The cited example shows the output.

Unlike a web interface, the release-notes check does not require Tomcat to be running. Directory selection matters because ./RELEASE-NOTES identifies a file relative to the current location. Careful use keeps the result tied to the installation whose files are being examined.

Separate the desired result from the method used to obtain it. Readers seeking a stored release label can use the document, while a reachable interface serves a current server check. Treat the returned text as confirmation of the release named by that file.

An exact phrase narrows the search to the wording used by the supplied example. That focused query produces a short version result instead of requiring the entire document to be read.

Release-note evidence is most useful after the relevant installation directory has been located. Choose this fallback when the task calls for a local release record rather than an observation of a running service. Framing the result this way prevents a file check from being mistaken for a report about present server behavior.

Local file inspection also avoids requiring a reachable browser endpoint for this direct confirmation.

Avoid Mistaking Package and Product Details for a Version Check

Product compatibility tables, vendor release labels, and service-status messages are not a universal Linux Tomcat version result. An installed server’s release identification differs from a platform’s packaging, an application’s support policy, or a process state.

Repository and Product Labels

Version 2.2 belongs to the Tomcat 6.x Maven Plugin, whose page provides Subversion checkout commands for a source repository. Those commands retrieve source code through anonymous HTTP or HTTPS access for committers, rather than identifying an installed server release. Proxy configuration places the Subversion servers file in ~/.subversion on Linux or Unix and uses port 3128 in its example.

Windows product guidance supports Tomcat 8.0 under stated Java conditions, excludes Tomcat 8.0.32, and excludes Tomcat 10.0 for that product. Vendor release notes identify VSI Tomcat Version 9.0-102A as a binary release of Apache Tomcat 9.0.102 for OpenVMS IA-64 and x86-64. Neither product-specific compatibility rules nor an OpenVMS release label answers a check Tomcat version Ubuntu request.

Service and Application States

Service status carries a separate meaning from server version. Similarly, stopped applications return HTTP error 404 in the Manager interface, making an application response code unsuitable as a version result.

Practical version checks separate the server’s own release label from surrounding clues. Start by treating repository metadata, application compatibility matrices, vendor platform names, service state, and HTTP 404 responses as context rather than answers. Keep operating environments distinct when recording results, because a Windows product guide, an OpenVMS distribution, and a Linux service use different packaging and conventions. Clear reporting names the Tomcat server release without substituting a plugin, product policy, or service condition for it.

Having owned a refurbished Lenovo ThinkPad T14 Gen 2 since 2022, I am suitably qualified to be suspicious when a label sounds more decisive than it is. In package and product details, I would check the installation’s server-version field instead of treating a package name, product name, or build description as confirmation of the Tomcat release.

Frequently Asked Questions

What Is the Command to Check Tomcat Version on Linux?

Run bin/version.sh from the Tomcat installation to display the server version. Read the line labeled Server version for the installed release.

Does Version.sh Work When Tomcat Is Stopped?

Yes, version.sh can report the Tomcat version while the server is stopped. A web-page check requires a reachable running server.

What Is the Relationship Between Tomcat Version Catalina.sh and Version.sh?

The version.sh script calls catalina.sh behind the scenes.

How Can I Check Tomcat Version Ubuntu When I Do Not Know the Install Path?

Run echo $PATH to see whether Tomcat’s bin directory is available to the shell. Locations such as /usr/local/, /opt/, and /usr/share/ are not guaranteed Tomcat directories, Stack Overflow contributors report.

Can I Find the Tomcat Version from a Web Page?

A running Tomcat web page can show its server version in the page title. The cited example title is Apache Tomcat/10.1.52.

Does Systemctl Status Tomcat Show the Tomcat Version?

sudo systemctl status tomcat checks whether an installed Tomcat service is running.

References

Sources read in September 2026.

Eric Dawson

I'm Eric Dawson, and I write The Money Watch from north Columbus, Ohio. Most of what I cover comes from my own life: renting, a 2014 Honda Fit, parking, computers, food and the bills behind all of it. I spent four years in an apartment-property office and eleven on a distributor's operations desk, reading leases and invoices. Where you need real information, I research the maker's or agency's own page and independent sources and report what they publish. I don't give tax, investment, legal or medical advice.