These are the essential building blocks that provide functionality and efficiency in Ubuntu’s Systemd init system:

• PID 1 – systemd Daemon: The main process responsible for initializing the system during boot. It manages and supervises all other processes and services, ensuring orderly startup and shutdown.
• Unit Files: Configuration files that describe how each resource should be managed. Units can represent system services, sockets, devices, mount points, timers, and more. Located in standardized directories for easy management.
• systemctl Tool: The primary command-line utility for interacting with systemd. It starts, stops, reloads, enables, disables, and inspects the status of services and other units.
• Journal (journald): Integrated logging service that collects, stores, and manages logs from services and the system. Logs are centralized for easier troubleshooting and auditing.
• Targets: Special unit types that group other units and coordinate system states, similar to traditional runlevels. They help organize and sequence the boot process for different usage scenarios, such as multi-user or graphical environments.
• Dependencies and Ordering: A system that defines which units start before or after others, ensuring resources are available when needed and shutdowns occur gracefully.
• Socket and Device Activation: Mechanisms for starting services on demand in response to socket activity or when new devices are detected, optimizing system resource usage.

These commands provide essential control over services and units managed by systemd on Ubuntu systems:

This workflow outlines the steps to create, enable, and manage systemd services on Ubuntu:

1. Create a service unit file:

   Place a custom service definition in the /etc/systemd/system/ directory. This file describes how the service should behave.

2. Reload systemd to recognize the new service:

   Run the following command to instruct systemd to reload its configuration and recognize the added or modified unit files:

   sudo systemctl daemon-reload

3. Enable the service to start on boot:

   Use this command to create the necessary symlinks so the service starts automatically when the system boots:

   sudo systemctl enable <service-name>

4. Start the service immediately:

   To start the service without rebooting the system, execute:

   sudo systemctl start <service-name>

5. Check service status:

   View the current state, logs, and error messages of the service with:

   systemctl status <service-name>

6. Manage the service:

   Use commands like stop, restart, or disable for ongoing control over the service lifecycle:

   • sudo systemctl stop <service-name> – Stop the service
   • sudo systemctl restart <service-name> – Restart the service
   • sudo systemctl disable <service-name> – Disable service from starting at boot

Targets are special unit types that group other units to manage system states and coordinate the startup process on Ubuntu systems:

1. Definition:

   A target is a unit that serves as a synchronization point during boot or shutdown by grouping other units such as services and mount points.

2. Purpose:

   Targets replace traditional runlevels and represent different operating states, like multi-user mode or rescue mode.

3. Common Targets and Their Roles:

   Target	Description	Old Runlevel Equivalent
   multi-user.target	Provides multi-user, non-graphical mode (text login)	3
   graphical.target	Multi-user mode with graphical user interface	5
   rescue.target	Single-user mode for system recovery and maintenance	1
   default.target	The target that the system boots into by default	N/A

4. Changing the Default Target:

   Use the following command to set a different default boot target:

   sudo systemctl set-default <target-name>

5. Viewing Current Default Target:

   Check which target is set as default using:

   systemctl get-default

6. Activating a Target Immediately:

   Switch to a different target without rebooting by running:

   sudo systemctl isolate <target-name>

   This stops all units not required by the new target and starts those that are.

The systemd journal provides a centralized and structured way to collect, manage, and access logs from the system and its services on Ubuntu:

1. journald Service:

   This is the systemd component responsible for collecting logs generated by the kernel, system services, and user processes. Logs are stored in a binary format for efficiency and indexed for easy searching.

2. Viewing Logs with journalctl:

   The journalctl command is used to access and query journal logs.

   • Show all logs:
     journalctl
   • Show logs for a specific service:
     journalctl -u <service-name>.service
   • Display logs in real time (follow):
     journalctl -f
   • View logs for the current boot session:
     journalctl -b
3. Persistent Logging:

   By default, journal logs are stored in volatile memory. To enable persistent logs across reboots, create the directory /var/log/journal:

   sudo mkdir -p /var/log/journal
   sudo systemctl restart systemd-journald

   This ensures logs are saved to disk and available after reboots.

4. Filtering Logs:

   journalctl supports various options to filter logs by time, priority, and more:

   • Show logs with priority errors and above:
     journalctl -p err
   • Show logs from a specific time range:
     journalctl --since "2025-07-20 14:00:00" --until "2025-07-20 15:00:00"
   • Show logs from a specific user session:
     journalctl _UID=1000
5. Rotating and Vacuuming Logs:

   Journald automatically manages log size, but manual cleanup can be done to free space:

   • Remove logs older than 2 days:
     journalctl --vacuum-time=2d
   • Limit log size to 500M:
     journalctl --vacuum-size=500M

This example demonstrates how to create and manage a simple custom service on Ubuntu using systemd:

1. Create the service unit file:

   Create a new file named myapp.service in the /etc/systemd/system/ directory with the following content:

   [Unit]
   Description=My App Service
   After=network.target
   
   [Service]
   ExecStart=/usr/bin/myapp --config /etc/myapp.conf
   Restart=always
   
   [Install]
   WantedBy=multi-user.target
   

2. Reload systemd manager configuration:

   Run this command so systemd recognizes the new service file:

   sudo systemctl daemon-reload

3. Enable the service to start on boot:

   This command ensures the service launches automatically when the system boots:

   sudo systemctl enable myapp

4. Start the service immediately:

   Launch the service without needing to reboot:

   sudo systemctl start myapp

5. Check the status of the service:

   View the current running state, recent logs, and any error messages:

   systemctl status myapp

6. Manage the service lifecycle:

   Use these commands to control the service as needed:

   • sudo systemctl stop myapp – Stop the service
   • sudo systemctl restart myapp – Restart the service
   • sudo systemctl disable myapp – Disable automatic startup on boot

This section outlines useful commands and practices for diagnosing and resolving issues with systemd services on Ubuntu:

1. Check for failed services:

   List all units that have failed to start or are in an error state:

   systemctl --failed

2. Examine detailed logs for errors and warnings:

   Use the journal to view recent logs, including detailed error explanations:

   journalctl -xe

3. Reload systemd manager configuration:

   After modifying unit files, reload systemd to apply the changes:

   sudo systemctl daemon-reload

4. Mask a service:

   Prevent a service from starting manually or automatically by masking it:

   sudo systemctl mask <service-name>

   To reverse masking, use:

   sudo systemctl unmask <service-name>

5. Restart a problematic service:

   Sometimes restarting the service resolves transient issues:

   sudo systemctl restart <service-name>

6. Check service status:

   View the active state and recent log entries for a specific service:

   systemctl status <service-name>

7. Verify the unit file syntax:

   Check the syntax of a unit file for errors without starting it:

   systemd-analyze verify /etc/systemd/system/<service-name>.service