410a915a8a
This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`, similar to how it's done in: - https://github.com/spantaleev/gitea-docker-ansible-deploy - https://github.com/spantaleev/nextcloud-docker-ansible-deploy In the near future, we'll be removing a lot of the shared role code from here and using upstream roles for it. Some of the core `matrix-*` roles have already been extracted out into other reusable roles: - https://github.com/devture/com.devture.ansible.role.postgres - https://github.com/devture/com.devture.ansible.role.systemd_docker_base - https://github.com/devture/com.devture.ansible.role.timesync - https://github.com/devture/com.devture.ansible.role.vars_preserver - https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages - https://github.com/devture/com.devture.ansible.role.playbook_help We just need to migrate to those.
18 lines
1.2 KiB
YAML
18 lines
1.2 KiB
YAML
---
|
|
# Specifies how long to wait between starting systemd services and checking if they're started.
|
|
#
|
|
# A too low value may lead to a failure, as services may not have enough time to start and potentially fail.
|
|
#
|
|
# A value higher than 30 seconds (or any multiple of that) may also not work well, because a failing systemd service
|
|
# auto-restarts after 30 seconds (`RestartSec=30` in systemd service files).
|
|
# Checking if a service is running right after it had potentially restarted in such a way will lead us to
|
|
# thinking it's running, while it's merely starting again (and likely to fail again, given that it already did once).
|
|
#
|
|
# All of the services we manage are also started sequentially, which in itself can take a long time.
|
|
# There may be a ~10 second (or even larger) interval between starting the first service and starting the last one.
|
|
# This makes it even harder to pick a correct value. Such a 10 second gap and a waiting time of 20 seconds will
|
|
# put us right at the "dangerous" 30-second mark.
|
|
#
|
|
# We can try to measure this gap and adjust our waiting time accordingly, but we currently don't.
|
|
matrix_common_after_systemd_service_start_wait_for_timeout_seconds: 15
|