Systemd is a modern system and service manager for Linux operating systems. It is responsible for managing the startup, shutdown, and maintenance of the system. While systemd itself is not specifically designed as a log management system, it does provide facilities for collecting, storing, and managing logs generated by various services and components running on a Linux system.
Systemd, when executed as the initial process during system boot, is responsible for managing userspace services and maintaining their functionality. The primary command used to interact with systemd is "systemctl."
When the systemctl command is executed without any arguments, it displays a list of all loaded and active units. These units represent various types of objects that systemd operates with. For instance, service units focus on starting and controlling processes, mount units manage mount points, timer units trigger other units based on timers, and so on. In total, there are 11 different types of units. Additional unit types employ specific extensions such as ".service" for service units, ".mount" for mount units, and so forth.
Systemctl provides several commands for managing services in systemd. These commands are fairly intuitive and serve specific purposes. Here are some commonly used systemctl commands for service management:
- Start a service: `systemctl start <name>.service`
- Restart a service: `systemctl restart <name>.service`
- Stop a service: `systemctl stop <name>.service`
- Check the status of a service: `systemctl status <name>.service`
- Enable a service to start on boot: `systemctl enable <name>.service`
- Disable a service from starting on boot: `systemctl disable <name>.service`
It's important to note that when using these commands, if no file extension is provided, `.service` is assumed. For example, `systemctl start <name>` is equivalent to `systemctl start <name>.service`. For a comprehensive list of supported commands and more detailed information, you can refer to the `man systemctl` documentation.
Unit files are used to define units in systemd, and they are written in a configuration file format consisting of key-value pairs organized into sections. Here's an example of a basic service unit file:
[Unit]
Description=My New Service
[Service]
ExecStart=/bin/bash /opt/service.sh
[Install]
WantedBy=multi-user.target
In this example, the unit file defines a service. Let's go through each section and its purpose:
1. `[Unit]`: This section contains general information about the unit.
- `Description`: Provides a human-readable description of the service.
2. `[Service]`: This section specifies how the service should be executed.
- `ExecStart`: Specifies the command or script to start the service.
3. `[Install]`: This section defines installation-related information for the unit.
- `WantedBy`: Indicates the target (in this case, `multi-user.target`) that determines when this unit should be started.
Unit files are typically stored in specific directories, such as `/etc/systemd/system/` for system-wide units or `/etc/systemd/user/` for user-specific units. Once you have created or modified a unit file, you can use systemctl commands (mentioned earlier) to manage the unit, including starting, stopping, enabling, and disabling the service.
It's important to note that unit files can have additional sections and parameters depending on the unit type and specific requirements. The systemd documentation provides comprehensive details on available options and configurations for different unit types.
By utilizing target units and appropriate WantedBy directives in unit files, you can effectively group and orchestrate units to achieve desired system behaviors during initialization.
When installing new software, unit files are typically placed in the `/lib/systemd/system` directory. It is not recommended to directly edit these files because they may be overwritten during software updates. Instead, if you need to modify a unit file or add a new service, you should create a new unit file in the `/etc/systemd/system` directory.
To add a completely new service to the system, follow these steps:
1. Create a new unit file in `/etc/systemd/system` directory. For example, let's say you want to create a service called `my-service`. You would create a file named `/etc/systemd/system/my-service.service`.
2. Edit the newly created `my-service.service` file and define the necessary settings for your service. The file follows the unit file format, including the `[Unit]`, `[Service]`, and `[Install]` sections.
3. Once you've created or modified the unit file, run the following command to reload systemd and apply the changes:
systemctl daemon-reload
4. Start and enable the new service:
systemctl start my-service.service
systemctl enable my-service.service
By placing your custom unit files in `/etc/systemd/system`, they will take precedence over the files in `/lib/systemd/system`. This allows you to safely make modifications or add new services without affecting the original files.
Additionally, if you prefer to keep your unit files in a custom directory, you can use the `systemctl link` command to create a symbolic link to the unit file in `/etc/systemd/system`. For example:
systemctl link /path/to/custom/my-service.service
This creates a symbolic link from `/etc/systemd/system/my-service.service` to the custom unit file location.
Remember that after making changes to unit files or creating new ones, you should always run `systemctl daemon-reload` to ensure systemd recognizes the changes and applies them accordingly.
By running the command `systemctl enable mynewservice.service`, your service will be associated with the `multi-user.target` unit. As a result, the service will be automatically launched during system boot. Under the hood, this dependency is established by creating a symbolic link in the `/etc/systemd/system/multi-user.target.wants/` directory.
When the `disable` command is executed, it removes the symbolic link that establishes the association between the service and the `multi-user.target` unit. As a result, the service is no longer tied to the `multi-user.target` unit, effectively severing the connection.
The logging system used by systemd is called the journal, and it can be accessed and read using the `journalctl` command. There are several useful flags available to enhance your usage of `journalctl`. Here are a few examples:
- `journalctl -b`: Displays all log messages since the last boot.
- `journalctl -x`: Provides explanatory help text for log messages when available.
- `journalctl -f`: Follows and continuously displays new log messages as they are generated.
- `journalctl -u <unit>`: Shows logs only from the specified unit. For instance, `journalctl -u cron` will display logs related to the `cron.service` unit.
Using the command journalctl -u cron -f as an example, it allows you to continuously view the logs that are specifically associated with the cron.service unit.
This command provides a real-time stream of log messages pertaining to the `cron.service` unit, allowing you to monitor its activity as new log entries are generated.
In conclusion, systemd provides powerful log management capabilities through its integrated logging framework called the journal. With the journalctl command, you can effectively access, filter, and analyze logs generated by various system services and components.
The best articles, links, and news delivered once a week to your inbox.