Files
gitea-pages/admin-guide/configuration/software/services.md

3.1 KiB

Managing Services with Systemd

Hiera can also be used to manage services and to automate reoccuring tasks with timers.

Enabling/Starting a Service

If the software already comes with an systemd unit file, then it is sufficient to just enable it in Hiera by using the base::services key:

base::services:
    netdata:
        enable: true

The key inside is the systemd service name without the .service suffix.

Disabling/Stopping a Service

To stop and disable an already running service, disable it in the base::services Hiera key with enable: false:

base::services:
    netdata:
        enable: false

Manage a Socket Activated Service

For socket activated services use in Hiera base:sockets instead:

base::sockets:
  cockpit:
    enable: true

Manage Services with Custom Unit Files

It is also possible to provide a full systemd unit file if there is none already. For this define the different secions and their content with subkeys below the options key as in below example:

# The following service stops users from accessing the node
# before the home directory is mounted
base::services:
    'wait_for_home':
        enable: true
        options:
            Unit:
                Before: 'systemd-user-sessions.service'
            Install:
                WantedBy: 'multi-user.target'
                RequiredBy: 'multi-user.target'
            Service:
                Type: 'oneshot'
                ExecStart: '/opt/pli/libexec/waitformount -m /das/home'
                RemainAfterExit: 'true'

If you need to set multiple values, then put the values into an list:

Service:
    Environment:
        - "FOO=bar"
        - "BIZ=buz"

Enhance a Service with a Dropin Unit File

It is possible to fine-tune already existing systemd unit files with dropins. These are placed as .conf files in /etc/systemd/system/$SERVICE.service.d/.

With the dropin: true setting the content of the options parameter is written into the according dropin directory:

base::services:
    'name_of_enhanced_service':
        enable: true
        dropin: true
    options:
        ...

Often this is done to start the service with different options, then you need to reset the orginal value with an emty entry:

base::services:
    'name_of_enhanced_service':
        enable: true
        dropin: true
        options:
            Service:
                ExecStart:
                    - ''
                    - '/usr/sbin/my_service --verbose'

If there are multiple dropins, you might also name them individually with the dropin_name parameter.

Run Command on Startup

If a command should run only once at boot time you may create a oneshot service with RemainAfterExit and have one or more commands ready in ExecStart:

base::services:
  tuned_setup:
    enable: true
    options:
      Unit:
        After: 'tuned.service'
      Install:
        WantedBy: 'multi-user.target'
      Service:
        Type: 'oneshot'
        ExecStart:
          - '/usr/sbin/tuned-adm active'
          - '/usr/sbin/tuned-adm profile virtual-host'
        RemainAfterExit: 'true'