Systemd Units
About systemd Units
- Units are the objects that systemd knows how to manage.
- These are basically a standardized representation of system resources that can be managed by systemd
- Each unit is configured by a unit file
- Here's are some of systemd units:
- .service: A service unit describes how to manage a service or application on the server.
- .socket: A socket unit file describes a network or IPC socket.
systemd sets up listening sockets (IP or otherwise) on behalf of your services (without these running yet), and then starts (activates) the services as soon as the first connection comes in. - .device: A unit that describes a device that has been designated as needing systemd management.
You can use that for device based activation - .target: A target unit is used to provide synchronization points for other units when booting up or changing states. They also can be used to bring the system to a new state. Other units specify their relation to targets to become tied to the target’s operations.
- .path: This unit defines a path that can be used for path-based activation. By default, a .service unit of the same base name will be started when the path reaches the specified state. This uses inotify to monitor the path for changes.
- .timer: A .timer unit defines a timer that will be managed by systemd, similar to a cron job for delayed or scheduled activation. A matching unit will be started when the timer is reached.
Example of a .service file
Here's an example:
1[Unit]
2Description=myprog demo service
3
4[Service]
5ExecStart=/bin/bash /usr/bin/myprog
6
7[Install]
8WantedBy=multi-user.target
- The ExecStart definition specifies the program to run
- the WantedBy definition creates a soft-link when we use the enable command.