systemctl / service
| Since: | systemctl | All Linux |
|---|---|---|
| service | All Linux |
systemctl is the command for managing services (daemons) through systemd. It covers the entire service lifecycle — starting, stopping, restarting, and configuring automatic startup. The older service command (SysVinit) also works in systemd environments through a compatibility layer.
Syntax
Basic service operations use the following form. UNIT is the service name (e.g., nginx, sshd).
systemctl start UNIT systemctl stop UNIT systemctl restart UNIT systemctl reload UNIT systemctl status UNIT systemctl enable UNIT systemctl disable UNIT
To list units, use the following commands.
systemctl list-units [--type=service] systemctl list-unit-files [--type=service]
After editing a unit file, the systemd configuration needs to be reloaded.
systemctl daemon-reload
Command List
| Command | Description |
|---|---|
| systemctl start UNIT | Starts the service immediately. |
| systemctl stop UNIT | Stops the service immediately. |
| systemctl restart UNIT | Stops and then starts the service. |
| systemctl reload UNIT | Reloads the configuration file without restarting the process (only for services that support it). |
| systemctl status UNIT | Shows the service state, PID, and recent log entries. |
| systemctl enable UNIT | Configures the service to start automatically on OS boot (does not start it immediately). |
| systemctl disable UNIT | Disables automatic startup on OS boot (does not stop the service immediately). |
| systemctl is-active UNIT | Checks whether the service is running (outputs active or inactive). |
| systemctl is-enabled UNIT | Checks whether automatic startup is configured (outputs enabled or disabled). |
| systemctl list-units | Lists currently loaded units. |
| systemctl list-unit-files | Lists all installed unit files and their auto-start state. |
| systemctl daemon-reload | Tells systemd to reload unit files from disk. |
Basic Service Management
Start capsule_corp_api.service and check its status.
sudo systemctl start capsule_corp_api
systemctl status capsule_corp_api
● capsule_corp_api.service - Capsule Corp API Server
Loaded: loaded (/etc/systemd/system/capsule_corp_api.service; enabled; preset: disabled)
Active: active (running) since Thu 2026-04-09 10:00:00 JST; 3s ago
Main PID: 12345 (python3)
Stop and restart the service.
sudo systemctl stop capsule_corp_api sudo systemctl restart capsule_corp_api
Enable automatic startup on OS boot. enable only configures the next boot — it does not start the service right away.
sudo systemctl enable capsule_corp_api sudo systemctl start capsule_corp_api
Use enable --now to enable and start in a single step.
sudo systemctl enable --now capsule_corp_api
List services. list-units shows currently loaded units; list-unit-files shows all installed ones.
systemctl list-units --type=service systemctl list-unit-files --type=service UNIT FILE STATE PRESET capsule_corp_api.service enabled disabled dragon_radar.service disabled disabled gravity_chamber.service enabled disabled
Unit File Locations
Unit files (.service files) are placed in the following directories.
| Path | Purpose |
|---|---|
| /etc/systemd/system/ | Unit files created or customized by the administrator. Loaded with the highest priority. |
| /usr/lib/systemd/system/ | Unit files installed by the package manager (yum/apt, etc.). Editing these files directly causes the changes to be overwritten on the next package update. |
| /run/systemd/system/ | Dynamically generated unit files at runtime. Removed on reboot. |
To customize a package's unit file, place a file with the same name under /etc/systemd/system/, or use systemctl edit to create a drop-in file.
sudo systemctl edit dragon_radar
Creating a Custom Service
You can manage any process as a service by creating a unit file under /etc/systemd/system/. The file name must be service-name.service.
/etc/systemd/system/gravity_chamber.service
[Unit] Description=Gravity Chamber Training Scheduler After=network.target [Service] Type=simple User=vegeta ExecStart=/usr/local/bin/gravity_chamber_server --config /etc/gravity_chamber/config.yml ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
After creating the file, run daemon-reload before starting the service.
sudo systemctl daemon-reload
sudo systemctl enable --now gravity_chamber
systemctl status gravity_chamber
● gravity_chamber.service - Gravity Chamber Training Scheduler
Loaded: loaded (/etc/systemd/system/gravity_chamber.service; enabled; preset: disabled)
Active: active (running) since Thu 2026-04-09 10:05:00 JST; 2s ago
Key sections and settings are described below.
| Section / Key | Description |
|---|---|
| [Unit] Description | Human-readable description shown by systemctl status. |
| [Unit] After | Units that must be started before this service (dependency ordering). |
| [Service] Type | Process startup model: simple (foreground process), forking (daemonizes via fork), oneshot (runs once and exits), etc. |
| [Service] User | User account to run the process as. Defaults to root if omitted. |
| [Service] ExecStart | The command to run. Must be an absolute path. |
| [Service] Restart | Restart policy when the process exits (on-failure, always, etc.). |
| [Install] WantedBy | Specifies which target pulls in this service when enable is run. Typically multi-user.target. |
Viewing Logs with journalctl
systemd logs are accessed via journalctl. Use the -u option to filter by service.
journalctl -u gravity_chamber Apr 09 10:05:00 server gravity_chamber_server[12345]: Starting Gravity Chamber... Apr 09 10:05:01 server gravity_chamber_server[12345]: Gravity multiplier set to 450G
The -f option tails the log in real time (press Ctrl+C to exit).
journalctl -u gravity_chamber -f
Use --since and --until to narrow the time range.
journalctl -u capsule_corp_api --since "2026-04-09 09:00:00" journalctl -u capsule_corp_api --since "1 hour ago" journalctl -u capsule_corp_api --since today
To view logs from multiple services at once, repeat the -u option.
journalctl -u gravity_chamber -u dragon_radar --since today
Differences from the service Command
The service command is a compatibility layer from the SysVinit era. On systemd systems, running service internally forwards the call to systemctl.
| service (SysVinit) | systemctl (systemd) |
|---|---|
| service nginx start | systemctl start nginx |
| service nginx stop | systemctl stop nginx |
| service nginx restart | systemctl restart nginx |
| service nginx status | systemctl status nginx |
| chkconfig nginx on | systemctl enable nginx |
| chkconfig nginx off | systemctl disable nginx |
service directly invokes SysV scripts under /etc/init.d/ and is a simple wrapper. It does not provide the advanced features that systemd offers, such as dependency management, centralized log collection, socket-based activation, and cgroup-based resource control.
Overview
The smallest unit in systemd is called a "unit." Types include .service (services), .socket (sockets), .timer (timers), and .mount (mount points). systemctl is the front-end for managing all of these unit types.
enable works by creating a symbolic link under a directory such as /etc/systemd/system/multi-user.target.wants/. disable simply removes that link — it has no effect on whether the service is currently running.
reload sends a signal to the process asking it to re-read its configuration file, without stopping or restarting the process. This only works for services that support it. For services that do not handle reload signals, use restart instead.
Common Mistakes
Common Mistake 1: Confusing enable with start
enable configures the service to start automatically at the next OS boot — it does not start the service right now. A common source of confusion is running enable after installation and wondering why the service is not running.
sudo systemctl enable dragon_radar
sudo systemctl status dragon_radar
○ dragon_radar.service - Dragon Radar Service
Loaded: loaded (/etc/systemd/system/dragon_radar.service; enabled; preset: disabled)
Active: inactive (dead)
The service shows enabled but Active: inactive. You also need start to run it now.
sudo systemctl enable dragon_radar
sudo systemctl start dragon_radar
systemctl status dragon_radar
● dragon_radar.service - Dragon Radar Service
Loaded: loaded (/etc/systemd/system/dragon_radar.service; enabled; preset: disabled)
Active: active (running) since Thu 2026-04-09 10:10:00 JST; 1s ago
Use enable --now to enable and start the service in a single command.
sudo systemctl enable --now dragon_radar
Common Mistake 2: Forgetting daemon-reload after editing a unit file
If you edit a unit file without running daemon-reload, systemd does not see the changes. Restarting the service will still use the old configuration.
sudo vi /etc/systemd/system/training_scheduler.service sudo systemctl restart training_scheduler Warning: The unit file, source configuration file or drop-ins of training_scheduler.service changed on disk. Run 'systemctl daemon-reload' to reload units.
The correct sequence is: edit → daemon-reload → restart.
sudo vi /etc/systemd/system/training_scheduler.service sudo systemctl daemon-reload sudo systemctl restart training_scheduler
When using systemctl edit UNIT, daemon-reload is run automatically, so no manual step is needed. Only files edited directly on disk require a manual daemon-reload.
If you find any errors or copyright issues, please contact us.
シェアする