부트스트랩 실패 오류 - pups 관련 문제

지원 자체 호스팅
1

안녕하세요 여러분 -

최근 업데이트 후 테스트 인스턴스를 다시 구축하려고 시도하고 있지만 성공하지 못하고 있습니다. 구글 검색이나 ChatGPT를 통해 app.yml 파일의 형식 관련 문제가 있을 수 있다는 추측이 나오는데, 아직 원인을 파악하지 못했습니다. 여기 stdout을 첨부합니다. 물론 이 내용만으로는 큰 도움이 되지 않을 수 있다는 점은 잘 알고 있습니다:

x86_64 arch detected.
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml
Ensuring launcher is up to date
Your version of Launcher is ahead of origin
Stopping old container
app
2.0.20250226-0128: Pulling from discourse/base
Digest: sha256:6f18aa2cd22bba0deb91d69194e577d4f96130ad555ae8ec646a8792cbfe37db
Status: Image is up to date for discourse/base:2.0.20250226-0128
docker.io/discourse/base:2.0.20250226-0128
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
109:C 13 Jun 2025 15:20:04.997 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
109:C 13 Jun 2025 15:20:04.997 # Redis version=7.0.15, bits=64, commit=00000000, modified=0, pid=109, just started
109:C 13 Jun 2025 15:20:04.997 # Configuration loaded
109:M 13 Jun 2025 15:20:04.997 * monotonic clock: POSIX clock_gettime
109:M 13 Jun 2025 15:20:04.998 * Running mode=standalone, port=6379.
109:M 13 Jun 2025 15:20:04.998 # Server initialized
109:M 13 Jun 2025 15:20:04.999 * Loading RDB produced by version 7.0.7
109:M 13 Jun 2025 15:20:04.999 * RDB age 14 seconds
109:M 13 Jun 2025 15:20:04.999 * RDB memory usage when created 2.95 Mb
109:M 13 Jun 2025 15:20:05.007 * Done loading RDB, keys loaded: 3659, keys expired: 0.
109:M 13 Jun 2025 15:20:05.007 * DB loaded from disk: 0.008 seconds
109:M 13 Jun 2025 15:20:05.007 * Ready to accept connections
3649:C 13 Jun 2025 15:22:52.415 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3649:C 13 Jun 2025 15:22:52.415 # Redis version=7.0.15, bits=64, commit=00000000, modified=0, pid=3649, just started
3649:C 13 Jun 2025 15:22:52.415 # Configuration loaded
3649:M 13 Jun 2025 15:22:52.415 * monotonic clock: POSIX clock_gettime
3649:M 13 Jun 2025 15:22:52.416 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
3649:M 13 Jun 2025 15:22:52.416 # Failed listening on port 6379 (TCP), aborting.
109:M 13 Jun 2025 15:25:05.035 * 100 changes in 300 seconds. Saving...
109:M 13 Jun 2025 15:25:05.041 * Background saving started by pid 3823
3823:C 13 Jun 2025 15:25:05.257 * DB saved on disk
3823:C 13 Jun 2025 15:25:05.257 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
109:M 13 Jun 2025 15:25:05.342 * Background saving terminated with success
109:signal-handler (1749828411) Received SIGTERM scheduling shutdown...
109:M 13 Jun 2025 15:26:51.694 # User requested shutdown...
109:M 13 Jun 2025 15:26:51.694 * Saving the final RDB snapshot before exiting.
109:M 13 Jun 2025 15:26:51.710 * DB saved on disk
109:M 13 Jun 2025 15:26:51.710 # Redis is now ready to exit, bye bye...
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
5b720b35a25e026d9908c60a2f7c5bcf3725b16a0b282875e8a66ce5ace4d06b

stderr를 첨부 파일로 업로드하고 싶지만, 신규 사용자라서 그럴 수 없습니다. pups 관련 부분이 포함된 로그의 마지막 부분만으로도 충분한지 궁금합니다.

2025-06-13 15:26:51.615 UTC [42] LOG:  aborting any active transactions
2025-06-13 15:26:51.634 UTC [42] LOG:  background worker "logical replication launcher" (PID 56) exited with exit code 1
2025-06-13 15:26:51.634 UTC [51] LOG:  shutting down
2025-06-13 15:26:51.637 UTC [51] LOG:  checkpoint starting: shutdown immediate
2025-06-13 15:26:51.646 UTC [51] LOG:  checkpoint complete: wrote 15 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.003 s, total=0.012 s; sync files=3, longest=0.003 s, average=0.001 s; distance=49 kB, estimate=243 kB
2025-06-13 15:26:51.659 UTC [42] LOG:  database system is shut down
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:223:in `block (2 levels) in run_commands': Invalid run command filename (SyntaxError)
	from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:211:in `each'
	from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:211:in `block in run_commands'
	from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:210:in `each'
	from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:210:in `run_commands'
	from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:191:in `run'
	from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/cli.rb:89:in `run'
	from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/bin/pups:9:in `<top (required)>'
	from /usr/local/bin/pups:25:in `load'
	from /usr/local/bin/pups:25:in `<main>'

문제를 파악하는 데 도움이 될 다른 부분을 찾아봐야 할까요? 도움을 주셔서 감사합니다!

2

참고로, app.yml 파일을 YAML 린터로 검사해 보았지만 아무런 문제가 발견되지 않았습니다. 또한 플러그인을 모두 비활성화한 상태로 다시 빌드해 보았지만, 차이가 없었습니다.

3

YML 파일의 일부 또는 전체를 붙여넣어 보시는 것을 권합니다. 비밀번호와 액세스 토큰은 반드시 마스킹 처리하세요. 출력 결과

은 의심스럽습니다. 제 YML 파일은 매우 단순하고 명령어가 없지만, 질문자님의 파일은 복잡할 수 있습니다.

4

@Ed_S 감사합니다. 단서가 있을까 봐 YML 파일을 첨부했습니다.

app_yml_redacted.txt (4.7 KB)

5

감사합니다. 제가 볼 수 있는 유일한 차이는 제가

templates/web.ratelimited.template.yml
을 가지고 있는 반면, 상대방은
templates/web.ratelimited-whitelist.template.yml
을 가지고 있다는 점입니다.

아마도 해당 파일에 구문 오류가 있는 것일 수 있습니다. 그 위치는 아마도

/var/discourse/templates/web.ratelimited-whitelist.template.yml
일 것입니다.

물론 언급된 다른 템플릿 중 어디에든 구문 오류가 있을 수도 있습니다.

6

확실히 이 파일이 부팅 실패의 원인인 것으로 좁혀졌습니다.

/var/discourse/templates/web.ratelimited-whitelist.template.yml

아래에 해당 파일을 붙여넣었습니다 (IP는 마스킹 처리함):

params:
  reqs_per_second: 12
  burst_per_second: 12
  reqs_per_minute: 200
  burst_per_minute: 100
  conn_per_ip: 20

run:
  - replace:
    filename: "/etc/nginx/conf.d/discourse.conf"
    from: /server.+{/
    to: |
       geo $limit {
           default 1;
           XX.YYY.ZZ.ZZZ 0; # hubprod
           XXX.YY.ZZZ.ZZZ 0; # hubdev
       }

       map $limit $limit_key {
           0 "";
           1 $binary_remote_addr;
       }

       limit_req_zone $limit_key zone=flood:10m rate=$reqs_per_secondr/s;
       limit_req_zone $limit_key zone=bot:10m rate=$reqs_per_minuter/m;
       limit_req_status 429;
       limit_conn_zone $limit_key zone=connperip:10m;
       limit_conn_status 429;
       server {
  - replace:
    filename: "/etc/nginx/conf.d/discourse.conf"
    from: "/location @discourse {/"
    to: |
       location @discourse {
         limit_conn connperip $conn_per_ip;
         limit_req zone=flood burst=$burst_per_second nodelay;
         limit_req zone=bot burst=$burst_per_minute nodelay;

여기서 run 명령에 뭔가 이상한 점이 있을까요? YAML 린팅은 여전히 정상으로 보입니다.

7

당신의 들여쓰기는 내가 예상할 수 있는 것과 아주 약간 다릅니다. 그리고 끝에 빈 줄이 하나 있습니다. 하지만 이것이 단서인지 모르겠네요.

8

제라면 바이너리 서치를 사용하여 이 YML 파일의 섹션을 삭제해 가면서 문제의 원인을 찾아볼 것 같습니다. 빈 줄이 몇 줄 있고, ‘replace’ 섹션이 두 개 있으므로 하나씩 제거해 보는 것도 방법입니다. 먼저 큰 섹션들을 제거해서 문제를 좁혀 내려가는 것이 좋습니다.

9

@Ed_S 님, 도움을 주셔서 감사합니다. 위에서 언급한 YAML 파일 안에 숨겨져 있던 단순한 들여쓰기 문제였네요. 왜 린터가 이 문제를 잡아내지 못했는지 모르겠지만, 문제 있는 파일과 프로덕션에 있는 파일을 diff로 비교해보니 바로 원인이 드러났습니다.