./launcher stop app 명령을 실행한 후 ./launcher start app 명령을 실행하면 사이트에서 502 Bad Gateway 오류가 발생합니다. 문제가 무엇인지 모르겠으며, 재빌드를 시도해 보았지만 효과가 없었습니다.
이 문제를 해결하는 방법에 대해 조언해 주실 수 있나요?
리빌드 로그를 공유해 주시겠어요?
root@amsaal:/var/discourse# ./launcher logs app
x86_64 아키텍처 감지됨.
run-parts: /etc/runit/1.d/00-ensure-links 실행 중
run-parts: /etc/runit/1.d/00-fix-var-logs 실행 중
run-parts: /etc/runit/1.d/01-cleanup-web-pids 실행 중
run-parts: /etc/runit/1.d/anacron 실행 중
run-parts: /etc/runit/1.d/cleanup-pids 실행 중
구식 PID 파일 정리 중
run-parts: /etc/runit/1.d/copy-env 실행 중
run-parts: /etc/runit/1.d/letsencrypt 실행 중
[Mon 15 Apr 2024 10:12:06 AM UTC] 도메인 변경 없음.
[Mon 15 Apr 2024 10:12:06 AM UTC] 건너뜀, 다음 갱신 시각: 2024-06-12T11:28:31Z
[Mon 15 Apr 2024 10:12:06 AM UTC] 강제 갱신을 하려면 '--force'를 추가하세요.
[Mon 15 Apr 2024 10:12:07 AM UTC] 키를 /shared/ssl/amsaal.net.key에 설치 중
[Mon 15 Apr 2024 10:12:07 AM UTC] 전체 체인을 /shared/ssl/amsaal.net.cer에 설치 중
[Mon 15 Apr 2024 10:12:07 AM UTC] 재시작 명령 실행: sv reload nginx
경고: nginx: supervise/ok 열 수 없음: 파일이 존재하지 않음
[Mon 15 Apr 2024 10:12:07 AM UTC] 재시작 오류:
[Mon 15 Apr 2024 10:12:07 AM UTC] 도메인 변경 없음.
[Mon 15 Apr 2024 10:12:07 AM UTC] 건너뜀, 다음 갱신 시각: 2024-06-12T11:28:38Z
[Mon 15 Apr 2024 10:12:07 AM UTC] 강제 갱신을 하려면 '--force'를 추가하세요.
[Mon 15 Apr 2024 10:12:08 AM UTC] 키를 /shared/ssl/amsaal.net_ecc.key에 설치 중
[Mon 15 Apr 2024 10:12:08 AM UTC] 전체 체인을 /shared/ssl/amsaal.net_ecc.cer에 설치 중
[Mon 15 Apr 2024 10:12:08 AM UTC] 재시작 명령 실행: sv reload nginx
경고: nginx: supervise/ok 열 수 없음: 파일이 존재하지 않음
[Mon 15 Apr 2024 10:12:08 AM UTC] 재시작 오류:
runsvdir 시작됨, PID는 537입니다
ok: run: redis: (pid 550) 0초
ok: run: postgres: (pid 551) 0초
nginx: [warn] /etc/nginx/conf.d/discourse.conf:60에서 "listen ... http2" 지시문은 비추천(deprecated)되므로 대신 "http2" 지시문을 사용하세요
supervisor pid: 545 unicorn pid: 577
root@amsaal:/var/discourse#
제가 의도한 바가 아닙니다. ./launcher rebuild app을 실행한 후 그 출력을 공유해 주시겠어요? (그리고 출력을 코드 펜스에 넣어주시면 주제가 읽기 훨씬 편합니다)
이렇게 하면 표준 출력을 파일로 기록하므로 사용자가 다시 빌드하는 것이 조금 더 쉬워집니다.
./launcher rebuild app >> rebuild.log
빌드마다 다른 파일로 로그를 저장하려면:
./launcher rebuild app > "rebuild-$(date -Imin).log" 2>&1
컨테이너를 시작하면 서비스가 실제로 제공되기까지 1~2분이 걸립니다. 웹사이트에 접속하기 전에 몇 분 정도 기다려 보셨나요?
x86_64 아키텍처가 감지되었습니다.
런처가 최신 상태인지 확인 중
런처가 최신 상태입니다
기존 컨테이너 중지 중
app
2.0.20231218-0429: discourse/base에서 가져오는 중
Digest: sha256:468f70b9bb4c6d0c6c2bbb3efc1a5e12d145eae57bdb6946b7fe5558beb52dc1
Status: discourse/base:2.0.20231218-0429 이미지가 최신 상태입니다
docker.io/discourse/base:2.0.20231218-0429
/usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
97:C 15 Apr 2024 18:52:04.329 # oO0OoO0OoO0Oo Redis 시작 중 oO0OoO0OoO0Oo
97:C 15 Apr 2024 18:52:04.329 # Redis version=7.0.7, bits=64, commit=00000000, modified=0, pid=97, just started
97:C 15 Apr 2024 18:52:04.330 # Configuration loaded
97:M 15 Apr 2024 18:52:04.331 * monotonic clock: POSIX clock_gettime
97:M 15 Apr 2024 18:52:04.336 * Running mode=standalone, port=6379.
97:M 15 Apr 2024 18:52:04.336 # Server initialized
97:M 15 Apr 2024 18:52:04.337 * Loading RDB produced by version 7.0.7
97:M 15 Apr 2024 18:52:04.337 * RDB age 31 seconds
97:M 15 Apr 2024 18:52:04.337 * RDB memory usage when created 23.25 Mb
97:M 15 Apr 2024 18:52:04.451 * Done loading RDB, keys loaded: 1351, keys expired: 5.
97:M 15 Apr 2024 18:52:04.461 * DB loaded from disk: 0.124 seconds
97:M 15 Apr 2024 18:52:04.461 * Ready to accept connections
3507:C 15 Apr 2024 18:58:01.238 # oO0OoO0OoO0Oo Redis 시작 중 oO0OoO0OoO0Oo
3507:C 15 Apr 2024 18:58:01.238 # Redis version=7.0.7, bits=64, commit=00000000, modified=0, pid=3507, just started
3507:C 15 Apr 2024 18:58:01.238 # Configuration loaded
3507:M 15 Apr 2024 18:58:01.239 * monotonic clock: POSIX clock_gettime
3507:M 15 Apr 2024 18:58:01.240 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
3507:M 15 Apr 2024 18:58:01.240 # Failed listening on port 6379 (TCP), aborting.
97:M 15 Apr 2024 18:58:27.220 * 100 changes in 300 seconds. Saving...
97:M 15 Apr 2024 18:58:27.223 * Background saving started by pid 3555
3555:C 15 Apr 2024 18:58:30.967 * DB saved on disk
3555:C 15 Apr 2024 18:58:30.969 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
97:M 15 Apr 2024 18:58:31.058 * Background saving terminated with success
97:M 15 Apr 2024 19:03:32.047 * 100 changes in 300 seconds. Saving...
97:M 15 Apr 2024 19:03:32.063 * Background saving started by pid 3634
3634:C 15 Apr 2024 19:03:37.774 * DB saved on disk
3634:C 15 Apr 2024 19:03:37.777 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
97:M 15 Apr 2024 19:03:37.828 * Background saving terminated with success
97:signal-handler (1713208309) Received SIGTERM scheduling shutdown...
97:M 15 Apr 2024 19:11:49.130 # User requested shutdown...
97:M 15 Apr 2024 19:11:49.131 * Saving the final RDB snapshot before exiting.
97:M 15 Apr 2024 19:11:52.592 * DB saved on disk
97:M 15 Apr 2024 19:11:52.593 # Redis is now ready to exit, bye bye...
sha256:066d1fc0bf450b6f9043e13960cafef6b7751d92f0d89cc4e0865208293ce2e2
58661874f252e2e9dac3955608dbbe90e60f020a4d307d2818e7f991d39f8010
Removing old container
app
ea032a7acab7743f4ef8de3b9a536da0dbbf36b8c9dd5b2a9add0cfb01286e5d
네, 재빌드 과정이 완료된 후 30초가 지났을 때 사이트가 작동하지 않고 502 게이트웨이 오류가 발생했어요. 그래서 /launch restart app과 launch start app을 실행했는데, 그때부터 정상적으로 작동하기 시작했죠.
그래서 뭔가 문제가 있는 것 같습니다.
그… 로그가 불완전한 것 같습니다. 실제로 거기서 끝나는 건지, 아니면 장기간 일시정지된 건가요? 후자라면 더 많은 RAM/스왑이 필요할 수 있습니다.
60초 정도 기다려 보세요.
일시정지 상태이거나, 재구축 완료에 약 30분이라는 상당한 시간이 걸리는 것일 수 있습니다. RAM이 2GB뿐이라 속도가 느려지는 원인일 수 있다고 생각하지만, 현재로서는 메모리 관련 문제는 없습니다. 그냥 속도만 느린 건데, 사양에 따라 다르겠지만 보통 1~2분을 넘기지 않아야 정상입니다.
아래는 제 VPS 사양입니다.
CPU: AMD EPYC 7551P 32코어 프로세서, 2000 MHz
RAM: 2 GB
SSD: 60 GB
컨테이너가 실행 중이 아니라면 502 오류가 발생하지 않습니다. 조금 더 기다렸다면 사이트가 정상적으로 작동했을 것입니다.
정지하고 다시 시작하는 것 때문에 작동한 것이 아니라, 재시작을 수행할 때 충분히 오래 기다렸기 때문입니다.
컨테이너가 시작되는 동안에는 502 오류가 발생하는 것이 정상입니다. 문제없습니다.
솔직히 그건 그렇게 이례적인 일은 아닙니다. 재구축은 원래 빠르지 않거든요, 특히…
…메모리가 충분하지 않을 때는 더 그렇습니다.
일반적으로 요즘에는 Discourse의 경우 총 메모리(램과 스왑)가 최소 4GB는 있어야 한다고 권장됩니다.
관리자 인터페이스에서 discourse를 업데이트하는 동안 이 호환성 문제 경고가 표시됩니다.
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
[3/5] Fetching packages...
warning Pattern ["wrap-ansi-cjs@npm:wrap-ansi@^7.0.0"] is trying to unpack in the same destination "/home/discourse/.cache/yarn/v6/npm-wrap-ansi-cjs-7.0.0-67e145cff510a6a6984bdf1152911d69d2eb9e43-integrity/node_modules/wrap-ansi-cjs" as pattern ["wrap-ansi@^7.0.0"]. This could result in non-deterministic behavior, skipping.
[4/5] Linking dependencies...
warning "@discourse/lint-configs > eslint-plugin-ember > ember-eslint-parser@0.3.8" has unmet peer dependency "@typescript-eslint/parser@^6.15.0".
warning " > @glint/environment-ember-loose@1.4.0" has unmet peer dependency "@glimmer/component@^1.1.2".
warning " > discourse-markdown-it@1.0.0" has unmet peer dependency "xss@*".
warning "workspace-aggregator-e69f39ff-3f17-47f3-9e20-638bb7914a45 > discourse > @uppy/aws-s3@3.0.6" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-e69f39ff-3f17-47f3-9e20-638bb7914a45 > discourse > @uppy/aws-s3-multipart@3.1.3" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-e69f39ff-3f17-47f3-9e20-638bb7914a45 > discourse > @uppy/xhr-upload@3.1.1" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-e69f39ff-3f17-47f3-9e20-638bb7914a45 > discourse-plugins > ember-this-fallback@0.4.0" has unmet peer dependency "ember-source@^3.28.11 || ^4.0.0".
warning "workspace-aggregator-e69f39ff-3f17-47f3-9e20-638bb7914a45 > admin > ember-source > router_js@8.0.3" has unmet peer dependency "rsvp@^4.8.5".
warning "workspace-aggregator-e69f39ff-3f17-47f3-9e20-638bb7914a45 > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0" has incorrect peer dependency "@uppy/core@^3.2.1".
이것들은 무시해도 안전하며, Discourse의 재구축을 방해하지 않습니다.