Chapter 27. Managing systemd units by using RHEL system roles


By using the systemd RHEL system role, you can automate certain systemd-related tasks and perform them remotely. You can use the role for the following actions:

  • Manage services
  • Deploy units
  • Deploy drop-in files

27.1. Managing services by using the systemd RHEL system role

You can automate and remotely manage systemd units, such as starting or enabling services, by using the systemd RHEL system role.

Prerequisites

Procedure

  1. Create a playbook file, for example ~/playbook.yml, with the following content. Use only the variables depending on what actions you want to perform.

    ---
    - name: Managing systemd services
      hosts: managed-node-01.example.com
      tasks:
        - name: Perform action on systemd units
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.systemd
          vars:
            systemd_started_units:
              - <systemd_unit_1>.service
            systemd_stopped_units:
              - <systemd_unit_2>.service
            systemd_restarted_units:
              - <systemd_unit_3>.service
            systemd_reloaded_units:
              - <systemd_unit_4>.service
            systemd_enabled_units:
              - <systemd_unit_5>.service
            systemd_disabled_units:
              - <systemd_unit_6>.service
            systemd_masked_units:
              - <systemd_unit_7>.service
            systemd_unmasked_units:
              - <systemd_unit_8>.service
    Copy to Clipboard

    For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.systemd/README.md file on the control node.

  2. Validate the playbook syntax:

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard

    Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

  3. Run the playbook:

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard

27.2. Deploying systemd drop-in files by using the systemd RHEL system role

Systemd applies drop-in files on top of setting it reads for a unit from other locations. Therefore, you can modify unit settings with drop-in files without changing the original unit file. By using the systemd RHEL system role, you can automate the process of deploying drop-in files.

Important

The role uses the hard-coded file name 99-override.conf to store drop-in files in /etc/systemd/system/<name>._<unit_type>/. Note that it overrides existing files with this name in the destination directory.

Prerequisites

Procedure

  1. Create a Jinja2 template with the systemd drop-in file contents. For example, create the ~/sshd.service.conf.j2 file with the following content:

    {{ ansible_managed | comment }}
    [Unit]
    After=
    After=network.target sshd-keygen.target network-online.target
    Copy to Clipboard

    This drop-in file specifies the same units in the After setting as the original /usr/lib/systemd/system/sshd.service file and, additionally, network-online.target. With this extra target, sshd starts after the network interfaces are actived and have IP addresses assigned. This ensures that sshd can bind to all IP addresses.

    Use the <name>.<unit_type>.conf.j2 convention for the file name. For example, to add a drop-in for the sshd.service unit, you must name the file sshd.service.conf.j2. Place the file in the same directory as the playbook.

  2. Create a playbook file, for example ~/playbook.yml, with the following content:

    ---
    - name: Managing systemd services
      hosts: managed-node-01.example.com
      tasks:
        - name: Deploy an sshd.service systemd drop-in file
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.systemd
          vars:
             systemd_dropins:
               - sshd.service.conf.j2
    Copy to Clipboard

    The settings specified in the example playbook include the following:

    systemd_dropins: <list_of_files>
    Specifies the names of the drop-in files to deploy in YAML list format.

    For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.systemd/README.md file on the control node.

  3. Validate the playbook syntax:

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard

    Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

  4. Run the playbook:

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard

Verification

  • Verify that the role placed the drop-in file in the correct location:

    # ansible managed-node-01.example.com -m command -a 'ls /etc/systemd/system/sshd.service.d/'
    99-override.conf
    Copy to Clipboard

27.3. Deploying systemd units by using the systemd RHEL system role

You can create unit files for custom applications, and systemd reads them from the /etc/systemd/system/ directory. By using the systemd RHEL system role, you can automate the deployment of custom unit files.

Prerequisites

Procedure

  1. Create a Jinja2 template with the custom systemd unit file contents. For example, create the ~/example.service.j2 file with the contents for your service:

    {{ ansible_managed | comment }}
    [Unit]
    Description=Example systemd service unit file
    
    [Service]
    ExecStart=/bin/true
    Copy to Clipboard

    Use the <name>.<unit_type>.j2 convention for the file name. For example, to create the example.service unit, you must name the file example.service.j2. Place the file in the same directory as the playbook.

  2. Create a playbook file, for example ~/playbook.yml, with the following content:

    ---
    - name: Managing systemd services
      hosts: managed-node-01.example.com
      tasks:
        - name: Deploy, enable, and start a custom systemd service
          ansible.builtin.include_role:
            name: redhat.rhel_system_roles.systemd
          vars:
             systemd_unit_file_templates:
               - example.service.j2
             systemd_enabled_units:
               - example.service
             systemd_started_units:
               - example.service
    Copy to Clipboard

    For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.systemd/README.md file on the control node.

  3. Validate the playbook syntax:

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard

    Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

  4. Run the playbook:

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard

Verification

  • Verify that the service is enabled and started:

    # ansible managed-node-01.example.com -m command -a 'systemctl status example.service'
    ...
    ● example.service - A service for demonstrating purposes
       Loaded: loaded (/etc/systemd/system/example.service; enabled; vendor preset: disabled)
       Active: active (running) since Thu 2024-07-04 15:59:18 CEST; 10min ago
    ...
    Copy to Clipboard

27.4. Deploying systemd user units by using the systemd RHEL system role

You can create per-user unit files for custom applications, and systemd reads them from the /home/<username>/.config/systemd/user/ directory. By using the systemd RHEL system role, you can automate the deployment of custom unit files for individual users.

Prerequisites

  • You have prepared the control node and the managed nodes.
  • You are logged in to the control node as a user who can run playbooks on the managed nodes.
  • The account you use to connect to the managed nodes has sudo permissions on them.
  • The user you specify in the playbook for the systemd unit exists.

Procedure

  1. Create a Jinja2 template with the custom systemd unit file contents. For example, create the ~/example.service.j2 file with the contents for your service:

    {{ ansible_managed | comment }}
    [Unit]
    Description=Example systemd service unit file
    
    [Service]
    ExecStart=/bin/true
    RemainAfterExit=yes
    
    [Install]
    WantedBy=multi-user.target
    Copy to Clipboard

    Use the <name>.<unit_type>.j2 convention for the file name. For example, to create the example.service unit, you must name the file example.service.j2. Place the file in the same directory as the playbook.

  2. Create a playbook file, for example ~/playbook.yml, with the following content:

    ---
    - name: Managing systemd services
      hosts: managed-node-01.example.com
      tasks:
        - name: Deploy, enable, and start a custom systemd service for a user
          ansible.builtin.include_role:
            name: rhel-system-roles.systemd
          vars:
            systemd_unit_file_templates:
              - item: example.service.j2
                user: <username>
            systemd_enabled_units:
              - item: example.service
                user: <username>
            systemd_started_units:
              - item: example.service
                user: <username>
    Copy to Clipboard
    Important

    The systemd RHEL system role does not create new users, and it returns an error if you specify a non-existent user in the playbook.

    For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.systemd/README.md file on the control node.

  3. Validate the playbook syntax:

    $ ansible-playbook --syntax-check ~/playbook.yml
    Copy to Clipboard

    Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

  4. Run the playbook:

    $ ansible-playbook ~/playbook.yml
    Copy to Clipboard

Verification

  • Verify that the service is enabled and started:

    # ansible managed-node-01.example.com -m command -a 'systemctl --user -M <username>@ status example.service'
    ...
    ● example.service - Example systemd service unit file
         Loaded: loaded (/home/<username>/.config/systemd/user/example.service; enabled; preset: disabled)
         Active: active (exited) since Wed 2025-03-05 13:33:36 CET; 45s ago
    ...
    Copy to Clipboard
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat