When the OpenAdmin service fails without logging any errors, you can inspect the service’s status to get clues on the failure source. Running the command below will show the status and recent logs of the OpenAdmin service:
service admin statusIf you encounter a service failure similar to the following output, it indicates a problem with starting the service, possibly due to a misconfiguration or an already running process:
× admin.service - OpenAdmin
Loaded: loaded (/etc/systemd/system/admin.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2024-03-15 18:41:02 WIB; 651ms ago
Process: 377672 ExecStart=gunicorn -c /usr/local/admin/service/service.config.py app:app (code=exited, status=1/F>
Main PID: 377672 (code=exited, status=1/FAILURE)
CPU: 223ms
Mar 15 18:41:02 de.openpanel.co systemd[1]: admin.service: Scheduled restart job, restart counter is at 5.
Mar 15 18:41:02 de.openpanel.co systemd[1]: Stopped OpenAdmin.
Mar 15 18:41:02 de.openpanel.co systemd[1]: admin.service: Start request repeated too quickly.
Mar 15 18:41:02 de.openpanel.co systemd[1]: admin.service: Failed with result 'exit-code'.
Mar 15 18:41:02 de.openpanel.co systemd[1]: Failed to start OpenAdmin.To manually start the process and identify the issue, use:
gunicorn -c /usr/local/admin/service/service.config.py app:appIf the error “Already running on PID XXX (or pid file ‘adminpanel’ is stale)” appears, it suggests a process conflict or a stale PID file. Resolve this by terminating the conflicting process:
kill -9 PID_HEREAfter addressing the conflict, restart the OpenAdmin service to apply the changes:
service admin restartFollowing these steps should successfully restart the OpenAdmin panel, and it will be accessible again:
opencli admin onThis procedure provides a straightforward way to resolve service failures for OpenAdmin by identifying and eliminating process conflicts and ensuring the service is correctly restarted.
