pub-solar/matrix-docker-ansible-deploy
5
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

Remove old systemd service checks

Browse source 
These are not even caused by Archlinux, but by running buggy Ansible on old Ubuntu
while targeting modern servers (like Archlinux, but also others, ..).

We shouldn't employ ugly workarounds like this. We should tell people to
avoid running buggy Ansible or bad distros like Ubuntu, even.
This commit is contained in:
Slavi Pantaleev 2022-11-23 08:55:34 +02:00
parent 360e643f84
commit eec5de7aba
1 changed files with 15 additions and 36 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

51
roles/custom/matrix-common-after/tasks/start.yml
View file

@ -30,40 +30,19 @@
delegate_to: 127.0.0.1 delegate_to: 127.0.0.1
become: false become: false
- when: "ansible_distribution != 'Archlinux'" - block:
block: - name: Populate service facts
- name: Populate service facts ansible.builtin.service_facts:
ansible.builtin.service_facts:
- name: Fail if service isn't detected to be running - name: Fail if service isn't detected to be running
ansible.builtin.fail: ansible.builtin.fail:
msg: >- msg: >-
{{ item }} was not detected to be running. {{ 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.). 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. Try running `systemctl status {{ item }}` and `journalctl -fu {{ item }}` on the server to investigate.
If you're on a slow or overloaded server, it may be that services take a longer time to start and that this error is a false-positive. If you're on a slow or overloaded server, it may be that services take a longer time to start and that this error is a false-positive.
You can consider raising the value of the `matrix_common_after_systemd_service_start_wait_for_timeout_seconds` variable. You can consider raising the value of the `matrix_common_after_systemd_service_start_wait_for_timeout_seconds` variable.
See `roles/custom/matrix-common-after/defaults/main.yml` for more details about that. See `roles/custom/matrix-common-after/defaults/main.yml` for more details about that.
with_items: "{{ matrix_systemd_services_list | map(attribute='name') }}" with_items: "{{ matrix_systemd_services_list | map(attribute='name') }}"
when: when:
- "item.endswith('.service') and (ansible_facts.services[item] | default(none) is none or ansible_facts.services[item].state != 'running')" - "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
ansible.builtin.systemd:
name: "{{ item.name }}"
register: systemdstatus
with_items: "{{ matrix_systemd_services_list }}"
- name: Fail if service isn't detected to be running
ansible.builtin.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'"