How to Check Which Process Is Using Port 8080 on Linux

You try to start a web app or development server, and Linux stops you with a short message: address already in use, port 8080 is already bound. Something is already listening there, but the error rarely tells you what. It might be an old copy of your own app, a forgotten test server, or a completely different program. Killing random processes is not the answer. This guide shows you how to identify exactly which process owns port 8080 and free the port safely on Ubuntu, Debian, and most other Linux systems.

Quick Answer

Run sudo ss -tlnp | grep 8080 or sudo lsof -i :8080 to see the process name and PID using port 8080. Check what it is with ps, stop it properly with its service command or sudo systemctl stop if it is a service, and only use kill on the confirmed PID as a last resort. Then verify the port is free by running the ss check again.

Why Port 8080 Causes So Many Clashes

Port 8080 is a favourite alternative web port. Developers use it for test servers, Tomcat and other Java servers default to it, and many tutorials tell every reader to use the same number, so clashes are almost inevitable.

A port can only be bound by one process at a time for the same protocol and address. The program already holding the port might be legitimate and important to someone else, especially on a shared server. Identify first, decide second, stop third. Almost everything on 8080 is TCP, so the commands below focus on TCP listening sockets.

Method 1: Find the Process With ss

The ss tool is the modern, fast replacement for the old netstat command, and it is installed by default on Ubuntu and Debian. It gives you the process directly when you run it with sudo.

1. Run sudo ss -tlnp | grep 8080. The flags mean TCP, listening only, numeric ports, and show the process.
2. Read the last column. You will see something like users with a program name and a PID, for example java with pid 2145.
3. Note the local address too. A listing for 0.0.0.0:8080 means all network interfaces. A listing for 127.0.0.1:8080 means local connections only.
4. If nothing appears without sudo but your app says the port is busy, run it again with sudo. Without root rights, you cannot always see processes owned by other users.
5. To see both TCP and UDP, run sudo ss -tulnp | grep 8080.

Once you have the PID, learn more before touching it. Run ps -p 2145 -o pid,ppid,user,cmd, using your real PID, to see the owner and the full command that started it. That full command often tells you the folder, the app name, and whether it is a system service or a session you started hours ago and forgot.

For related socket work, our guide on how to check open ports on Linux and see what is listening explains how to audit every listening port on a server, not just one.

Method 2: Find the Process With lsof and fuser

Some administrators prefer lsof, because it shows files and sockets in a very readable way. It may need installing on a minimal server with sudo apt install lsof.

1. Run sudo lsof -i :8080 to list every process using that port.
2. Or narrow it to TCP listeners with sudo lsof -iTCP:8080 -sTCP:LISTEN.
3. Read the COMMAND, PID, and USER columns, and the NAME column showing the address and port.
4. Use the quick tool fuser as a cross-check with sudo fuser 8080/tcp, which returns the PID directly.
5. For a fuller picture of one PID, run sudo lsof -p 2145 | head to see what else it has open.

The official ss man page on man7.org documents every flag used here, and the lsof man page explains its output columns if you want to go deeper.

Method 3: Check if a Container or Service Owns the Port

On modern systems, the process holding 8080 is often not a normal program at all. It can be a Docker container forwarding the port, or a systemd service that restarts itself the moment you kill it.

Docker and containers

1. Run docker ps and look for 8080 in the PORTS column, such as 0.0.0.0:8080->80/tcp.
2. If you find a container, stop it properly with docker stop container_name, using the name or ID from the list.
3. Do not kill the Docker daemon process shown by ss. That would affect every container on the machine.

Systemd services

1. Search for the service by PID with systemctl status 2145, using your PID. Systemd can often tell you the unit it belongs to.
2. Or list likely web services with systemctl list-units --type=service --state=running and look for Tomcat, Jenkins, or your app name.
3. Stop a confirmed service with sudo systemctl stop service_name, and disable it at boot only if you are sure with sudo systemctl disable service_name.

If you kill a service process directly with kill, systemd may simply restart it within seconds, and the port will appear busy again. That restart behaviour is by design. Stopping the unit is the correct method for a service.

How to Free Port 8080 Safely, Step by Step

1. Identify the PID, owner, and full command using ss or lsof, and write them down.
2. Decide if the process is yours, a known service, a container, or something you do not recognise. If you do not recognise it on a shared or production machine, stop and ask the owner or check documentation before proceeding.
3. Try the graceful way first. If it is your terminal app, press Ctrl+C in its terminal. If it is a service, use systemctl stop. If it is a container, use docker stop.
4. If it is a normal background process that is yours and has no graceful control, send a polite termination with kill 2145, using your PID. This is SIGTERM, which lets the program close files and exit cleanly.
5. Wait a few seconds, then check with sudo ss -tlnp | grep 8080.
6. Only if the process ignores the polite signal and you are certain it is safe, use the force signal with kill -9 2145. This is SIGKILL and gives the program no chance to clean up, so it is a last resort.
7. Verify the port is fully free, then start your own program and confirm it now binds and answers.

Alternatives When You Should Not Free the Port

Sometimes the right answer is not to free 8080 at all, but to move your new program instead. If the existing process is a real service other people use, change your app to listen on 8081 in its config file or start command, such as --port 8081. You can also run your test in a container with a different host mapping, for example host 8081 to container 8080, so both programs keep working without a clash.

Common Mistakes and Useful Tips

• Killing the first PID you see: Always read the full command and owner first. A PID belonging to a database proxy or a team service is not yours to kill.
• Forgetting sudo: Without it, ss and lsof may hide other users’ processes, leaving you thinking the port is free when it is not.
• Using kill -9 immediately: Force killing can corrupt files a program was writing. Try graceful stops and SIGTERM first.
• Ignoring Docker: The ss output may point to a container runtime. Stop the container, not the runtime.
• Not verifying afterwards: A process can restart automatically. Always re-run the ss check and test your own app binding before you declare success.
• Tip — save your usual commands: Keep a short note with the ss and lsof commands for your team, so a junior colleague can identify a port owner without guessing.
• Tip — check before you deploy: Run the port check as part of your deployment routine. Finding a clash before users do is much calmer.

Conclusion

Freeing port 8080 on Linux is simple once you identify the owner properly. Use sudo ss -tlnp | grep 8080 or sudo lsof -i :8080 to get the name and PID, confirm what it is with ps or systemd and Docker checks, then stop it the graceful way for its type, using kill only on a confirmed process you own. Verify the port is clear, and if the existing service matters more than your test, move your app to a different port instead. Identify first, and you will never take down the wrong thing.

Frequently Asked Questions

Why does ss show nothing for port 8080 but my app says it is in use?

You may have run ss without sudo, so another user’s process was hidden, or your app may be trying an IPv6 address or a container namespace. Run sudo ss -tlnp | grep 8080, check Docker with docker ps, and read the full error message from your app.

Is kill -9 safe to use on the process using port 8080?

It works, but it is not the safe first choice. It stops the process instantly with no cleanup, which can leave files or data in a bad state. Use the service or container stop command first, then a normal kill, and reserve kill -9 for a stuck process you fully own.

How do I stop a process from taking port 8080 again after reboot?

Find its service or container and disable its automatic start. For systemd, use sudo systemctl disable service_name. For Docker, remove the container or change its restart policy. Simply killing it today does not stop a boot-time start tomorrow.

What is the quickest one-line check for port 8080?

On most Ubuntu and Debian systems, sudo ss -tlnp | grep 8080 is the fastest check. If it returns a line, the last column names the program and PID. If it returns nothing, the port is free for TCP listeners.