If a Java deployment fails to restart, the fastest way to recover is to treat it as a service issue first and an application issue second. In a hosted Java environment, a failed restart often means Tomcat or the private JVM did not come back cleanly, a port is still in use, the Java process exited because of a configuration problem, or the application itself stopped the startup sequence before it became ready. In a control panel environment such as Plesk with a Java hosting extension like My App Server, you can usually identify and fix the problem without SSH access, as long as you know which signals to check and which recovery steps are safe.
This guide explains how to recover after a failed restart for a Java deployment in a managed hosting setup, with a focus on private JVM and Tomcat-based applications. It is especially relevant for JSP, servlet, and WAR deployments that run under a service you control from the panel.
What a failed restart usually means
A failed restart does not always mean the application is broken. In many cases, it means one of the following happened during service startup:
- The Tomcat or Java service did not stop fully before the restart started.
- A port used by the app is still occupied by another process.
- The configured Java version is not compatible with the deployed application.
- The application has a startup error, missing file, or invalid configuration.
- The JVM ran out of memory during initialization.
- The deployment package was incomplete or corrupted.
- A custom runtime setting, environment variable, or context file is preventing startup.
In a hosted environment, the goal is to restore service safely without creating a second failure by repeatedly clicking restart. Repeated restarts can make logs harder to read and can sometimes leave the process in a confused state if shutdown was not clean.
First checks after the restart fails
Before changing anything, check the current service state in the control panel. In My App Server or a similar Java hosting control interface, look for these details:
- Whether the service is shown as running, stopped, or failed.
- The time of the last restart attempt.
- Any visible error message from the service control page.
- The configured Java version and Tomcat version.
- The application root, deployment path, and context path.
- Recent log entries for startup and shutdown.
If the panel shows that the service is still running but the site is unavailable, the restart may not have completed properly or the application may have started but failed its web layer. If the panel shows the service as stopped or failed, focus on the startup logs and configuration.
Check whether the stop step completed
One of the most common reasons for a failed restart is an incomplete stop. The previous Java process may still be bound to the configured port. If the panel offers separate stop and start actions, use them instead of pressing restart again immediately. Allow a short pause after stopping so the process can release resources cleanly.
If the application was forcefully stopped or the hosting platform performed an automatic recovery, the service may need a full stop-start cycle rather than a single restart command.
Safe recovery steps in Plesk or My App Server
Use the following recovery sequence when a Java deployment does not restart successfully.
1. Open the service control page
Go to the Java service or application server section in the control panel. In a My App Server setup, this is where you can manage the private JVM, Tomcat instance, and deployment-related service actions.
Confirm the selected application server is the one tied to the failing site or domain. If more than one Java runtime or custom app server exists in the account, it is easy to act on the wrong service.
2. Stop the service cleanly
If the service is still marked as running, stop it first. Wait until the panel confirms the process has ended. Do not attempt to restart repeatedly while the stop is still in progress.
If the service does not stop cleanly, note the exact message. A stuck stop often points to a hanging thread, a blocked shutdown hook, or a process that needs manual cleanup by support staff.
3. Review the startup and shutdown logs
Logs are the most important source of recovery information. Check the most recent startup log, Catalina output, application log, and any runtime messages produced by the control panel. Look for:
- Java version mismatch errors.
- Port binding errors such as address already in use.
- Class loading failures or missing dependencies.
- Permission errors on deployment folders.
- OutOfMemoryError messages.
- XML or property file parsing errors.
- Context path conflicts or deployment descriptor issues.
If the logs show a clear application error, fix that first. If the logs do not show enough detail, a second startup attempt after confirming the configuration may produce a cleaner error message.
4. Verify the Java runtime version
Incorrect Java version selection is a common cause of failed restarts in hosted Tomcat environments. Some applications require an older Java release, while newer frameworks may require a more recent one. If your hosting platform offers several ready-to-install Java versions, verify that the application is using the intended one.
Check the following:
- Whether the deployed application was built for the selected runtime.
- Whether the JVM version matches the application documentation.
- Whether a manual runtime upload was updated correctly after a change.
If you recently changed the Java version, return to the previously known working version and try again. This is often the quickest way to recover service.
5. Confirm that the port is free
Tomcat and private JVM deployments typically rely on specific ports for HTTP or internal connectors. If another process is using the same port, startup will fail. In panel-based hosting, you may not need to inspect system tools directly, but the log will usually mention the port conflict.
To recover safely:
- Make sure the previous instance is fully stopped.
- Check whether another app in the same account was moved to the same port.
- Restore the default port assignment if it was changed recently.
- Ask support to check for a process that did not release the port if the issue persists.
6. Recheck the deployment package
If the application was deployed from a WAR file or exploded directory, confirm that the package is complete and consistent. A failed upload, interrupted deployment, or corrupted archive can prevent startup.
Useful checks include:
- Re-uploading the WAR file from a known good build.
- Making sure the deployed version matches the source control release.
- Checking for missing libraries in the WEB-INF folder.
- Confirming that configuration files were not overwritten during deployment.
When possible, test the package locally or in a staging environment before trying another restart in production.
7. Review memory settings
If the service starts and then exits quickly, memory settings may be too aggressive for the application. A private JVM on shared hosting should be sized realistically for the application’s actual needs. Too little heap can prevent initialization. Too much can also cause instability if the account limits are exceeded.
Look for:
- Xms and Xmx values that are too large for the plan.
- Metaspace or permgen settings that are incompatible with the selected Java version.
- Memory spikes during startup caused by large frameworks or caches.
Lowering the memory footprint or restoring default settings is a common recovery step. If the application only starts with a specific memory profile, document it before making further changes.
Common causes and how to fix them
Application error during startup
Some applications fail because of an exception raised as soon as Tomcat loads the web app. This can happen if the application expects a database connection, a missing environment variable, or a configuration file that is not present on the hosting account.
Recovery steps:
- Inspect the application log for the first exception, not only the final shutdown line.
- Verify database credentials and connection URLs.
- Check whether any config file was changed during the last deployment.
- Restore the previous working build if needed.
Tomcat connector or port conflict
If the web connector cannot bind to its port, the service cannot complete startup. This is usually visible in the log and often happens after an unclean shutdown or a duplicate service configuration.
Recovery steps:
- Stop the service fully and wait a moment.
- Ensure no duplicate instance exists under another name.
- Reapply the default connector settings if they were edited.
- Contact support if the port remains busy after a clean stop.
Java version incompatibility
Some deployments are built for a specific Java release. A service may appear to restart, then fail because classes, libraries, or framework features are not supported by the current runtime.
Recovery steps:
- Return to the last working Java version.
- Check the application release notes or build target.
- Install or select a compatible runtime from the panel if available.
Insufficient permissions
Startup may fail if the JVM cannot read deployment files or write to temporary folders. This can happen after a manual file upload, permission change, or partial restore.
Recovery steps:
- Confirm file ownership and permissions for the app directory.
- Make sure temporary and log directories are writable.
- Review whether the deployment was unpacked with the correct structure.
Broken or partial deployment
If the application was updated just before the restart failed, the deployment itself may be the source of the issue. A missing library, bad class file, or incomplete WAR upload can block startup.
Recovery steps:
- Roll back to the last known good deployment.
- Re-upload the release artifact.
- Clear any stale extracted files if the panel workflow supports it.
When to use rollback instead of troubleshooting further
If the application was working before the restart and failed immediately after a change, rollback is often the fastest recovery option. This is especially true when:
- The failure started after a deployment update.
- A new Java version was selected just before the problem.
- A configuration file was edited recently.
- The logs show multiple unrelated startup errors.
Restore the previous stable package, Java version, and runtime settings, then restart once. This reduces downtime and avoids more changes while the root cause is still unclear.
What not to do after a failed restart
To avoid making recovery harder, do not:
- Click restart repeatedly without checking logs.
- Change several runtime settings at the same time.
- Delete log files before reviewing them.
- Replace the whole deployment package without keeping a backup.
- Switch Java versions blindly without confirming application compatibility.
A controlled approach makes it easier to identify whether the problem is in the service layer, the runtime layer, or the application itself.
How to verify that recovery worked
After applying a fix and starting the service again, confirm that the deployment is actually healthy. Do not rely only on the service status indicator.
- Check that the service is shown as running in the panel.
- Open the application URL and confirm it loads correctly.
- Review the latest log entries for a clean startup sequence.
- Verify that login, form submission, or API routes work as expected.
- Confirm that no repeated restarts are being triggered by a monitoring script or deployment hook.
If the site loads but one function fails, the service may be up while the application still has a configuration problem. That should be treated separately from the restart issue.
Best practices for future restarts
A stable Java hosting setup is easier to recover when restart operations are handled consistently. These habits reduce failed restart incidents:
- Keep one documented working Java version per application.
- Record the standard memory and connector settings.
- Use staged deployment before updating production.
- Keep a known good WAR or backup build available.
- Review logs after every deployment, not only after a failure.
- Avoid changing multiple runtime variables in one maintenance window.
For Tomcat hosting and private JVM setups, clear documentation of the runtime profile saves time when a restart goes wrong.
When to contact support
Contact hosting support if the service still fails after you have checked the logs, confirmed the Java version, and tried a clean stop-start cycle. Support is especially useful when:
- The service does not stop or start from the panel.
- The logs show a port conflict that you cannot resolve.
- The panel shows an internal service error.
- You suspect a platform-side process is still holding resources.
- The application needs a runtime check beyond what the control panel exposes.
When opening a support request, include the application name, domain, exact error message, time of the failed restart, and any recent changes to Java version, WAR file, or configuration.
FAQ
Why did my Java app fail after a simple restart?
A restart can fail if the previous process did not shut down fully, if the app has a startup error, if the Java version is wrong, or if a port is already in use. The restart itself is often only the trigger that reveals the underlying problem.
Should I click restart again immediately?
No. First check whether the service stopped cleanly and review the logs. Repeating the action too quickly can hide the original error and make recovery harder.
Can I fix a failed restart from the control panel only?
Often yes. In many hosted Java environments, especially with My App Server and Plesk-based control, you can stop the service, check logs, change runtime settings, and redeploy without SSH access.
What is the fastest recovery path if the app worked before?
Return to the last known working Java version, restore the previous WAR or configuration, stop the service cleanly, and start it again. This usually restores service faster than deep troubleshooting.
How do I know whether the problem is in Tomcat or in the application?
If the service fails before the web app loads, the issue is often in Tomcat, the JVM, port binding, or panel settings. If Tomcat starts but the site throws errors, the problem is more likely inside the application or its configuration.
Can memory settings cause restart failure?
Yes. Too little memory can prevent startup, and unrealistic memory values can also break the service under shared hosting limits. Check JVM heap and runtime settings if the service exits during initialization.
What should I send support if I cannot recover it myself?
Send the domain name, service name, time of failure, current Java version, recent deployment changes, and the exact log error. This helps support identify whether the issue is a startup conflict, configuration error, or runtime problem.
Conclusion
Recovering after a failed restart for a Java deployment is usually a structured process: stop the service cleanly, read the logs, verify the Java runtime, check for port conflicts, confirm the deployment package, and restore the last known good configuration if needed. In a managed Java hosting environment with private JVM control, Tomcat service management, and Plesk integration, this approach is usually enough to bring the application back online quickly and safely.
If the restart failure is caused by a configuration change or a corrupted deployment, rollback is often the fastest and safest fix. If the platform shows a service-level problem that you cannot clear from the panel, escalate with the relevant logs and details so the issue can be reviewed efficiently.