Mastering Service Management: How to Start a Service in Linux Using Systemd and Legacy Tools
Understanding how to start and manage services in Linux is critical for system admins and developers alike. It ensures applications run smoothly, helps maintain system stability, and empowers you to troubleshoot proactively—cutting downtime and headaches. Instead of memorizing a long list of commands, let's focus on the strategic logic behind Linux service management: why systemd revolutionized this area, how to use both systemd and legacy init scripts effectively, and when each approach fits best.
Why Learning Service Management Matters
In Linux, a “service” is essentially a background program or daemon that performs important tasks (like web servers, database servers, or schedulers). Starting a service properly means ensuring your app or server boots up as expected, restarts on failure if configured, and stops cleanly when no longer needed.
System administrators often face situations requiring manual service control:
- Deploying new software
- Debugging failed services
- Optimizing startup times
- Managing server resources dynamically
Mastering how to start services directly with both modern tools (systemd) and older methods using SysV init scripts empowers you with maximum flexibility.
Enter systemd: The Modern Standard for Service Management
Introduced by Lennart Poettering and others in 2010, systemd replaced the older SysV init system on most modern Linux distributions (Fedora, Ubuntu since 15.04+, Debian 8+, CentOS 7+, and more).
Systemd provides:
- Parallelized service startup
- Sophisticated dependency management
- On-demand starting of daemons
- Better logging via journalctl
- Unified commands via
systemctl
How to Start a Service with systemd
Starting a service is simple:
sudo systemctl start <service-name>
For example, starting the Apache web server (httpd) on CentOS / RHEL systems:
sudo systemctl start httpd
On Debian/Ubuntu systems where Apache’s service is apache2:
sudo systemctl start apache2
You can also enable automatic start at boot:
sudo systemctl enable <service-name>
Check service status with:
sudo systemctl status <service-name>
Practical Example: Start and Monitor SSHD
sudo systemctl start sshd # Start SSH daemon immediately
sudo systemctl enable sshd # Enable SSHD at boot time
sudo systemctl status sshd # Check current state & logs info
Legacy Tools: Managing Services with SysV Init Scripts
Before systemd became widespread, services were managed by traditional init scripts stored under /etc/init.d/ or /etc/rc.d/init.d/.
They can still be found on older systems or minimal installs without full systemd support.
How to Start Services Using Init Scripts
Simply run the init script with the start argument as root:
sudo /etc/init.d/<service-name> start
Example for starting Apache (named "apache2" in Debian):
sudo /etc/init.d/apache2 start
You can also use the service command that wraps around these scripts:
sudo service apache2 start
While this interface has been superseded by systemctl, it remains available for compatibility.
When To Use Which Method?
| Scenario | Recommended Approach |
|---|---|
| Modern distributions using systemd | Use systemctl |
| Older Linux versions without systemd | Use service or init scripts |
| Scripts or custom daemons lacking a systemd unit | Use legacy method first; consider creating custom units |
If you’re on a modern distro but working with legacy software that hasn’t yet adopted native unit files, you might fall back to calling init scripts directly.
Bonus: Creating Your Own Systemd Service Unit File
To deeply master Linux services, you’ll want to create your own unit files instead of relying solely on default units or legacy scripts.
A minimal unit file example (/etc/systemd/system/myapp.service):
[Unit]
Description=My Custom App Service
After=network.target
[Service]
ExecStart=/usr/local/bin/myapp --serve
Restart=on-failure
[Install]
WantedBy=multi-user.target
Reload the daemon to recognize new unit files:
sudo systemctl daemon-reload
Start your custom app:
sudo systemctl start myapp.service
Enable it at boot:
sudo systemctl enable myapp.service
Summary: Key Commands Cheat Sheet
| Task | Systemd Command | Legacy Command |
|---|---|---|
| Start service | sudo systemctl start <service> | sudo service <service> start |
| Stop service | sudo systemctl stop <service> | sudo service <service> stop |
| Restart service | sudo systemctl restart <service> | sudo service <service> restart |
| Check status | sudo systemctl status <service> | sudo service <service> status |
| Enable at boot | sudo systemctl enable <service> | varies—usually manually linking scripts |
| Disable at boot | sudo systemctl disable <service> | varies |
Final Thoughts
Mastering how to start and manage services in Linux starts with understanding why these tools exist and how they work under the hood. Whether using modern systemd commands or falling back to legacy init scripts, having both toolsets in your toolbox empowers you to manage any environment effectively.
Forget rote memorization—grasp the logic behind each method, practice real commands daily, and soon managing services will become second nature on any Linux box you touch.
If you found this helpful or want me to cover creating advanced unit files or troubleshooting failing.service jobs next—drop a comment below!