If a Tomcat restart fails, the application may not come back online immediately, but the problem is usually recoverable without reinstalling the whole service. In a managed hosting environment with Plesk and a private JVM, the safest approach is to check the service status, review the recent changes, and then start Tomcat again with the correct Java runtime and configuration. In most cases, a failed restart is caused by a port conflict, a bad deployment, an invalid server.xml change, a missing file, or a JVM startup error.
For Tomcat hosting, JSP hosting, servlet hosting, and private JVM setups, the key is to recover in a controlled way. Do not keep clicking restart repeatedly without checking logs, because repeated attempts can make the issue harder to isolate. Instead, confirm whether Tomcat stopped cleanly, whether the Java process is still running, and whether the application itself is blocking startup. If you use a hosting control panel such as Plesk with My App Server, you can usually recover by using the service controls, validating the application package, and restarting with a known-good Java version.
Common reasons a Tomcat restart fails
Before trying recovery steps, it helps to understand what usually breaks a Tomcat deployment after a restart request.
Port already in use
Tomcat needs its configured HTTP, HTTPS, AJP, and shutdown ports to be free. If another service is using the same port, Tomcat may fail during startup or stop responding during restart. This can happen if an old Java process remains running after shutdown.
Invalid configuration file
A small syntax mistake in server.xml, context.xml, or application-specific configuration can stop Tomcat from starting. Even a missing quote or broken connector setting may prevent the service from coming back online.
Application deployment error
If a WAR file is incomplete, corrupted, or contains broken libraries, Tomcat may fail while unpacking or loading the application. A problematic JSP or servlet can also trigger startup failure depending on when the error is detected.
Java runtime mismatch
If the application was deployed for one Java version and Tomcat restarts under another, startup can fail. This is especially relevant when you manage multiple ready-to-use Java versions or upload a custom runtime.
Permission or ownership problem
Tomcat must be able to read the application files, write temporary files, and access its directories. Incorrect permissions after upload, restore, or manual file changes can block recovery.
Memory pressure or JVM crash
If the JVM runs out of memory during startup, the service may exit during restart. This can happen with large applications, too many libraries, or an unexpectedly heavy initialization step.
First recovery checks after a failed restart
Use these initial checks before changing anything else. They help you identify whether Tomcat is actually down, partially running, or stuck in a failed startup loop.
Check the service state in Plesk
Open the service management area in your control panel and verify whether the Tomcat instance is marked as running, stopped, or failed. In a My App Server setup, the service control page is the fastest way to confirm whether the restart request reached the Java process.
Wait briefly before retrying
Some Tomcat instances take a little longer to stop cleanly, especially if the JVM is handling active requests. Wait 30 to 60 seconds before pressing restart again. Starting a second instance too early may create a port conflict.
Check whether the old process is still alive
A failed stop can leave the Java process running in the background. In that case, Tomcat may refuse to start because the ports are already occupied. If your control panel shows the service as stopped but the application still answers, this is a likely cause.
Review recent file changes
Think about what changed before the restart failed. Common triggers include a new WAR upload, edited XML file, new library JARs, Java version changes, or a manual change in the web app directory. Recent changes are often the fastest route to the cause.
Step-by-step recovery procedure
Follow these steps in order. They are suitable for a shared hosting account with private JVM control and Tomcat managed through Plesk or a similar panel.
1. Stop the service cleanly
Use the control panel stop function first, even if the restart failed. This gives Tomcat a chance to close resources, release ports, and write any final log entries. Avoid force actions unless the service is clearly stuck.
2. Wait and confirm the process is gone
After stopping, give the service a short pause. Then check whether the JVM is still listed as active. If the process remains, the initial shutdown may not have completed correctly, which explains why the restart failed.
3. Inspect the latest logs
Open the Tomcat and application logs immediately after the failed restart. Look for startup exceptions, port binding errors, file permission errors, class loading failures, and Java version messages. The last 20 to 50 lines often contain the exact reason.
4. Verify the Java version
Make sure the service is using the intended Java runtime. If you recently switched between installed Java versions or uploaded a custom runtime, test the deployment with the last known working version first. A wrong Java version can break startup even if the application itself has not changed.
5. Check the application package
Confirm that the WAR or expanded application directory is complete and intact. If the restart failed after deployment, re-upload the package from a clean copy. For JSP and servlet apps, verify that all required libraries are present in the expected folders.
6. Review configuration files
If you edited server.xml, connector definitions, JVM arguments, environment files, or application context settings, compare them with the last working version. Undo the latest changes if you suspect a syntax error.
7. Validate file permissions
Make sure the Tomcat user can read the deployed files and write to temporary and work directories. If files were uploaded with incorrect permissions, correct them before starting the service again.
8. Start Tomcat again
Once the obvious causes are cleared, start the service from the control panel. If the startup succeeds, test the application immediately and confirm that the expected context path responds correctly.
9. Test the application endpoint
Open the app in a browser or use a health check URL if available. A successful Tomcat start does not always mean the application deployed correctly. Check for HTTP 404, 500, or redirect loops that may point to a deployment-level issue rather than a service-level issue.
What to check in logs
When Tomcat fails to restart, the logs usually point to one of a few recurring problems. Focus on the first error, not just the final shutdown message.
Port binding errors
Messages like “Address already in use” indicate that another process still holds the port. This usually means the previous Tomcat instance did not stop fully or another application uses the same connector.
Class loading or missing library errors
If the log shows ClassNotFoundException or NoClassDefFoundError, an application library is missing or incompatible. Check the WEB-INF/lib folder and any custom classpath settings.
XML parsing errors
If the log references malformed XML, inspect the relevant file for broken tags, invalid attributes, or encoding problems. A single configuration syntax error can prevent startup entirely.
Java version or module errors
Logs may show unsupported class version errors, illegal access messages, or other runtime compatibility issues. These often mean the application was built for a different Java release than the one currently selected in My App Server.
Permission denied
If the service cannot read or write a file, the log may mention access denied or failed temporary file creation. This is common after manual uploads, restores, or migration work.
How to recover when Tomcat is stuck after restart
If the service appears to be neither fully running nor fully stopped, use a cautious recovery sequence.
Use the control panel to stop and wait
Issue a stop command once, then wait. If the process is still active after a reasonable delay, check the service status again before trying anything else.
Remove the cause, not just the symptom
If a deployment caused the failure, do not simply restart the same broken package. Roll back to the last known good WAR or configuration file first. This avoids an endless fail-restart loop.
Clear temporary deployment artifacts if needed
Sometimes Tomcat leaves behind partial unpacked files or stale work directories after an interrupted deployment. If your hosting environment allows it, remove only the temporary deployment output related to the affected app, then redeploy the clean package.
Reapply the known-good Java runtime
If the issue started after a runtime change, set the service back to the previous Java version that worked. My App Server is designed to let you switch between supported Java versions and manage a private JVM without needing a full server rebuild.
Recovery checklist for Plesk and My App Server
If you manage your Tomcat instance through a hosting control panel, this checklist can help you recover quickly and safely.
- Confirm whether the service is truly stopped.
- Check for an active Java process that did not exit.
- Review the latest Tomcat startup log entries.
- Verify the selected Java version.
- Confirm that the deployed WAR or application folder is complete.
- Undo the last configuration change if startup began failing afterward.
- Check file permissions on the app and runtime directories.
- Restart the service once the cause is addressed.
- Test the application endpoint immediately after startup.
How to avoid failed restarts in the future
Good restart hygiene reduces downtime and makes recovery easier when something does go wrong.
Change one thing at a time
Avoid changing Java version, application package, and Tomcat configuration all at once. If the restart fails, you will know exactly where to look.
Keep a known-good deployment copy
Store a working WAR file and the last stable configuration set so you can roll back quickly. This is especially useful for small and medium Java applications hosted on a private JVM.
Test after deployment before restarting in production use
If your workflow allows it, validate the package contents and check logs after upload. Catching deployment issues early is easier than recovering after a failed restart.
Monitor resource usage
If the application is close to its memory limit, restart failures can happen during peak load or after a code update. Keep an eye on memory and CPU usage, especially for applications with heavier startup routines.
Use supported Java and Tomcat combinations
Choose a Java version that matches the needs of the application. In a managed Tomcat hosting setup, compatibility matters more than picking the newest runtime.
When to restore or ask for support
Some restart failures can be fixed quickly by the account owner, but others need support involvement. Contact support if the service still will not start after you have checked logs, Java version, permissions, and recent changes.
Best cases for self-service recovery
You can usually resolve the issue yourself when the cause is a recent WAR upload, a Java version mismatch, a small XML mistake, or a simple port conflict from a stuck process.
Best cases for support assistance
Ask for help if you see unclear startup errors, repeated JVM crashes, a service that refuses to stop cleanly, or a configuration problem you cannot trace. Include the exact error lines and the time of the failed restart.
FAQ
Why did Tomcat fail only after I clicked restart?
Restart combines stop and start in one action. A problem that is hidden during normal runtime, such as a port conflict, a broken deployment, or a missing dependency, may appear only when the JVM tries to start again.
Is it safe to restart Tomcat repeatedly?
Not if the service is already failing. Repeated restarts can keep a broken process alive, create port conflicts, and make logs harder to read. Check the cause first, then try again once the issue is addressed.
Can a bad WAR file prevent Tomcat from starting?
Yes. A damaged or incomplete WAR can stop application deployment and, in some cases, interfere with overall service startup. Re-upload a clean copy if the failure began after deployment.
What if the service is stopped but the site still responds?
This usually means an old Java process is still running or another service is answering on the same port. Check the process list and confirm the configured connector ports.
Does changing the Java version affect restart behavior?
Yes. An application that works under one Java runtime may fail under another. If you recently switched Java versions in My App Server, test the previous working version first.
Do I need to reinstall Tomcat after a failed restart?
Usually not. Most restart failures are caused by configuration, deployment, permissions, or runtime selection. Reinstallation is rarely the first or best fix.
Conclusion
A failed Tomcat restart is usually recoverable if you approach it methodically. In a private JVM hosting setup, the fastest path is to stop the service cleanly, confirm the process state, read the logs, verify the Java runtime, and roll back any recent deployment or configuration change. With My App Server in Plesk, you have the practical controls needed to manage Tomcat safely without rebuilding the whole application environment.
If the service still does not start after these checks, provide the exact log errors and the changes made before the failure. That information usually shortens recovery time and helps isolate whether the issue is with the Tomcat service, the Java runtime, or the application itself.