While automatic startup handles what happens at boot, system administrators constantly need to manually start, stop, and restart services throughout the day — after a configuration change, during troubleshooting, or to apply an update. This article covers, from first principles, how to manually control services in Linux using systemctl (the modern standard) and legacy service/init.d commands.
What Does “Manually” Mean Here?
“Manual” service control means an administrator explicitly issues a command to change a service’s running state, as opposed to the system automatically doing so at boot or on a schedule. This is the bread-and-butter, everyday task of any Linux admin — applying a config change and testing it live.
sequenceDiagram
participant Admin
participant systemctl
participant Service
Admin->>systemctl: systemctl start nginx
systemctl->>Service: Launch process
Service-->>systemctl: Running
Admin->>systemctl: systemctl stop nginx
systemctl->>Service: Terminate process
Service-->>systemctl: StoppedThe Core systemctl Commands
Starting a Service
sudo systemctl start nginxThis starts the service immediately. It does not affect whether the service starts automatically at the next boot — that’s controlled separately by enable/disable.
Stopping a Service
sudo systemctl stop nginxSends a stop signal to the service, letting it shut down gracefully.
Restarting a Service
sudo systemctl restart nginxEquivalent to a stop followed immediately by a start. Use this after a configuration change that requires a full process restart.
Reloading a Service (Without Full Restart)
sudo systemctl reload nginxMany services (like Nginx and Apache) support reloading their configuration without dropping active connections — much less disruptive than a full restart. Not all services support this; check with:
systemctl show nginx -p CanReloadReload-or-Restart
sudo systemctl reload-or-restart nginxThis attempts a graceful reload, but falls back to a full restart if the service doesn’t support reloading.
Checking Service Status
systemctl status nginxThis shows whether the service is active, its process ID, memory usage, recent log lines, and more — the single most useful command for quick diagnostics.
Example output interpretation:
● nginx.service - A high performance web server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
Active: active (running) since Fri 2026-07-24 09:12:03 UTC; 3h ago
Main PID: 1423 (nginx)Loadedshows whether the unit file exists and whether it’s enabled for bootActiveshows the current runtime state (running, exited, failed, inactive)
Legacy Command: service
Many distributions still support the older service command as a wrapper, which works even on systemd systems for backward compatibility:
sudo service nginx start
sudo service nginx stop
sudo service nginx restart
sudo service nginx statusInternally, on a systemd-based system, this simply calls the equivalent systemctl command.
Legacy init.d Scripts Directly
On very old SysVinit-based systems (or in some minimal/embedded distros), you invoke the init script directly:
sudo /etc/init.d/apache2 start
sudo /etc/init.d/apache2 stop
sudo /etc/init.d/apache2 restart
sudo /etc/init.d/apache2 statusComparison: Manual Control Commands Across Systems
| Action | systemd (systemctl) | Legacy (service) | Legacy (init.d direct) |
|---|---|---|---|
| Start | systemctl start svc | service svc start | /etc/init.d/svc start |
| Stop | systemctl stop svc | service svc stop | /etc/init.d/svc stop |
| Restart | systemctl restart svc | service svc restart | /etc/init.d/svc restart |
| Status | systemctl status svc | service svc status | /etc/init.d/svc status |
| Reload config only | systemctl reload svc | service svc reload | /etc/init.d/svc reload |
A Practical Walkthrough: Applying a Web Server Config Change
Step 1: Edit the config
sudo nano /etc/nginx/sites-available/mysite.confStep 2: Test the syntax before touching the running service
sudo nginx -tStep 3: Reload gracefully (no dropped connections)
sudo systemctl reload nginxStep 4: Confirm it’s healthy
systemctl status nginx
curl -I http://localhostKilling a Stuck Service Manually
Occasionally a service won’t respond to a normal stop command. You can find and terminate its process directly:
systemctl status myapp # find the Main PID
sudo kill -TERM 4521 # graceful termination request
# if that doesn't work after a few seconds:
sudo kill -KILL 4521 # forceful killsystemctl stop is always preferred over manually killing processes, since it properly runs the service’s defined stop procedure — manual kill should be a last resort.
Real-World Example: Rolling Restart During Deployment
Suppose you’re deploying a new version of an application behind a load balancer with two backend servers. You want zero downtime:
# On server 1:
ssh server1 "sudo systemctl stop myapp && sudo cp -r /deploy/new-version/* /opt/myapp/ && sudo systemctl start myapp"
# Wait for server1 to pass health checks, then repeat on server2:
ssh server2 "sudo systemctl stop myapp && sudo cp -r /deploy/new-version/* /opt/myapp/ && sudo systemctl start myapp"This manual, sequential restart pattern (sometimes automated in CI/CD pipelines) avoids taking both servers down simultaneously.
Best Practices
- Always check
statusafter any start/stop/restart command — don’t assume success just because the command returned without an error message. - Prefer
reloadoverrestartwhen a service supports it, to minimize disruption to active connections. - Test configuration syntax before restarting, using each service’s built-in test flag (
nginx -t,sshd -t,apachectl configtest). - Avoid
kill -9(SIGKILL) as a first resort — it doesn’t allow the process to clean up, which can corrupt data (especially for databases). Usesystemctl stopfirst. - Check logs immediately if a start fails, using
journalctl -u servicename -n 50. - Understand the difference between “started” and “enabled.” Starting a service manually does not make it start automatically after a reboot — you must also
enableit separately.
Troubleshooting
Problem: systemctl start hangs or times out
The service may be waiting on a dependency (like a database or network mount) that isn’t ready. Check:
journalctl -u servicename -n 50 --no-pagerProblem: Job for nginx.service failed
Run the suggested diagnostic command shown in the error output:
systemctl status nginx.service
journalctl -xeProblem: Service shows “active (running)” but isn’t actually working
The process may be running but misconfigured (e.g., listening on the wrong port). Check with:
sudo ss -tlnp | grep nginxProblem: Can’t stop a service — it keeps respawning
Check if it’s configured with Restart=always in its unit file, which will cause it to restart itself even after a manual stop attempt during a crash loop. You may need to systemctl stop immediately followed by fixing the underlying issue, or temporarily mask the service:
sudo systemctl mask servicenamemask prevents the service from being started at all, even manually, until you unmask it.
Problem: “Unit not found” when trying to start a custom service
The unit file may not be recognized yet:
sudo systemctl daemon-reload
systemctl status myappConclusion
Manually starting and stopping services is a daily task for any Linux administrator, and systemctl provides a clean, consistent interface for it across modern distributions — start, stop, restart, reload, and status cover nearly every situation you’ll encounter. Understanding the legacy service and init.d equivalents ensures you’re never stuck when working on an older system. Combined with good habits — testing configs before restarting, checking status after every action, and preferring graceful reloads over hard restarts — manual service management becomes fast, safe, and predictable.
