.github
docs
examples
group_vars
inventory
roles
matrix-aux
matrix-base
matrix-bot-matrix-reminder-bot
matrix-bridge-appservice-discord
matrix-bridge-appservice-irc
matrix-bridge-appservice-slack
matrix-bridge-appservice-webhooks
matrix-bridge-mautrix-facebook
matrix-bridge-mautrix-hangouts
matrix-bridge-mautrix-signal
matrix-bridge-mautrix-telegram
matrix-bridge-mautrix-whatsapp
matrix-bridge-mx-puppet-discord
matrix-bridge-mx-puppet-instagram
matrix-bridge-mx-puppet-skype
matrix-bridge-mx-puppet-slack
matrix-bridge-mx-puppet-steam
matrix-bridge-mx-puppet-twitter
matrix-bridge-sms
matrix-client-element
matrix-common-after
matrix-corporal
matrix-coturn
matrix-dimension
matrix-dynamic-dns
matrix-email2matrix
matrix-jitsi
matrix-ma1sd
matrix-mailer
matrix-nginx-proxy
matrix-postgres
defaults
tasks
templates
sql
systemd
matrix-postgres.service.j2
usr-local-bin
env-postgres-psql.j2
env-postgres-server.j2
matrix-registration
matrix-synapse
matrix-synapse-admin
.editorconfig
.gitignore
CHANGELOG.md
LICENSE
README.md
ansible.cfg
setup.yml
These are just defensive cleanup tasks that we run. In the good case, there's nothing to kill or remove, so they trigger an error like this: > Error response from daemon: Cannot kill container: something: No such container: something and: > Error: No such container: something People often ask us if this is a problem, so instead of always having to answer with "no, this is to be expected", we'd rather eliminate it now and make logs cleaner. In the event that: - a container is really stuck and needs cleanup using kill/rm - and cleanup fails, and we fail to report it because of error suppression (`2>/dev/null`) .. we'd still get an error when launching ("container name already in use .."), so it shouldn't be too hard to investigate.