PostgreSQL bleibt beim Neuaufbau hängen

Installation
24

Habe das gleiche Problem… DO Droplet auf Ubuntu 20.04. Habe versucht, Docker zuerst innerhalb von Discourse zu aktualisieren, aber es gab immer einen Fehlercode 137. Dann habe ich versucht, Discourse über die Kommandozeile neu zu erstellen, aber es hing bei The database is ready to accept connections. Strg+C tat nichts, also schloss ich SSH und öffnete ein neues, startete Discourse erneut und es funktionierte immer noch, aber nicht aktualisiert. Habe das Droplet neu gestartet und versucht, Docker erneut von Discourse aus zu aktualisieren, und diesmal hat es funktioniert! Dann habe ich versucht, Discourse erneut neu zu erstellen, aber es hing immer noch an der gleichen Stelle. Habe SSH wieder geschlossen und geöffnet und Discourse erneut gestartet, aber jetzt bekomme ich den Oops-Bildschirm! Jetzt ist meine Discourse-Seite ausgefallen und die einzige Möglichkeit, die ich bisher vom Oops-Bildschirm wiederherstellen konnte, war das Neuerstellen der App, was ich nicht tun kann!

Jetzt bin ich ratlos, da meine Erfahrung mit Discourse und Droplet sehr begrenzt ist und ich nicht weiß, was ich jetzt tun kann. docker_manager ist das einzige Plugin, das in meiner app.yml verwendet wird, daher kann ich nur annehmen, dass der Fehler auf eine neuere Version von Docker zurückzuführen ist, die nicht mit meiner Discourse-Version harmoniert? Ich weiß es nicht. Ich habe Discourse zuletzt im Januar aktualisiert, also ist es nicht so veraltet…

Meine Seite ist also ausgefallen, bis dieses Problem gelöst ist… Es sei denn, ich starte ein neues Droplet, richte alles neu ein und stelle das von mir erstellte Discourse-Backup wieder her? Ist das meine einzige Option zu diesem Zeitpunkt? :müde_Gesicht:

25

Fehler 137 bedeutet, dass der Arbeitsspeicher voll ist. Ich würde versuchen, mehr Swap hinzuzufügen. Wenn Sie nur 1 GB RAM haben, würde ich ihn auf 2 GB vergrößern und vielleicht auch 3 oder 4 GB Swap haben.

Sie könnten versuchen:

./launcher start app

Aber ich vermute, dass die Datenbank zu weit für den alten Container migriert ist.

Wenn Sie nicht weiterkommen und bezahlten Support wünschen, sehen Sie unter Contact Us - Literate Computing nach.

Bearbeiten: Aber hier ist, was ich tun würde:

26

Hallo, hier das gleiche Problem. Als Workaround erzwinge ich vorerst den Versionsparameter in app.yml auf v3.3.0. Arch AMD64, Ubuntu 18.04. Seltsam, dass eine Nebenversion fehlgeschlagen ist, das Update auf v3.3.0 letzte Woche ohne Probleme durchlief :neutral_face:

1 „Gefällt mir“
27

Für alle, die auf dieses Problem stoßen und mir Zugriff auf ihren Server gewähren möchten, senden Sie mir bitte eine private Nachricht, damit ich das Problem auf einem Server mit dem Problem debuggen kann. Ich habe mehrere Wege versucht und kann dieses Problem nicht reproduzieren, was es schwieriger macht, eine Lösung zu finden.

5 „Gefällt mir“
28

Ich sehe in meinem Profil keine Möglichkeit, Ihnen eine PN zu senden…

29

Sie müssen Trust Level 1 haben, um Nachrichten senden zu können

Wenn man sich die Statistiken in Ihrem Profil ansieht, sind Sie schon ziemlich nah dran

2 „Gefällt mir“
30

Für alle, die mit diesem Problem feststecken, dass Discourse ausgefallen ist, habe ich festgestellt, dass Sie zumindest die alte Version des Forums wieder zum Laufen bringen können, indem Sie die VM neu starten und dann ./launcher start app ausführen. Dieser Befehl funktioniert nicht, nachdem Sie versucht haben, ein Rebuild durchzuführen, ohne Ihre Instanz / VM neu zu starten.

Ich sollte in der Lage sein, die Ubuntu-Version auf unserer betroffenen VM am Montag zu aktualisieren, und werde alle über das Ergebnis auf dem Laufenden halten.

1 „Gefällt mir“
31

Strg+c funktioniert nicht, wenn es blockiert ist, das System muss neu gestartet werden.

32

Dieser Befehl tut auch nichts.\n\n\n**/var/discourse**# ./launcher start app\n\nx86_64 arch erkannt.\n\nWARNUNG: containers/app.yml Datei ist für alle lesbar. Sie können diese Datei sichern, indem Sie ausführen: chmod o-rwx containers/app.yml\n\n+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=techoforum.com -e DISCOURSE_DEVELOPER_EMAILS=techoforumd@gmail.com -e DISCOURSE_SMTP_ADDRESS=smtp.sendgrid.net -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=apikey -e DISCOURSE_SMTP_PASSWORD=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 -e DISCOURSE_SMTP_DOMAIN=gmail.com -e DISCOURSE_NOTIFICATION_EMAIL=techoforumd@gmail.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h discourseonubuntu2004-s-1vcpu-1gb-sfo3-01-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f8:99:7d:c3:d6 local_discourse/app /sbin/boot\n\nImage 'local_discourse/app' nicht gefunden\n\ndocker: Fehlerantwort vom Daemon: Pull-Zugriff verweigert für local_discourse/app, Repository existiert nicht oder erfordert 'docker login': Zugriffsverweigerung für die angeforderte Ressource.\n\nSiehe 'docker run --help'.\n

33

Ich habe ein anderes Forum auf einem anderen Droplet, und das gibt keine Probleme beim Aktualisieren. Es ist seltsam, warum bei gleicher Serverkonfiguration ein Droplet Probleme hat, während ein anderes keine hat?

34

Das klingt nach einem RAM-Problem. Wie viel RAM und Swap hast du? Ich würde ein oder zwei GB SWAP-Speicher hinzufügen (und vielleicht RAM hinzufügen, wenn du nur 1 GB hast).

Wie viel RAM und Swap hast du auf diesen Systemen? Was ist die Ausgabe von

free -h

Und RAM würde erklären, warum @tgxworld es nicht reproduzieren konnte.

Ich bin ziemlich sicher, dass RAM/Swap das Problem ist.

35

Übrigens, für alle, die auf dieses Problem stoßen: Sie können es vorerst umgehen, indem Sie base_image: discourse/base:2.0.20240708-0023 am Anfang der Datei containers/app.yml hinzufügen.

5 „Gefällt mir“
36

Ich bin mir nicht sicher, ob es sich in meinem Fall um ein RAM-Problem handelt, da der betroffene VM 125 GiB zugewiesen und 78 GB verfügbar sind.

              total        used        free      shared  buff/cache   available
Mem:           125G         14G        940M         31G        110G         78G
Swap:            0B          0B          0B

Der Dev-Server mit demselben Betriebssystem, der ohne dieses Problem erfolgreich aktualisiert wurde, hat nur 16 GiB RAM.

1 „Gefällt mir“
37

Verdammt. Das hätte alles erklärt. :person_shrugging:

1 „Gefällt mir“
38

Könnte es ein Problem mit der Datenbankgröße sein?

Die Datenbank auf unserem Produktionsserver ist ziemlich groß, aber die Entwicklungsumgebung ist sehr klein. Das ist der einzige wirkliche Unterschied zwischen den VMs, die erfolgreich aktualisiert wurden, und der betroffenen (in meinem Fall).

39

Vielleicht haben Sie die Speicher-Konfiguration für die Datenbank geändert?

Wie groß ist die Datenbank?

1 „Gefällt mir“
40

Ich werde es überprüfen und sehen, ob es geändert wurde

41

Das ist das Einzige, was für mich funktioniert hat. Danke, dass Sie das geteilt haben!! Meine Kunden danken Ihnen auch :slight_smile:

Ich hoffe, wir bekommen bald eine richtige Lösung dafür.

1 „Gefällt mir“
42

Hallo,
Ich habe gerade Droplet vergrößert, indem ich den RAM verdoppelt und die Festplattengröße erhöht habe. Ich habe immer noch das gleiche Problem.
Gibt es noch etwas anderes, das ich versuchen kann?

# free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       289Mi        83Mi        11Mi       1.6Gi       1.5Gi
Swap:         2.0Gi       3.0Mi       2.0Gi

# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            941M     0  941M   0% /dev
tmpfs           198M  1.1M  197M   1% /run
/dev/vda1        34G   14G   21G  39% /
tmpfs           986M     0  986M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           986M     0  986M   0% /sys/fs/cgroup
/dev/vda15      105M  7.4M   97M   8% /boot/efi
/dev/loop1       56M   56M     0 100% /snap/core18/2829
/dev/loop2       56M   56M     0 100% /snap/core18/2823
/dev/loop3       92M   92M     0 100% /snap/lxd/29619
/dev/loop0       64M   64M     0 100% /snap/core20/2264
/dev/loop4       64M   64M     0 100% /snap/core20/2318
/dev/loop5       39M   39M     0 100% /snap/snapd/21465
/dev/loop6       92M   92M     0 100% /snap/lxd/24061
/dev/loop7       39M   39M     0 100% /snap/snapd/21759
tmpfs           198M     0  198M   0% /run/user/0
overlay          34G   14G   21G  39% /var/lib/docker/overlay2/3c7ebf42647de2b5df34cba2b047079fd3454ea7fe9b04c7b70f227df1e7eafe/merged
1 „Gefällt mir“
43

OMG! Warum habe ich diese Lösung nicht vorher gelesen. Sie hat auch für mich funktioniert.
Was ist also die Lösung für die Zukunft? Müssen wir dieses Basis-Image auch in Zukunft angeben oder es ändern, um ein aktualisiertes Image zu erhalten?