106 lines
3.4 KiB
Markdown
106 lines
3.4 KiB
Markdown
# 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
|
|
```
|
|
|
|
## Systemd Timers
|
|
To have custom executables run regulary on given time/interval, you may use the `base::timers` Hiera key:
|
|
|
|
```
|
|
base::timers:
|
|
'timer_test':
|
|
description: 'test timers'
|
|
command: '/usr/bin/logger foo'
|
|
on_calendar: '*:*:10'
|
|
timer_options:
|
|
persistence: false
|
|
```
|
|
|
|
For each timer following keys are mandatory
|
|
|
|
- `description` for a short explaination what it is about
|
|
- `command` for the command to run
|
|
- `on_calendar` defining when it should run using the [`systemd` calendar event format](https://www.freedesktop.org/software/systemd/man/systemd.time.html#Calendar%20Events), (alternatively see also chapter "CALENDAR EVENTS" of `man systemd.date`)
|
|
|
|
Optional is
|
|
- `timer_options` for additional options. In the example it is `persistence`which signals if the timer should run immediately after boot when the node was switched of on the last scheduled run time (default is `false`).
|
|
|
|
## 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.
|
|
|
|
|