У меня возникла проблема с пересборкой тестового домена (самостоятельный хостинг — работает около 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
Я просмотрел остальную часть лога, и единственные дополнительные ошибки, которые я вижу, в других сообщениях здесь считаются «не важными».
Есть ли какие-либо предложения, что делать дальше?
Думаю, на данном этапе мне останется выполнить чистую установку, а затем попытаться восстановить из резервной копии, но буду признателен за любые подсказки о том, что на самом деле происходит…
Я следил — я забыл, что мы возились с экземпляром WordPress, который также работает на этом droplet, так что мы определённо используем какую-то подкачку. Вероятно, в любом случае нужно увеличить этот VPS…
Да.
Я выполнил grep по логу и не нашёл этой ошибки.
У меня появилась блестящая идея перезагрузить VPS перед повторной попыткой. Если это не сработает, я увеличу размер droplet и попробую снова.
Нет — я предполагаю, что что-то в одном из скриптов процесса сборки. Я собираю его так же уже много лет (подключаюсь по SSH к нескольким сеансам — один наблюдает за другим…). Все они, начиная с момента, когда всё стало сбоить, содержат SIGTERM (предположительно) в том же месте скрипта, которое, кажется, закрывает приложение, из которого что-то читается…
Нет. Я думаю, что запрос прошёл успешно. Возможно, ошибка заключается в сообщении «failed to commit» в самом конце, но у меня нет для этого восклицательного знака.
Есть ли в скрипте лаунчера что-то, что отправляет данные обратно в GitHub? Это могло бы объяснить ошибку, если они отслеживают какие-то метрики по коммиту. Если это реализовано в shell-конвейере (например, через Curl или подобное), это также могло бы вызвать ошибку закрытого канала.
Вместо того чтобы пытаться отлаживать, что происходит с лаунчером, я думаю, что для меня проще всего будет попробовать выполнить новую установку и восстановление.
Буду рад вашим предложениям, если у вас есть какие-то идеи…
Недавно у кого-то возникла похожая ошибка, которую я связываю с истекшим ключом цепочки для HTTPS-сертификатов. Подозреваю, что это была ваша проблема.
Другой пользователь выполнил обновление ОС, что решило проблему, но я предпочитаю начать с чистого листа.