Remove old systemd service checks

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.
development
Slavi Pantaleev 2 years ago
parent 360e643f84
commit eec5de7aba

@ -30,40 +30,19 @@
delegate_to: 127.0.0.1
become: false
- when: "ansible_distribution != 'Archlinux'"
block:
- name: Populate service facts
ansible.builtin.service_facts:
- name: Fail if service isn't detected to be running
ansible.builtin.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.
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.
See `roles/custom/matrix-common-after/defaults/main.yml` for more details about that.
with_items: "{{ matrix_systemd_services_list | map(attribute='name') }}"
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
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'"
- block:
- name: Populate service facts
ansible.builtin.service_facts:
- name: Fail if service isn't detected to be running
ansible.builtin.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.
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.
See `roles/custom/matrix-common-after/defaults/main.yml` for more details about that.
with_items: "{{ matrix_systemd_services_list | map(attribute='name') }}"
when:
- "item.endswith('.service') and (ansible_facts.services[item] | default(none) is none or ansible_facts.services[item].state != 'running')"

Loading…
Cancel
Save