KodeCloud Linux Services
Services in linux help us configure software that run in the background.
- Services make sure that the software runs all the time automatically when the servers are rebooted and follow the right order of startup.
- Web server or database server are example of services.
When we install a web server or docker they are automatically configured as services.
- Starting the services
sudo systemctl start <service-name>
sudo service <service-name> start
- Service command uses
- Stopping a service
sudo systemctl stop <service-name>
- Check the status of the service
sudo systemctl status <service-name>
- Configure a service to start automatically when the system boots up
sudo systemctl enable <service-name>
- We use
disableif we don't want the service to start at startup
How to configure programs as a service¶
systemctlprogram is used to manage systemd services.
- So to use our program as a service it has to be configured as a systemd service.
A systemd service is configured using a systemd unit file which may be located at
- The unit file must be named after the name of the service and must have
ExecStartdirective is where we list the command that we want to run as a service.
- We need to reload the systemd daemon to let systemd know that we have configured a new service.
sudo systemctl daemon-reload
- The final step is to start the service
How do we configure the service to run automatically when the system boots up?
We need to make the following changes to the service file
Now we have to
enable the service to start at boot up.
- We can provide additional meta data information about the service using
- If there are commands or scripts that need to be run before or after starting the service then we can define
If we want the application to restart incase it crashes we can specify
Above was an example for a simple unit service file. It can be much more complex. Docker service example
Diving deeper into services¶
- When a
systemdsystem boots up,
systemdis trying to make the system state match the state specified by
default.target- which is usually an alias for either
multi-user.targetnormally defines a system state where all network services are started up and the system will accept logins, but a local GUI is not started.
- This is the typical default system state for server systems, which might be rack-mounted headless systems in a remote server room.
graphical.targetis another possible alias for
default.target. Normally it's defined as a superset of the
multi-user.target: it includes everything the
multi-user.targetdoes, plus the activation of a local GUI login.
- The line
WantedBy=multi-user.targetin a service tells
systemdthat this service should be started as part of normal system start-up.
WantedByis separate from the enabled/disabled state: so in another sense, it's sort of a "preset": it determines under what conditions the automatic start may happen, but only when the service is enabled in the first place.
- If you omit the
WantedBy=multi-user.targetline and no other enabled service includes a
Wants=your.servicein its service definition, your service will not be started automatically.
systemdworks on dependencies, and at boot time, if nothing
Wantsyour service, it won't be started even if the service is enabled.
- Sure, you could edit your
default.targetto add or delete
Wantslines for any services you want started at boot time - but so that you can just drop a new service file into the system and have it work by default (which makes things very easy for software package managers),
RequiredBykeywords which can be used to insert
Requires-type dependencies (respectively) from "the other end".
- You should omit the
WantedByline if you don't want the service to be ever started automatically at boot time, or this service is a part of a chain of dependencies you've defined explicitly.
- For example, you might be refactoring server application A and for some reason or another decide to split some optional functionality off it into a separate service B, to allow the user the choice of not installing it if it isn't needed.
- You could then make service B a separate
service-B.rpm, and define
systemdstart up service B automatically whenever service A is started - but only when
service-B.rpmis actually installed.
WantedBy only says that the system should startup one service whenever another service or target is also started, but it specifies nothing at all about the startup/shutdown order.
If you need service B to be already running when service A starts up, you'd need to add
Before=A.service in the
B.service file to explicitly specify the start-up order dependency.
Last updated: 2022-10-02