Проблемы с пересборкой приложения

У меня возникла проблема с пересборкой тестового домена (самостоятельный хостинг — работает около 7 лет с редкими обновлениями, но до этой недели использовался последний релиз).

У меня были проблемы с неподдерживаемым плагином, который я теперь удалил, и, возможно, это что-то повредило в базе данных или конфигурации. Ошибка, которую я получаю при завершении:

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

Я просмотрел остальную часть лога, и единственные дополнительные ошибки, которые я вижу, в других сообщениях здесь считаются «не важными».

Есть ли какие-либо предложения, что делать дальше?

Думаю, на данном этапе мне останется выполнить чистую установку, а затем попытаться восстановить из резервной копии, но буду признателен за любые подсказки о том, что на самом деле происходит…

Спасибо!

Без полного лога невозможно сказать.

Мое предположение — у вас закончилась оперативная память. Попробуйте добавить файл подкачки (swap).

Сколько у вас оперативной памяти и swap?

2G. Исходя из предыдущего, казалось, что у меня всё в порядке, но легко добавить ещё и попробовать снова.

Если проблемы сохранятся, я загрузу лог.

До этого доберусь только завтра…

Вам нужно было следить за топ-процессом во время выполнения пересборки.

2 ГБ оперативной памяти и 2 ГБ подкачки? Проверьте лог на наличие ошибки 137 — нехватка памяти.

Я следил — я забыл, что мы возились с экземпляром WordPress, который также работает на этом droplet, так что мы определённо используем какую-то подкачку. Вероятно, в любом случае нужно увеличить этот VPS…

Да.

Я выполнил grep по логу и не нашёл этой ошибки.

У меня появилась блестящая идея перезагрузить VPS перед повторной попыткой. Если это не сработает, я увеличу размер droplet и попробую снова.

По-прежнему не удаётся, и ошибка та же при 4 ГБ памяти/свопа, поэтому вот лог сборки.

rebuild.out.240425.txt (202.4 КБ)

Надеюсь, вы сможете что-то увидеть, и спасибо за помощь до сих пор…

[

SIGTERM похоже на то, что вы нажали Control-C.

Вам надоело ждать, и вы прервали задачу?

Нет — я предполагаю, что что-то в одном из скриптов процесса сборки. Я собираю его так же уже много лет (подключаюсь по SSH к нескольким сеансам — один наблюдает за другим…). Все они, начиная с момента, когда всё стало сбоить, содержат SIGTERM (предположительно) в том же месте скрипта, которое, кажется, закрывает приложение, из которого что-то читается…

Нет. Я думаю, что запрос прошёл успешно. Возможно, ошибка заключается в сообщении «failed to commit» в самом конце, но у меня нет для этого восклицательного знака.

Есть ли в скрипте лаунчера что-то, что отправляет данные обратно в GitHub? Это могло бы объяснить ошибку, если они отслеживают какие-то метрики по коммиту. Если это реализовано в shell-конвейере (например, через Curl или подобное), это также могло бы вызвать ошибку закрытого канала.

Вместо того чтобы пытаться отлаживать, что происходит с лаунчером, я думаю, что для меня проще всего будет попробовать выполнить новую установку и восстановление.

Буду рад вашим предложениям, если у вас есть какие-то идеи…

Устарела ли ваша ОС?

Появляется множество странных ошибок, связанных с невозможностью записи некоторых файлов git.

Вероятно, стоит создать новую виртуальную машину. Проще всего восстановить из резервной копии, но вы также можете перенести сайт Discourse на другой VPS с помощью rsync

Наверное, это было излишним, но я создал новый droplet, выполнил чистую установку и затем восстановил старую резервную копию оттуда.

Теперь всё работает…

Недавно у кого-то возникла похожая ошибка, которую я связываю с истекшим ключом цепочки для HTTPS-сертификатов. Подозреваю, что это была ваша проблема.

Другой пользователь выполнил обновление ОС, что решило проблему, но я предпочитаю начать с чистого листа.