앱 재빌드 문제

테스트 도메인을 다시 구축하는 데 문제가 생겼습니다 (자체 호스팅 - 약 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

로그의 나머지 부분을 스캔해 봤는데, 확인되는 추가적인 에러는 이 사이트의 다른 게시물에서 "중요하지 않음"으로 분류된 것들뿐입니다.

다음으로 무엇을 해야 할지 조언을 구합니다.

이 시점에서는 새로 설치한 뒤 백업에서 복원하는 것을 시도해야 할 것 같은데, 실제로 어떤 일이 일어나고 있는지 알 수 있는 힌트를 주시면 감사하겠습니다…

감사합니다!

전체 로그를 확인하지 않는 한 알 수 없습니다.

제 추측으로는 램(RAM)이 부족할 것 같습니다. 스왑(swap)을 추가해 보는 것이 좋습니다.

현재 램과 스왑 용량이 각각 얼마나 되나요?

2G. 위쪽 기준으로 보면 문제없어 보였지만, 더 추가해서 다시 시도하기는 쉽습니다.

아직 문제가 있다면 로그를 업로드하겠습니다.

내일쯤에나 할 수 있을 것 같습니다…

리빌드가 실행되는 동안 상단을 주시해야 합니다.

RAM 2GB와 스왑 2GB? 로그에서 메모리 부족에 따른 에러 137을 확인해 보세요.

저는 보고 있었어요. 그 드롭렛에서 동시에 실행 중인 WordPress 인스턴스를 만지작거리고 있었다는 걸 잊고 있었거든요. 그래서 확실히 스왑 공간을 일부 사용하고 있습니다. 어차피 그 VPS 용량을 늘려야 할 것 같습니다…

네.

로그를 grep으로 검색해 봤는데 그 오류는 보이지 않았습니다.

다시 시도하기 전에 VPS를 재부팅하는 것이 좋은 생각이라는 걸 떠올랐습니다. 그래도 실패한다면 드롭렛 용량을 늘려서 다시 시도할 것입니다.

4GB 메모리/스왑에서도 같은 방식으로 실패했습니다. 그래서 빌드 로그를 첨부합니다.

rebuild.out.240425.txt (202.4 KB)

무언가를 발견하실 수 있기를 바라며, 지금까지의 도움에 감사드립니다…

[

SIGTERM은 Control-C를 눌렀다는 뜻으로 보입니다.

기다리다 지쳐서 작업을 강제로 종료했나요?

아니요 - 빌드 프로세스의 스크립트 중 하나에 문제가 있는 것 같습니다. 수년 동안 같은 방식으로 빌드해 왔거든요(ssh로 세션 두 개를 열고, 하나는 다른 하나를 지켜보는 식으로요…). 문제가 발생하기 시작한 이후로, 해당 스크립트의 (아마도) 같은 위치에 SIGTERM이 발생하고 있으며, 어떤 것이 읽는 중인 앱을 닫게 만드는 것 같습니다…

아니요. 제 생각에는 요청이 잘 처리된 것 같습니다. 아마 오류는 마지막에 표시된 “failed to commit” 때문일 텐데, 그 부분에 대한 예외가 없네요.

런처 스크립트에서 GitHub로 데이터를 보내는 기능이 있나요? 커밋을 기준으로 추적하는某种의 메트릭이 있다면, 그걸로 에러가 설명될 수 있을 것 같습니다. 만약 셸 파이프라인(예: Curl 등)에 그런 기능이 있다면, 닫힌 파이프(closed pipe) 에러도 설명이 됩니다.

런처에서 무슨 일이 일어나고 있는지 디버깅하는 것보다는, 제 입장에서는 새 설치를 시도하고 복원하는 것이 가장 쉬울 것 같습니다.

혹시 아이디어가 있으시면 제안을 환영합니다…

OS가 최신 버전이 아닌가요?

일부 git 파일을 작성할 수 없다는 내용의 이상한 오류가 여러 개 발생하고 있습니다.

새 VM을 만드는 것이 좋은 방법일 것입니다. 백업 복원이 가장 쉽지만, rsync를 사용하여 Discourse 사이트를 다른 VPS로 이동하는 것도 가능합니다.

아마도 과한 조치일 수 있지만, 결국 새로운 드롭렛을 생성하고, 새 설치를 한 뒤, 거기서 기존 백업의 복원을 수행했습니다.

지금은 정상 작동합니다…

최근 다른 사용자도 비슷한 오류를 경험했는데, https 인증서용 키 체인이 만료된 것이 원인이었던 것 같습니다. 이 문제도 같은 원인일 것으로 추정됩니다.

해당 사용자는 OS를 업그레이드하여 문제를 해결했지만, 저는 새로 시작하는 방식을 선호합니다.