src.nth.io/

summaryrefslogtreecommitdiff
path: root/pleroma
diff options
context:
space:
mode:
Diffstat (limited to 'pleroma')
-rw-r--r--pleroma/otp/tasks/instance.yaml21
-rw-r--r--pleroma/otp/templates/config.exs.j28
2 files changed, 24 insertions, 5 deletions
diff --git a/pleroma/otp/tasks/instance.yaml b/pleroma/otp/tasks/instance.yaml
index a7bfdd4..fa7ca8a 100644
--- a/pleroma/otp/tasks/instance.yaml
+++ b/pleroma/otp/tasks/instance.yaml
@@ -63,10 +63,16 @@
mode: "0644"
when: pleroma_fe_theme is defined
-- name: ensure pleroma instance is enabled and started
- become: yes
- systemd: name="pleroma@{{pleroma_instance}}.service" enabled="yes" state="started"
-
+# Always, not just on a fresh install: /opt/pleroma's release binary is
+# shared across every pleroma instance on a host, but each instance has its
+# own database. installed_version (install.yaml) only reflects whether THIS
+# run installed a new shared release, not whether THIS instance's db has
+# been migrated against it, so gating migrate on that skipped it for every
+# instance but whichever one's play happened to run first after an upgrade,
+# leaving the others crash-looping on "Unapplied Migrations detected".
+# pleroma_ctl migrate is a no-op when nothing's pending, so there's no
+# reason to skip it. Runs before starting the service so an upgrade doesn't
+# briefly crash-loop before migrating.
- name: check if pleroma binary is present
stat:
path: "/opt/pleroma/bin/pleroma_ctl"
@@ -79,4 +85,9 @@
chdir: "/opt/pleroma/"
environment:
PLEROMA_CONFIG_PATH: "/etc/pleroma/{{pleroma_instance}}.config.exs"
- when: pleroma_binary.stat.exists and not installed_version.stat.exists
+ when: pleroma_binary.stat.exists
+ changed_when: false
+
+- name: ensure pleroma instance is enabled and started
+ become: yes
+ systemd: name="pleroma@{{pleroma_instance}}.service" enabled="yes" state="started"
diff --git a/pleroma/otp/templates/config.exs.j2 b/pleroma/otp/templates/config.exs.j2
index 6f09ec8..f726b2a 100644
--- a/pleroma/otp/templates/config.exs.j2
+++ b/pleroma/otp/templates/config.exs.j2
@@ -71,3 +71,11 @@ config :logger,
config :logger, :ex_syslogger,
level: :critical
+
+# The above only sets the ex_syslogger backend's level. Logger's separate
+# default console handler (stdout, captured by journald) has no level set
+# and prints everything: info-level telemetry attach notices, every SQL
+# debug query, etc. This caps it at warnings and errors without losing the
+# crash/error output journalctl is actually useful for.
+config :logger,
+ level: :warning

☐