J’ai un problème pour reconstruire un domaine de test (auto-hébergé - fonctionne depuis environ 7 ans avec des mises à jour peu fréquentes mais fonctionnait avec la dernière version jusqu’à cette semaine).
J’ai eu des problèmes avec un plugin non pris en charge que j’ai maintenant supprimé et je pense que cela a peut-être endommagé quelque chose dans la base de données ou la configuration. L’erreur que j’obtiens à la fin est :
2024-04-25 01:07:42.098 UTC [34] LOG: received fast shutdown request
I, [2024-04-25T01:07:42.099067 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 96
96:signal-handler (1714007262) Received SIGTERM scheduling shutdown...
2024-04-25 01:07:42.105 UTC [34] LOG: aborting any active transactions
2024-04-25 01:07:42.121 UTC [34] LOG: background worker \"logical replication launcher\" (PID 49) exited with exit code 1
96:M 25 Apr 2024 01:07:42.121 # User requested shutdown...
96:M 25 Apr 2024 01:07:42.122 * Saving the final RDB snapshot before exiting.
2024-04-25 01:07:42.133 UTC [44] LOG: shutting down
96:M 25 Apr 2024 01:07:42.177 * DB saved on disk
96:M 25 Apr 2024 01:07:42.178 # Redis is now ready to exit, bye bye...
2024-04-25 01:07:42.195 UTC [34] LOG: database system is shut down
Error response from daemon: invalid JSON: got EOF while reading request body
FAILED TO COMMIT cbaab1290466a63d0a77f5f1e0894b0da632204e63472416674b7fab9ae53b41
J’ai scanné le reste du journal et les seules erreurs supplémentaires que je vois sont considérées comme « sans importance » sur d’autres publications ici.
Des suggestions sur la marche à suivre ?
Je pense qu’il ne me reste plus qu’à faire une nouvelle installation, puis à tenter une restauration à partir d’une sauvegarde, mais j’apprécierais tout indice sur ce qui pourrait réellement se passer…
Je le faisais - j’avais oublié que nous avions tripoté l’instance WordPress qui tourne aussi sur cette goutte, donc nous utilisons certainement de l’espace swap. Il faut probablement agrandir ce VPS de toute façon…
Oui.
J’ai fait un grep dans le log et je n’ai pas vu cette erreur.
J’ai eu la brillante idée de redémarrer le VPS avant de réessayer. En supposant que cela échoue, j’agrandirai la goutte et réessayerai.
non - je suppose qu’il y a quelque chose dans l’un des scripts du processus de construction - c’est la même façon dont je l’ai construit pendant des années (ssh dans quelques sessions - une regardant l’autre…) - tous ceux qui ont commencé à échouer ont un sigterm à (je suppose) la même place dans le script qui semble fermer l’application que quelque chose lit…
Non. Je pense que la demande s’est bien déroulée. Peut-être que l’erreur est le « échec de la validation » tout à la fin, mais je n’ai pas d’exclamation pour cela.
Y a-t-il quelque chose dans le script de lancement qui renvoie des informations à GitHub ? Cela expliquerait l’erreur s’il y a une sorte de métrique qu’ils suivent par un commit - si cela se trouve dans un pipeline shell (par exemple, Curl ou autre), cela expliquerait également l’erreur de canal fermé.
Plutôt que d’essayer de déboguer ce qui se passe avec le lanceur, je pense que le plus simple pour moi serait d’essayer de faire une nouvelle installation et une restauration.
Je suis ouvert aux suggestions si vous avez des idées…
Probablement excessif, mais j’ai fini par créer une nouvelle gouttelette, j’ai fait une nouvelle installation, puis j’ai restauré une ancienne sauvegarde à partir de là.
Quelqu’un d’autre a eu une erreur similaire récemment, je pense que c’était dû à une chaîne de clés expirée pour les certificats https. Je soupçonne que c’était votre problème.
L’autre personne a effectué une mise à niveau du système d’exploitation, ce qui a résolu le problème, mais je préfère un nouveau départ.