How to Restart a Linux Service Without a Full Reboot on Your VPS
Restart nginx, mysql, php-fpm or any stuck service on your Linux VPS without taking the whole system down. Practical guide with systemctl, validation and troubleshooting.
When a single service on your VPS hangs — nginx stops responding, MySQL refuses connections, php-fpm has a zombie pool — the first instinct is often reboot. But restarting the whole system also takes down every other healthy service, resets legitimate TCP connections, delays recovery by 30 to 90 seconds and can even trigger unnecessary monitoring alerts.
Restarting only the problem service is surgical: it takes 1 to 5 seconds, keeps the rest of the system running and isolates the issue. This guide shows how to do that with systemctl, the difference between restart and reload, how to validate the service is back to normal and how to diagnose when the restart does not solve the problem.
Estimated time: 5 to 10 minutes, depending on the troubleshooting needed.
Prerequisites
You need a Linux VPS running systemd (Ubuntu 20.04+, Debian 11+, Rocky Linux 9+, AlmaLinux 9+), SSH access with a sudo user or root, and the exact name of the service you want to restart. Basic terminal knowledge is assumed.
systemd systemctl journalctl sudo / root If you connect to the VPS via SSH and are not fully comfortable with it yet, it is worth reviewing an SSH connection guide first — some of the commands below assume you will not lose the session mid-operation.
Identify the service that needs to be restarted
Before restarting anything, confirm the exact service name in systemd. Restarting the wrong service rarely causes serious harm, but it wastes time.
List every active service on the system:
sudo systemctl list-units --type=service --state=runningThe output shows three relevant columns: UNIT (name with the .service suffix), LOAD (whether the unit definition was loaded) and ACTIVE (current state). Look for the service you suspect — nginx shows up as nginx.service, MySQL can be mysql.service or mariadb.service, PHP-FPM is usually php8.3-fpm.service.
Filter by name pattern if you are not sure:
sudo systemctl list-units --type=service | grep -i nginxReplace nginx with the term that makes sense. The grep -i flag is case insensitive. If nothing comes back, the service may be stopped (state failed or inactive) — in that case, switch to listing every state:
sudo systemctl list-units --type=service --all | grep -i nginxCheck the detailed state of the service:
sudo systemctl status nginx.serviceLook for the Active: line — it may show active (running), failed, inactive (dead) or activating (auto-restart). The last ten lines of the service log also appear there, giving you an early hint of what may be wrong even before the restart.
Restart the service with systemctl
With the name confirmed, choose between restart (cuts connections) and reload (keeps connections when the service supports it). When in doubt, try-reload-or-restart is the safest option.
For reload without dropping connections (when the service supports it — nginx, apache2, sshd, postgresql, haproxy):
sudo systemctl reload nginx.serviceReload sends a SIGHUP signal to the master process, which re-reads the configuration file and updates workers without killing in-flight TCP connections. If the config has a syntax error, the reload fails but the service keeps running with the previous config — desirable behavior in production.
For a full restart (when reload does not work or the process is stuck):
sudo systemctl restart nginx.serviceRestart stops the process (sends SIGTERM, waits for TimeoutStopSec, then forces SIGKILL if needed) and starts a fresh instance. Active connections drop. Use it when the configuration changed in ways reload does not cover (process user changed, descriptor limits, etc.) or when the process is stuck in an infinite loop and ignores SIGHUP.
For the safe option in scripts and automation:
sudo systemctl try-reload-or-restart nginx.serviceThis command attempts reload first; if the service does not declare reload support in its unit file, it falls back to restart automatically. Avoids errors in scripts that target heterogeneous services.
Before a restart in production, weigh the impact: restarting MySQL during an ongoing backup corrupts the dump. Restarting SSH with a broken config can lock you out — always validate the config (sshd -t) first and keep a parallel session open.
Validate that the service is back to normal
A restart without validation is half the job. Confirm that the service came up, is accepting connections and is responding as expected.
Check the state right after the restart:
sudo systemctl status nginx.serviceThe Active: line should show active (running) with a recent timestamp (seconds ago). Main PID: shows the new PID — if it matches the PID from before the restart, either the command did not run as expected or the service uses a wrapper that keeps the PID stable.
Verify the service is listening on the expected port:
sudo ss -tlnp | grep nginxss -tlnp lists TCP sockets in LISTEN state alongside the process. For an nginx default config you should see :80 and :443. If the port is missing, the process came up but failed to bind — check the service log with journalctl -u nginx.service -n 50.
For HTTP services, perform a response test:
curl -I http://127.0.0.1-I issues a HEAD request, returning only headers. You should see HTTP/1.1 200 OK (or 301/302 if a redirect is configured). If you get Connection refused, the service is not accepting traffic — repeat systemctl status and inspect the log.
Tail the log for a few seconds to make sure there are no errors right after startup:
sudo journalctl -u nginx.service -f-f follows the log (similar to tail -f). Press Ctrl+C to exit. If you see no new messages beyond the startup ones, the service is stable. Recurring errors (“connection refused”, “worker process died”) point to a persistent problem.
Troubleshooting
Not every restart fixes the problem. Here are the three most common scenarios and how to diagnose them.
Service fails to come up after restart
Status shows failed or gets stuck in activating. The cause is almost always invalid configuration or a missing resource.
sudo journalctl -xeu nginx.service -n 100-x adds systemd explanations to the errors, -e jumps to the end of the log, -u filters by service, -n 100 shows the last 100 lines. Typical errors: bind() to 0.0.0.0:80 failed (98: Address already in use) (another instance or service holding the port), nginx: [emerg] open() /etc/nginx/conf.d/site.conf failed (file deleted or wrong permission), invalid number of arguments in "server_name" (broken syntax). For nginx specifically, validate with sudo nginx -t before attempting another restart.
The restart command hangs for minutes
If systemctl restart does not return to the prompt within 10 to 15 seconds, the service is not responding to SIGTERM. From another terminal:
sudo systemctl status nginx.serviceThe Status: line may show stop-sigterm — meaning systemd is waiting for TimeoutStopSec (default 90s). If you cannot wait:
sudo systemctl kill --signal=SIGKILL nginx.serviceSIGKILL kills the process instantly — no buffer flush, no closing of open files, no transaction rollback. Use it only when SIGTERM has failed and you have no alternative. On databases, it can corrupt data.
Service starts but fails seconds later
Status flips between active and failed repeatedly. Look at the Restart= field in the unit file:
sudo systemctl cat nginx.service | grep -i restartIf you see Restart=on-failure with a low RestartSec=, systemd is in a restart loop. The root cause is usually in journalctl — broken config, missing dependency or resource limit hit (memory, file descriptors). Fix the cause before trying again — extra restarts only make things worse.
Next steps
Restarting services is just one piece of routine Linux VPS maintenance. To go further:
- Learn to read centralized logs with
journalctl --since,--untiland priority filters to investigate historical incidents. - Configure
systemd-timerinstead of cron to schedule tasks with better logging and dependencies. - Study
systemctl edit name.serviceto create local overrides without editing the main unit file — useful for adjustingTimeoutStopSecor environment variables without losing the change on the next package update. - Implement an external health check (e.g. monit, a simple script with curl + cron) that catches failure before your users do.
If you are putting a critical application into production, a Hostini VPS ships with Ubuntu LTS and systemd preconfigured, an out-of-band KVM console for access even when SSH is down, and a serial console to recover the system when the config is broken — useful in exactly the situations this tutorial covers.
Frequently asked questions
What is the difference between restart, reload and try-reload-or-restart?
restart stops the process and starts it again (active connections drop). reload sends SIGHUP so the process re-reads its configuration without restarting (connections are preserved — use when the service supports it, like nginx and ssh). try-reload-or-restart attempts reload first and falls back to restart if the service does not support reload — it is the safest option for scripts.
Why does systemctl restart hang without throwing an error?
Usually the service has an ExecStop that never returns or a child process that does not respond to SIGTERM. systemd waits for TimeoutStopSec (default 90s) before sending SIGKILL. Running systemctl status name.service shows the PID that is stuck, and journalctl -u name.service -n 50 reveals the last log line before the hang.
Does restarting a service drop active connections?
It depends. restart yes — the process dies and any in-flight TCP/HTTP connection drops. reload (when supported) preserves open connections because the master process forks a new worker with the updated config and drains the old ones. Nginx, Apache, HAProxy and PostgreSQL all support reload without downtime.
Is it possible to restart a service without sudo?
By default no — systemctl restart, stop and start require root through polkit. You can delegate specific services to non-sudo users by adding rules in /etc/polkit-1/rules.d/, or create a NOPASSWD entry like /bin/systemctl restart nginx.service in sudoers for automation. In production, avoid granting broad sudo — restrict per service.
What should I do if the service fails to come up after a restart?
Check journalctl -xeu name.service — the -xe flag highlights errors and adds context, and -u filters by service. Common causes: configuration file with a syntax error (run the service validator, e.g. nginx -t), port already in use by another process (ss -tlnp | grep :80), or read permission missing on the socket/directory. Fix the root cause and try status again.
Is there an alternative to systemctl on very old VPSes?
Yes — pre-systemd distros (CentOS 6, Ubuntu 14.04 and earlier) use SysV init. Equivalent commands: service name restart, service name reload, /etc/init.d/name restart. Modern distros keep the service command as a wrapper that redirects to systemctl. If you are running in 2025+ and systemctl is missing, consider migrating the VPS — security and support matter.