Skip to content

Knowledgebase

Restarting only the affected Webuzo service

control-panels, servers

Restart the specific Webuzo-managed service only when diagnosis or a configuration change requires it. A panel outage, website outage and database outage involve different processes and should not automatically trigger a reboot of the whole server.

What you need before you begin

Use authorized administrator access. Record the symptom, active connections and relevant log entries before restarting. Validate changed configuration with the service appropriate syntax test and arrange a maintenance window if existing requests or transactions may be interrupted.

01 Restart only the affected Webuzo service

  1. Open Admin Home > Apps > Services and identify the actual affected service. Compare its reported running state with a real client test.
  2. Inspect its recent error log and resource conditions. A full disk or invalid configuration will usually remain broken after a restart.
  3. If a restart is justified, select that service and apply the action once. Avoid Stop unless you intend to leave it unavailable, and avoid Disable when you only need a temporary restart.
  4. Follow the completion result and immediately inspect the service log. Confirm that it remains running instead of entering a repeated crash cycle.
  5. If the Webuzo panel service itself is the problem and the panel cannot open, the documented administrator command webuzo --restart restarts that panel stack. It is distinct from restarting every hosted application service.
  6. Test the affected customer workflow and monitor it for a short period before closing the incident.

Is restarting the Webuzo panel the same as restarting Apache?

No. The panel has its own service stack. Identify whether the failed endpoint is the administrative panel, a hosted website, mail or a database before choosing the action.

Confirm the expected result

Confirm the listener responds, the intended application operation succeeds and no recurring startup error appears. Check that the service remains enabled for future boot when it should be. A running process alone is not sufficient proof that it serves correct requests.

Troubleshoot unexpected results

If startup fails, stop repeated retries and inspect the first error, port conflicts, permissions and resource availability. Restore the last valid configuration when a recent edit caused the problem. Rebooting can erase useful volatile evidence and affect unrelated accounts, so reserve it for a justified host-level condition.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support