e1690722f7
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/756 Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/737 I feel like timers are somewhat more complicated and dirty (compared to cronjobs), but they come with these benefits: - log output goes to journald - on newer systemd distros, you can see when the timer fired, when it will fire, etc. - we don't need to rely on cron (reducing our dependencies to just systemd + Docker) Cronjobs work well, but it's one more dependency that needs to be installed. We were even asking people to install it manually (in `docs/prerequisites.md`), which could have gone unnoticed. Once in a while someone says "my SSL certificates didn't renew" and it's likely because they forgot to install a cron daemon. Switching to systemd timers means that installation is simpler and more unified.
71 lines
2.7 KiB
YAML
71 lines
2.7 KiB
YAML
---
|
|
|
|
- name: Determine whether we should make services autostart
|
|
set_fact:
|
|
matrix_services_autostart_enabled_bool: "{{ true if matrix_services_autostart_enabled|default('') == '' else matrix_services_autostart_enabled|bool }}"
|
|
|
|
- name: Ensure systemd is reloaded
|
|
service:
|
|
daemon_reload: yes
|
|
|
|
- name: Ensure Matrix services are stopped
|
|
service:
|
|
name: "{{ item }}"
|
|
state: stopped
|
|
with_items: "{{ matrix_systemd_services_list }}"
|
|
when: not ansible_check_mode
|
|
|
|
- name: Ensure Matrix services are started
|
|
service:
|
|
name: "{{ item }}"
|
|
enabled: "{{ matrix_services_autostart_enabled_bool }}"
|
|
state: started
|
|
with_items: "{{ matrix_systemd_services_list }}"
|
|
when: not ansible_check_mode
|
|
|
|
# If we check service state immediately, we may succeed,
|
|
# because it takes some time for the service to attempt to start and actually fail.
|
|
#
|
|
# Waiting too long (30s) may not work for a similar reason,
|
|
# as we may run into systemd's automatic restart logic retrying the service.
|
|
- name: Wait a bit, so that services can start (or fail)
|
|
wait_for:
|
|
timeout: 5
|
|
delegate_to: 127.0.0.1
|
|
become: false
|
|
|
|
- block:
|
|
- name: Populate service facts
|
|
service_facts:
|
|
|
|
- name: Fail if service isn't detected to be running
|
|
fail:
|
|
msg: >-
|
|
{{ item }} was not detected to be running.
|
|
It's possible that there's a configuration problem or another service on your server interferes with it (uses the same ports, etc.).
|
|
Try running `systemctl status {{ item }}` and `journalctl -fu {{ item }}` on the server to investigate.
|
|
with_items: "{{ matrix_systemd_services_list }}"
|
|
when:
|
|
- "item.endswith('.service') and (ansible_facts.services[item]|default(none) is none or ansible_facts.services[item].state != 'running')"
|
|
when: " ansible_distribution != 'Archlinux'"
|
|
|
|
- block:
|
|
# Currently there is a bug in ansible that renders is incompatible with systemd.
|
|
# service_facts is not collecting the data successfully.
|
|
# Therefore iterating here manually
|
|
- name: Fetch systemd information
|
|
systemd:
|
|
name: "{{ item }}"
|
|
register: systemdstatus
|
|
with_items: "{{ matrix_systemd_services_list }}"
|
|
|
|
- name: Fail if service isn't detected to be running
|
|
fail:
|
|
msg: >-
|
|
{{ item.item }} was not detected to be running.
|
|
It's possible that there's a configuration problem or another service on your server interferes with it (uses the same ports, etc.).
|
|
Try running `systemctl status {{ item.item }}` and `journalctl -fu {{ item.item }}` on the server to investigate.
|
|
with_items: "{{ systemdstatus.results }}"
|
|
when: "item.status['ActiveState'] != 'active'"
|
|
when: "ansible_distribution == 'Archlinux'"
|