Fehlgeschlagener Bootstrap

Dies ist auf einer Testmaschine. Ich habe dort zuvor Discourse ausgeführt – ich habe die Installation vermasselt und konnte nicht auf die neueste Version aktualisieren, was ich für meinen Fehler hielt. Nachdem ich das gesamte Discourse-Verzeichnis entfernt und Docker bereinigt hatte, versuchte ich eine komplett neue Installation, bevor ich ein Backup aus der Live-Datenbank importierte.

Seltsamerweise sehe ich immer noch die gleichen Probleme, die ich nicht lösen kann.

Hier ist die Fehlerausgabe. Habe discourse-doctor bereits ausprobiert, aber nichts Hilfreiches gefunden.

...
I, [2022-06-04T18:42:29.087446 #1]  INFO -- : Terminating async processes
I, [2022-06-04T18:42:29.087672 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 42
I, [2022-06-04T18:42:29.087881 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 103
2022-06-04 18:42:29.088 UTC [42] LOG:  received fast shutdown request
103:signal-handler (1654368149) Received SIGTERM scheduling shutdown...
2022-06-04 18:42:29.118 UTC [42] LOG:  aborting any active transactions
2022-06-04 18:42:29.123 UTC [42] LOG:  background worker "logical replication launcher" (PID 51) exited with exit code 1
2022-06-04 18:42:29.123 UTC [46] LOG:  shutting down
103:M 04 Jun 2022 18:42:29.154 # User requested shutdown...
103:M 04 Jun 2022 18:42:29.154 * Saving the final RDB snapshot before exiting.
103:M 04 Jun 2022 18:42:29.159 * DB saved on disk
103:M 04 Jun 2022 18:42:29.159 # Redis is now ready to exit, bye bye...
2022-06-04 18:42:29.201 UTC [42] LOG:  database system is shut down


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & bundle exec rake db:migrate' failed with return #<Process::Status: pid 1102 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
69cb25658efb6f16e4479bb98a2d0278d72e56028865730841ac1efacc5b8d9d
==================== END REBUILD LOG ====================

Der Server selbst sollte in Ordnung sein – viel Speicherplatz, ansonsten genügend Ressourcen. Irgendwelche Ideen?

Wir müssen mehr vom Log sehen, denke ich, und insbesondere sehen, was mit dem Rake-Befehl passiert ist.

Bitte geben Sie die Ausgaben von

free
df

an.

Es könnte auch relevant sein, wenn Ihr Log Folgendes enthält:
WARNING overcommit_memory is set to 0!

1 „Gefällt mir“

Das tut es:

103:M 04 Jun 2022 18:40:07.369 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

Hier ist der Rest, den Sie angefordert haben:

root@testserver-2021:/var/discourse# free
              total        used        free      shared  buff/cache   available
Mem:       16005396      353200    13366988        1100     2285208    15316292
Swap:             0           0           0
root@testserver-2021:/var/discourse# free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi       343Mi        12Gi       1.0Mi       2.2Gi        14Gi
Swap:            0B          0B          0B
root@testserver-2021:/var/discourse# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.7G     0  7.7G   0% /dev
tmpfs           1.6G  1.1M  1.6G   1% /run
/dev/sda1       226G   44G  173G  21% /
tmpfs           7.7G     0  7.7G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.7G     0  7.7G   0% /sys/fs/cgroup
/dev/sda15       61M  5.2M   55M   9% /boot/efi
overlay         226G   44G  173G  21% /var/lib/docker/overlay2/c9457cf1821fb558a92c79e55bd6a70153b8ae0388732aa5eef17237b6924c25/merged
overlay         226G   44G  173G  21% /var/lib/docker/overlay2/6d350b54871378d4b0e7ac5d30e236df3bdd1c45cd3b5fb2e9ab67ffe7a1bba1/merged
tmpfs           1.6G     0  1.6G   0% /run/user/0
overlay         226G   44G  173G  21% /var/lib/docker/overlay2/104be98cc5c33e73e4119d2186b6d9d08123ffc79df872f48425e94a66ca6749/merged

Ich vermute, die Overcommit-Meldungen sind darauf zurückzuführen, dass Swap 0 ist? Seltsamerweise hat sich das nie geändert, seit dieser Server existiert…

Hmm… 16 GB RAM sind ziemlich viel, daher denkst du vielleicht, dass du keinen Swap benötigst. Aber ich würde sagen, es schadet nicht, etwas hinzuzufügen. Ohne deine Protokolle zu sehen, kann ich nicht sagen, dass das Problem Speichermangel ist. Aber wenn es so ist, könnte das Einstellen des Overcommit-Modus helfen, unabhängig davon, ob du Swap hast oder nicht.

Sie könnten auch versuchen:
dmesg | egrep -i "oom|memory"
um zu sehen, ob Prozesse wegen Speichermangels beendet wurden.

Aber wie gesagt, mehr von Ihrem Log zu sehen, wird wahrscheinlich helfen.

Bearbeiten: Ups, ich habe das -i hinzugefügt

1 „Gefällt mir“

Ich habe einen Swap erstellt und auch den Overcommit-Modus eingestellt. Leider hat sich nichts geändert.

Hier ist das gesamte Protokoll vom Erstellen der App: https://pastebin.com/raw/R2B8Wneu

Ich sehe einige Redis-Fehler, die besagen, dass der Port belegt ist, aber ich kann nicht sehen, woher das kommt.

root@testserver-2021:~# sudo lsof -i -P -n | grep LISTEN
systemd       1            root   89u  IPv6  15961      0t0  TCP *:9090 (LISTEN)
systemd-r   573 systemd-resolve   13u  IPv4  10890      0t0  TCP 127.0.0.53:53 (LISTEN)
sshd        676            root    3u  IPv4  20387      0t0  TCP *:22 (LISTEN)
sshd        676            root    4u  IPv6  20389      0t0  TCP *:22 (LISTEN)
docker-pr   913            root    4u  IPv4  23665      0t0  TCP *:9100 (LISTEN)
docker-pr   921            root    4u  IPv6  21827      0t0  TCP *:9100 (LISTEN)
docker-pr   981            root    4u  IPv4  24732      0t0  TCP *:3003 (LISTEN)
docker-pr   989            root    4u  IPv6  22636      0t0  TCP *:3003 (LISTEN)
monitorix  1284       monitorix    3u  IPv4  27978      0t0  TCP *:8080 (LISTEN)

Danke für das Log – es sieht nach einem Problem mit der S3-Einrichtung aus (wobei ich nicht helfen kann, aber ich bin sicher, jemand kann es).

I, [2022-06-05T09:06:10.144445 #1] INFO – : > cd /var/www/discourse & su discourse -c ‘bundle exec rake db:migrate’
rake aborted!
Discourse::SiteSettingMissing: s3_upload_bucket
/var/www/discourse/lib/file_store/s3_store.rb:267:in `s3_bucket’

Guter Fund, Ed. Danke. Es sieht so aus, als ob s3_bucket irgendwann zu s3_upload_bucket geändert wurde und ich habe diese in containers/app.yml, was das Problem verursacht zu haben scheint. Zumindest lief das Bauen jetzt gut, nachdem ich DISCOURSE_S3_BUCKET dort in DISCOURSE_S3_UPLOAD_BUCKET geändert habe.

Ich wünschte, solche Änderungen würden auch eine Prüfung im Build-Prozess einführen, um dies zu vermeiden – und viel Glück, wir testen unsere Updates immer auf einer Testmaschine.

1 „Gefällt mir“

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.