فشل في خطأ bootstrap - مشكلة مع pups

تثبيت
1

Hi folks -

I’ve recently been trying to rebuild our test instance after an update with no luck. Googling/ChatGPT indicates that maybe something is wrong with the app.yml formatting, but I’ve not been able to suss it out. Here’s the stdout, which I realize is not that useful:

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

I’d like to upload the stderr as an attachment, but as a new user I can’t. Maybe this last bit of the log with the excerpt involving pups is enough?

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>'

Is there anything else I should look for that would shed some light on the problem? I appreciate your help!

2

Incidentally, I ran the app.yml file through a YAML linter and it didn’t find anything. I also tried rebuilding without any plugins active, and that didn’t make a difference.

3

Suggest you paste some or all of your YML file - take care redact passwords and access tokens. The output

does seem suspicious. My own YML file is very simple, no commands, but perhaps yours is complicated.

إعجابَين (2)
4

Thanks @Ed_S. I’ve attached the YML in the hopes there’s a clue there.

app_yml_redacted.txt (4.7 KB)

5

Thanks. The only thing I can see is that where I have

templates/web.ratelimited.template.yml

you have

templates/web.ratelimited-whitelist.template.yml

Just possibly there is a syntax error in that file? It would be, I think, at

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

Although there could equally be a syntax error in any of the other templates mentioned.

إعجاب واحد (1)
6

I’ve definitely narrowed it down to this file, which is for sure causing the boot failure -

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

which I’m pasting below (with IPs redacted):

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;

Is there anything in the run command here that looks off? YAML linting still looks OK.

7

Your indentation is just very slightly different from what I might expect. And you have a blank line at the end. But I don’t know if these are clues.

إعجاب واحد (1)
8

I think in your place I’d start deleting sections of this YML in a binary search to find the culprit. You have a couple of blank lines, and you have two ‘replace’ sections which you could perhaps remove one at a time. Start by removing major sections and hope you can converge on the problem.

إعجابَين (2)
9

Thanks for your help @Ed_S, it turned about to be some poor indentation buried in the YAML file I mentioned above. Not sure why any of the linters didn’t pick up on it, but diffing the problem file versus one in production made the problem clear right away.

إعجابَين (2)
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.