Service

Manage services. There are three modules that manage services

• ansible.builtin.service

• ansible.builtin.systemd

• ansible.builtin.sysvinit

Synopsis

There are four standalone blocks that can be selected by tags:

• Debug. Display variables.

• Sanity check

• Manage automatically services listed in lp_service_auto

• Manage services listed in lp_service

The module service is used in automatic management of services listed in lp_service_auto. The OS specific service management module discovered by ansible.builtin.setup is used to manage services listed in lp_service. The last task after the blocks will flush handlers.

See also

• service.yml

• service-service.yml

• service-systemd.yml

• service-sysvinit.yml

Quick guide

• Create list lp_service_auto

  lp_service_auto: [smart, udev]
  

  and select the automatic management of services:

  shell> ansible-playbook lp.yml -t lp_service_auto
  

• Create list lp_service:

  lp_service:
    - enabled: true
      name: smartmontools
      state: started
      use: auto
    - enabled: true
      name: udev
      state: started
      use: service
  

  and select the manual management of services:

  shell> ansible-playbook lp.yml -t lp_service_manual
  

Best practice

Create a playbook and configure variables

shell> cat lp.yml
- hosts: test_01
  become: true
  roles:
    - vbotka.linux_postinstall

Check the syntax of the playbook

shell> ansible-playbook lp.yml --syntax-check

Display variables

shell> ansible-playbook lp.yml -t lp_service_debug -e lp_service_debug=true
shell> ansible-playbook lp.yml -t lp_debug -e lp_debug=true

Check sanity of variables

shell> ansible-playbook lp.yml -t lp_service_sanity -e lp_service_sanity=true -e lp_service_sanity_quiet=false

Don’t make any changes, predict and show differences. Limit the execution to the automatic and manual management of services

shell> ansible-playbook lp.yml -t lp_service_auto --check --diff
shell> ansible-playbook lp.yml -t lp_service_manual --check --diff

If all seems right manage services and display results

shell> ansible-playbook lp.yml -t lp_service_manual -e lp_service_debug=true

Automatically manage services and display results

shell> ansible-playbook lp.yml -t lp_service_auto -e lp_service_debug=true

To minimize both the execution and output, disable skipped hosts

shell> ANSIBLE_DISPLAY_SKIPPED_HOSTS=false ansible-playbook lp.yml -t lp_service_auto
  ...
TASK [vbotka.linux_postinstall : service: Automatic management of listed services] **************
ok: [test_01] => (item=unattended-upgrades enabled=False state=stopped use=auto)
ok: [test_01] => (item=autofs enabled=False state=stopped use=auto)
ok: [test_01] => (item=bluetooth enabled=True state=started use=auto)
ok: [test_01] => (item=postfix enabled=True state=started use=auto)
ok: [test_01] => (item=resolvconf enabled=True state=started use=auto)
ok: [test_01] => (item=smartmontools enabled=True state=started use=auto)
ok: [test_01] => (item=speech-dispatcher enabled=False state=stopped use=auto)
ok: [test_01] => (item=ssh enabled=True state=started use=auto)
ok: [test_01] => (item=systemd-timesyncd.service enabled=False state=stopped use=auto)
ok: [test_01] => (item=udev enabled=True state=started use=service)
ok: [test_01] => (item=ufw enabled=True state=started use=auto)

See also

• source code service.yml to learn details.

• defaults/main/service.yml

• examples below.

Note

• The module service is a proxy for OS specific service management modules. See the parameter use of the module.

• The module service by default uses the service manager discovered by ansible.builtin.setup stored in the variable ansible_service_mgr.

Hint

Use yaml callback

Debug

By default, the debug is turned off lp_service_debug=false. If enabled the debug task will display the variables. For example,

shell> ansible-playbook lp.yml -t lp_service_debug -e lp_service_debug=True

  ...

TASK [vbotka.linux_postinstall : service: Debug] ***********************************************
ok: [test_01] => 
  msg: |-
    ansible_os_family: Debian
    ansible_service_mgr: systemd
    lp_service_sanity: False
  
    lp_service_module: auto
    lp_service_module_valid: ['auto', 'service', 'systemd', 'sysvinit']
    lp_service:
      - enabled: true
        name: smartmontools
        state: started
        use: auto
      - enabled: true
        name: udev
        state: started
        use: service
  
    lp_service_auto:
      - smart
      - udev

Note

To demonstrate the functionality, both lp_service and lp_service_auto list the same services. To manage a service you will usually use either lp_service or lp_service_auto. The tasks won’t complain if you use both.

Sanity

By default, the sanity checking is turned off lp_service_sanity=false. If enabled the module ansible.builtin.service_facts will get the service facts and following tasks will check the validity of:

• the service names in lp_service

• the service names in lp_service_auto

• the value of lp_service_module

shell> ansible-playbook lp.yml -t lp_service_sanity -e lp_service_sanity=True -e lp_service_sanity_quiet=False

  ...

TASK [vbotka.linux_postinstall : service: Get service facts] *************************************************************************
ok: [test_01]

TASK [vbotka.linux_postinstall : service: Sanity lp_service_auto items are defined] **************************************************
ok: [test_01] => changed=false 
  msg: '[OK]  All service names in lp_service_auto are valid.'

TASK [vbotka.linux_postinstall : service: Sanity lp_service names are defined] *******************************************************
ok: [test_01] => changed=false 
  msg: '[OK]  All service names in lp_service are valid.'

TASK [vbotka.linux_postinstall : service: Sanity lp_service_module] ******************************************************************
ok: [test_01] => changed=false 
  msg: '[OK]  auto is valid value of lp_service_module.'

See also

The declaration of the dynamic variables in defaults/main/service.yml

Manage services automatically

Only limited parameters (state, enabled, use) of the module service are used in the automatic management of the services. The configuration is very simple. Put services you want to manage into the list lp_service_auto. Non-empty list lp_service_auto enables automatic management of services

lp_service_auto:
  - smart
  - udev

See the tasks what services are implemented (acpi, apparmor, auto_upgrades, …, zfs). For each service, there might be five variables of the form

lp_<service_name> ........... included if true (default=false)
lp_<service_name>_service ... OS specific name (default=<service_name>)
lp_<service_name>_enable .... enabled if true (default=false)
lp_<service_name>_state ..... started if true (default=<fn(enabled)>)
lp_<service_name>_module .... module used (default=auto)

where service_name is the name of the task.

• lp_<service_name> is used both to import the tasks in tasks/main.yml and to enable automatic management of the service. If this variable is false neither the tasks will be imported nor the service will be managed automatically. The default value is false (see defaults).

• lp_<service_name>_service is the name of the service. The names of services may vary among the operating systems. The default is <service_name>

• lp_<service_name>_enable is what you think it is. The default is false.

• lp_<service_name>_state is also what you think it is. The default state of the service is derived from the variable lp_<service_name>_enable. If enabled the state is set started otherwise it is set stopped.

• lp_<service_name>_module is a name of Ansible module used in the parameter use of the module service. The default is auto.

For example, given the below variables, the service udev will be set enabled and started by the module service if udev is included in the list lp_service_auto

lp_udev: true
lp_udev_enable: true
lp_udev_module: service

See also

Example 1: Automatic management of services

Manage services

If you want to set other parameters of the services use the list lp_service. Non-empty list lp_service enables manual management of services

lp_service:
  - enabled: true
    name: smartmontools
    state: started
    use: auto
  - enabled: true
    name: udev
    state: started
    use: service

Here you can use the variables lp_<service_name>_* explicitly. The content of the below list will be the same

lp_service:
  - name: "{{ lookup('vars', 'lp_smart_service') }}"
    enabled: "{{ lookup('vars', 'lp_smart_enable', default=false) }}"
    state: "{{ lookup('vars', 'lp_smart_state', default='stopped') }}"
    use: "{{ lookup('vars', 'lp_smart_module', default='auto') }}"
  - name: "{{ lookup('vars', 'lp_udev_service') }}"
    enabled: "{{ lookup('vars', 'lp_udev_enable', default=false) }}"
    state: "{{ lookup('vars', 'lp_udevt_state', default='stopped') }}"
    use: "{{ lookup('vars', 'lp_udev_module', default='auto') }}"

What parameters can be used depends on the module. By default the variable lp_service_module is set to auto. In this case, the OS native service manager ansible_service_mgr is used. Take a look at files tasks/fn/service-*.yml what options are available. The valid options are listed in the variable lp_service_module_valid

lp_service_module_valid: [auto, service, systemd, sysvinit]

Module systemd

Quoting from the notes:

The order of execution when having multiple properties is to first enable/disable, then mask/unmask and then deal with service state. It has been reported that systemctl can behave differently depending on the order of operations if you do the same manually.

The task systemd will be run three times to:

1. enable/disable services

2. mask/unmask services

3. deal with services’ states

See also

• source code service-systemd.yml

• Example 2: Manual management of services

Module sysvinit

TBD

See also

• source code service-sysvinit.yml

Examples

• Example 1: Automatic management of services
• Example 2: Manual management of services