Restarting a Linux server is straightforward but consequential. Every running process is terminated, every network connection is dropped, and the system goes through a full shutdown and boot sequence. On a web server, that means every visitor gets an error page until the system comes back up. On a database server, any in-progress transactions are rolled back.
Most of the time, you do not need to restart the entire server. Restarting a single service (Nginx, PHP-FPM, MySQL) is faster, less disruptive, and solves the majority of issues that make people reach for a full reboot. This guide covers both: how to restart the whole system when you genuinely need to, and how to restart individual services when that is sufficient.
Restarting the entire system#
sudo reboot
The simplest command:
sudo reboot
This initiates an immediate, graceful shutdown and restart. “Graceful” means the system sends a termination signal to all running processes, waits briefly for them to clean up, then shuts down. It is equivalent to pressing the reboot button in a hosting control panel.
If you are connected via SSH, your connection drops as the system goes down. You need to wait for the system to come back up and reconnect. On most servers, the full reboot cycle takes 30 seconds to a few minutes depending on hardware, filesystem checks, and how many services need to start.
sudo shutdown -r now
sudo shutdown -r now
Does the same thing as
sudo reboot
. The
-r
flag means restart (as opposed to
-h
for halt/power off). The
now
argument means do it immediately.
The
shutdown
command is more flexible than
reboot
because it accepts a time argument and can broadcast a warning message. More on that below.
systemctl reboot
sudo systemctl reboot
The systemd way to reboot. On modern Linux distributions (Ubuntu 16.04+, Debian 8+, CentOS 7+), this is what
reboot
calls internally. The result is identical.
Which command to use
All three commands produce the same result. Use whichever you remember.
sudo reboot
is the shortest and most common.
Scheduled restart#
Restart at a specific time
sudo shutdown -r 02:00
Schedules a restart for 2:00 AM. The system continues running normally until then. Other users logged in via SSH see a broadcast warning that a shutdown is pending.
Restart after a delay
sudo shutdown -r +10
Restarts in 10 minutes. The number is in minutes.
Restart with a warning message
sudo shutdown -r +5 "Server restarting for kernel update in 5 minutes"
The message is broadcast to all logged-in users. This is courteous on multi-user systems and useful for documentation (the message appears in system logs).
Cancel a scheduled restart
sudo shutdown -c
Cancels a pending scheduled shutdown or restart. Only works if you used
shutdown
with a time argument. An immediate
reboot
or
shutdown -r now
cannot be cancelled because it executes immediately.
Shutdown without restarting#
Power off
sudo shutdown -h now
Or:
sudo poweroff
These halt the system and power it off. On a physical server, the machine turns off. On a VPS or cloud instance, the virtual machine stops. You need to start it again through the hosting provider’s control panel or API.
Difference between restart and shutdown
A restart (
reboot
,
shutdown -r
) stops the system and immediately starts it again. A shutdown (
poweroff
,
shutdown -h
) stops the system and leaves it off. On a remote server, a shutdown means you lose access until someone or something powers it back on. Only shut down a remote server if you have a way to turn it back on (hosting control panel, IPMI/iLO access, or someone physically at the machine).
Restarting services#
Most problems that seem like they need a full server restart actually need a service restart. Configuration changes, memory leaks, stuck processes — these are all resolved by restarting the specific service.
Restart a service with systemctl
sudo systemctl restart nginx
This stops and starts the service. There is a brief interruption while the service is down.
Common service restarts
# Web server
sudo systemctl restart nginx
sudo systemctl restart apache2
# PHP-FPM (replace version number)
sudo systemctl restart php8.3-fpm
# Database
sudo systemctl restart mysql
sudo systemctl restart mariadb
# SSH server
sudo systemctl restart sshd
# Cron daemon
sudo systemctl restart cron
Reload vs restart
sudo systemctl reload nginx
A reload tells the service to re-read its configuration files without stopping. The service stays running and continues handling requests while applying the new configuration. Not all services support reload, but the important ones do:
| Service | Supports reload? | What reload does |
|---|---|---|
| Nginx | Yes | Re-reads config, gracefully replaces worker processes |
| Apache | Yes | Re-reads config, gracefully restarts workers |
| PHP-FPM | Yes | Re-reads pool config, gracefully replaces workers |
| MySQL/MariaDB | No | Must use restart |
| SSH (sshd) | Yes | Re-reads sshd_config, applies to new connections only |
When to reload: after changing a configuration file (nginx.conf, php.ini, pool.d config). Reload is preferred because there is zero downtime. Existing connections finish normally while new connections use the updated configuration.
When to restart: after installing a new version of the software, when the service is in a bad state (memory leak, stuck workers), or when reload is not supported. Restart causes a brief interruption.
Check service status
sudo systemctl status nginx
Shows whether the service is running, its PID, memory usage, and recent log entries. If a restart failed, the status output usually includes the error message explaining why.
Start and stop a service
sudo systemctl stop nginx
sudo systemctl start nginx
Stop halts the service. Start launches it. Restart is equivalent to stop followed by start. Sometimes you need to stop a service, make a change (like editing a file that the service locks), and then start it again.
Enable and disable a service
sudo systemctl enable nginx
sudo systemctl disable nginx
Enable means the service starts automatically at boot. Disable means it does not. This does not affect the current running state — a disabled service that is currently running continues running until the next reboot or until you stop it.
What happens during a restart#
Understanding the shutdown and boot sequence helps you predict what will happen and how long it takes.
Shutdown sequence
- The init system (systemd) sends SIGTERM to all running processes
- Processes have a grace period (typically 90 seconds) to clean up and exit
- Any processes still running after the grace period receive SIGKILL (forced termination)
- Filesystems are synced and unmounted
- The kernel halts or reboots
Step 2 is why a graceful reboot matters. Database servers use this time to flush buffers and complete transactions. Web servers use it to finish serving in-flight requests. A hard power cut (or
reboot -f
) skips this, which can cause data corruption.
Boot sequence
- Hardware initialization (BIOS/UEFI)
- Bootloader loads the kernel
- Kernel initializes hardware and mounts the root filesystem
- systemd starts, reads its configuration, and starts services in dependency order
- Network interfaces come up
- Services start (SSH, Nginx, PHP-FPM, MySQL, etc.)
- The system is ready to accept connections
On a VPS, steps 1-2 are handled by the hypervisor and take seconds. On physical hardware, they can take 30-60 seconds. Steps 3-6 typically take 10-30 seconds on a well-configured server.
Impact on running processes
Everything stops during a restart. This includes:
- Web server connections. Every active HTTP connection is dropped. Visitors see a connection error or timeout. If you have a load balancer in front of multiple servers, take the server out of the pool before restarting.
- Database connections. Active queries are terminated. InnoDB (the default MySQL/MariaDB storage engine) is crash-safe, so committed transactions are preserved. Uncommitted transactions are rolled back on startup.
- SSH sessions. Your SSH connection drops. If you are running a long command, it stops unless you ran it inside
screenortmux. - Cron jobs. Any currently running cron job is terminated mid-execution.
- Background processes. Anything running in the background (queue workers, daemons, scripts) is killed.
When to restart the whole server#
A full reboot is the correct action in a limited number of situations:
Kernel update. A new kernel is installed but not loaded until the system reboots. The
needs-restarting
command (CentOS/RHEL) or checking
/var/run/reboot-required
(Ubuntu/Debian) tells you if a reboot is pending.
# Ubuntu/Debian
cat /var/run/reboot-required 2>/dev/null
If this file exists, a reboot is needed (usually after a kernel or libc update).
Unresponsive system. If the system is so overloaded that you cannot reliably stop individual services, a reboot clears everything. This is a last resort.
Hardware changes. After adding memory, changing CPU count (on a VM), or modifying hardware parameters that the kernel reads at boot.
Filesystem issues. If the root filesystem needs a consistency check (
fsck
), it can only run safely at boot time when the filesystem is not mounted read-write.
When NOT to restart the whole server#
After changing Nginx configuration. Reload Nginx instead:
sudo nginx -t && sudo systemctl reload nginx
The
nginx -t
tests the configuration for syntax errors first. If the test passes, reload applies it with zero downtime.
After changing PHP configuration. Restart PHP-FPM only:
sudo systemctl restart php8.3-fpm
After a PHP-FPM worker pool exhaustion. Restart PHP-FPM to clear stuck workers:
sudo systemctl restart php8.3-fpm
After a MySQL/MariaDB issue. Restart the database service only:
sudo systemctl restart mysql
After installing or updating a package. The package manager tells you if a service restart is needed. Restart only that service.
In all these cases, restarting the affected service takes 1-2 seconds and only interrupts that specific service. A full server reboot takes 30+ seconds and interrupts everything.
Restarting remotely over SSH#
If you are connected to the server via SSH and issue a reboot, your connection drops immediately. The server restarts without your input. To run the reboot and reconnect:
sudo reboot
Wait 30-60 seconds, then reconnect:
ssh user@your-server
If the server does not come back, check the hosting provider’s console for boot errors.
For more on running commands remotely without an interactive session, see How to run commands over SSH.
Keeping a process running through a reboot
If you need a process to survive a restart (for example, a long-running import), create a systemd service for it or add it to a startup script. Processes running in a regular shell session do not survive a reboot. The
screen
and
tmux
tools keep processes running through SSH disconnections, but not through reboots.
Restarting services on Hostney#
On Hostney, each account runs in an isolated container. You do not have root access and cannot restart the entire server. Services like Nginx, PHP-FPM, and MySQL are managed by the platform.
To restart PHP-FPM (the most common need after changing PHP settings), go to Hosting > PHP Manager in the control panel. Changes to PHP variables take effect immediately without manual restarts.
For SSH access to your container, see the Terminal Access section in the control panel. While you cannot restart system services via SSH on Hostney, you can use SSH to manage your WordPress installation, run WP-CLI commands, and troubleshoot issues.