Échec du démarrage

Installation
1

Ceci est sur une machine de test. J’exécutais auparavant discourse dessus - j’ai raté l’installation et je n’ai pas pu mettre à jour vers la dernière version, ce que je pensais être mon erreur. Après avoir supprimé tout le répertoire discourse et nettoyé docker, j’ai essayé de faire une installation complètement nouvelle avant d’importer une sauvegarde de la base de données en direct.

Étrangement, je rencontre toujours les mêmes problèmes que je ne parviens pas à résoudre.

Voici la sortie de l’échec. J’ai déjà essayé discourse-doctor mais cela n’a rien donné d’utile.

...
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 ====================

Le serveur lui-même devrait être correct - beaucoup d’espace disque, suffisamment de ressources sinon. Des idées ?

2

Nous devons voir davantage du journal, je pense, et en particulier voir ce qui s’est passé avec cette commande rake.

Veuillez fournir les sorties de

free
df

Il pourrait également être pertinent que votre journal inclue
WARNING overcommit_memory is set to 0!

1 « J'aime »
3

C’est le cas :

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.

Voici le reste que vous avez demandé :

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

Je suppose que les messages de « overcommit » sont dus au fait que le swap est à 0 ? Étrangement, cela n’a jamais changé depuis que ce serveur existe…

4

Hmm… 16G de RAM, c’est beaucoup, vous pourriez donc penser que vous n’avez pas besoin de swap. Mais je dirais que cela ne ferait pas de mal d’en ajouter. Sans voir votre journal, je ne peux pas dire que le problème soit un manque de mémoire. Mais si c’est le cas, régler le mode overcommit pourrait aider, que vous ayez du swap ou non.

6

Vous pourriez aussi essayer
dmesg | egrep -i "oom|memory"
pour voir si des processus ont été tués en raison d’un manque de mémoire.

Mais encore une fois, voir plus de votre journal est susceptible d’aider.

Modifier : oups, j’ai ajouté le -i

1 « J'aime »
7

J’ai créé un swap et j’ai également défini le mode de surallocation. Malheureusement, rien n’a changé.

Voici tout le journal de la construction de l’application https://pastebin.com/raw/R2B8Wneu

Je vois des échecs de redis indiquant que le port est utilisé, mais je ne vois pas d’où cela vient.

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)
8

Merci pour le journal - il semble s’agir d’un problème de configuration S3 (ce avec quoi je ne peux pas vous aider, mais je suis sûr que quelqu’un le pourra).

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’

9

Bonne trouvaille, Ed. Merci. Il semble que s3_bucket ait été remplacé à un moment donné par s3_upload_bucket et j’ai ces éléments dans containers/app.yml, ce qui semble avoir causé le problème. Au moins, la construction s’est bien déroulée maintenant après que j’ai changé DISCOURSE_S3_BUCKET en DISCOURSE_S3_UPLOAD_BUCKET.

J’aimerais que de tels changements introduisent également une vérification dans le processus de construction pour éviter de rencontrer ce problème - et bonne chance, nous testons toujours nos mises à jour sur une machine de test.

1 « J'aime »
10

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