DEV Community: Ahmad Zia

Managing Apache Tomcat with systemd on Linux – A DevOps Guide

Ahmad Zia — Sun, 13 Jul 2025 03:39:39 +0000

As a DevOps engineer, automation and service management are critical. While working with Java-based web applications, Apache Tomcat is one of the most widely used tools to serve Java servlets and JSPs. However, starting and stopping Tomcat manually using shell scripts (startup.sh and shutdown.sh) isn’t ideal in a production environment.

In this guide, we’ll walk through setting up Tomcat as a systemd service, allowing us to manage it easily using systemctl — just like any other system service!

✅ What is Tomcat?

Apache Tomcat is an open-source application server developed by the Apache Software Foundation. It's used to host Java-based web applications, similar to how Apache HTTPD serves websites.

🛠️ Setup Steps

1. Install Required Software

First, install Tomcat and Java:

sudo yum install java-17-openjdk -y

Download and extract Tomcat from the official website. You’ll typically extract it using:

tar -xvzf apache-tomcat-9.x.xx.tar.gz

2. Start Tomcat Manually (Initial Test)

To make sure everything works initially, run:

cd apache-tomcat-9.x.xx/bin./startup.sh

Then, open your browser and visit:

http://<your_server_ip>:8080

You should see the Tomcat welcome page.

❌ The Problem

By default, Tomcat requires manual start/stop using shell scripts. That’s not ideal for production or automation. We need to integrate it into our system’s service manager – systemd.

✅ The DevOps Solution: Use systemctl

We’ll create a custom systemd service file for Tomcat, enabling us to manage it using:

sudo systemctl start tomcat
sudo systemctl stop tomcat
sudo systemctl enable tomcat

🧰 Step-by-Step Guide

🔹 Step 1: Create a Non-root Tomcat User

It’s a security best practice to run services as non-root users.

sudo useradd -m -U -d /opt/tomcat -s /bin/false tomcat

🔹 Step 2: Move Tomcat Files

Assuming you’ve already extracted Tomcat:

sudo mv apache-tomcat-9.x.xx /opt/tomcat
sudo chown -R tomcat: /opt/tomcat

🔹 Step 3: Create systemd Service File

Create a new file:

sudo nano /etc/systemd/system/tomcat.service

Paste the following configuration:


[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
User=tomcat
Group=tomcat
Environment=JAVA_HOME=/usr/lib/jvm/jre
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
WorkingDirectory=/opt/tomcat
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

🔎 Note: Replace JAVA_HOME with the actual path of your installed JDK, if different.

🔹 Step 4: Reload systemd and Start Tomcat

sudo systemctl daemon-reload
sudo systemctl start tomcat

To make Tomcat start automatically at boot:

sudo systemctl enable tomcat

To check the status:

sudo systemctl status tomcat

🎯 Final Test

Visit your server IP on port 8080 again:

http://<your_server_ip>:8080

If you see the Tomcat page — congratulations! You’ve successfully integrated Tomcat into your Linux service system.

Granting a User Access to Only apt: A Hands-On Experiment with sudoers

Ahmad Zia — Sat, 22 Feb 2025 03:33:51 +0000

So, I wanted to give a specific user the ability to use apt, but nothing else. I knew this had to be done via the sudoers file, but I wasn’t exactly sure how. No worries—just open the file and figure it out, right?

Opening the sudoers File

I ran:

sudo visudo

This opened up the sudoers file, where I started looking for something that controlled user privileges. I saw this familiar-looking line:

username ALL=(ALL:ALL) ALL

At first, I had no idea what it meant, so I Googled it. Turns out, the last ALL means the user can run all commands. That was my hint—this is where I had to tweak things.

Changing Access to apt

So, I replaced ALL with apt, thinking this would restrict the user to only using apt:

username ALL=(ALL:ALL) apt

I saved the file, but when I tried to use apt with the restricted user, I got an error—something about a path issue. I wasn’t sure what was going wrong, so I experimented a bit.

Changing apt to APT

Next, I tried changing apt to uppercase APT, just in case:

username ALL=(ALL:ALL) APT

This time, the file saved successfully, but the user still couldn’t run apt. The error message clearly said something about no access to /usr/bin/apt. That was the real problem.

The Final Fix: Specifying the Full Path

So, I copied the path /usr/bin/apt from the error message and used it explicitly in the sudoers file:

username ALL=(ALL:ALL) /usr/bin/apt

Saved the file, tested it, and boom—it worked! Now, the user could run apt, but nothing else.

Lessons Learned

The sudoers file controls which commands a user can execute with sudo.
The last ALL in ALL=(ALL:ALL) ALL defines which commands a user can run.
Specifying just apt doesn’t work—you need the full path (/usr/bin/apt).
Always test changes in a separate terminal before closing visudo, so you don’t lock yourself out!

That’s it! Hope this helps if you ever need to restrict users to specific commands.