Hello, Anyone can help me? I, [2025-02-24T17:35:41.516926 #1] INFO -- : Terminating async processes I, [2025-02-24T17:35:41.516987 #1] INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main pid: 38 105:signal-handler (1740418541) Received SIGTERM scheduling shutdown... I, [2025-02-24T17:35:41.517067 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 105 2025-02-24 17:35:41.517 UTC [38] LOG: received fast shutdown request 2025-02-24 17:35:41.518 UTC [38] LOG: aborting any active transactions 2025-02-24 17:35:41.521 UTC [38] LOG: background worker "logical replication launcher" (PID 52) exited with exit code 1 105:M 24 Feb 2025 17:35:41.523 # User requested shutdown... 105:M 24 Feb 2025 17:35:41.523 * Saving the final RDB snapshot before exiting. 2025-02-24 17:35:41.525 UTC [47] LOG: shutting down 2025-02-24 17:35:41.538 UTC [47] LOG: checkpoint starting: shutdown immediate 2025-02-24 17:35:41.550 UTC [47] LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.005 s, sync=0.001 s, total=0.025 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=1122 kB 2025-02-24 17:35:41.581 UTC [38] LOG: database system is shut down 105:M 24 Feb 2025 17:35:41.657 * DB saved on disk 105:M 24 Feb 2025 17:35:41.657 # Redis is now ready to exit, bye bye... FAILED -------------------- Pups::ExecError: cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets failed with return # Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn' exec failed with the params {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets", "sudo -E -u discourse bundle exec rake s3:expire_missing_assets"]} 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. c08b2ad74e9f1171f7677979af4e41a46be92877a0783350b2f020359895a431

Please help me understand correctly. Do you mean to set DISCOURSE_USE_S3: false in app.yml? I would like to do this because my Discourse server is in Asia, and B2 only has servers in the US. Also, this time, the AWS SDK issue is related to asset management, right? So if I store assets on the local server, it may avoid the issue (if I understand the situation correctly).

The issue is related to removing assets from S3. If you’ll remove just the line that tries to remove the unused assets it will work right now. And it sounds like soon the problem will be resolved. This is the easiest solution. It’s what I recommend. That’s my best free answer.

Thank you, that’s very helpful for me!

[imagem] Falco: [imagem] metadaddy: but it’s helpful to know that it doesn’t cover a number of scenarios, including: Deleting files - Discourse is using the DeleteObjects S3 operation to delete multiple files in a single API call, as it should. Yeah, and AWS SDK maintainers are only giving us the cold shoulder on this s3.deleteObjects sends CRC32 checksum even if `requestChecksumCalculation` is set to `WHEN_REQUIRED` · Issue #6819 · aws/aws-sdk-js-v3 · GitHub This is because, in the S3 API definition, the DeleteObjects operation has httpChecksum.requestChecksumRequired set to true, in contrast to, say, PutObject, which sets it to false. So the SDK is honoring WHEN_REQUIRED, because the checksum is required. All of the AWS SDKs are now generated from the API definition, with minimal extra code to cover edge situations. The code sees that DeleteObjects requires a checksum, and the way to do that now is to use one of the new checksums, rather than Content-MD5. Unfortunately, AWS didn’t see fit to provide a ‘use Content-MD5 like you used to’ configuration. They don’t tend to consider the third-party object storage ecosystem when they make these sorts of changes, since they don’t really need to. The only time that stuff like this gets fixed is when it accidentally hoses one of their own services in some corner case.

[imagem] Yt.w: B2 only has servers in the US Not that it particularly helps if you’re in Asia, but, for the record, we also have data centers in Europe (Amsterdam, Netherlands) and, since the beginning of this year, Canada (Toronto). I can’t make any promises, but we are definitely considering an Asia location. Also, if you use a CDN, it doesn’t matter too much where the origin server is.

You’re right! Backblaze does not support x-amz-checksum-crc32, and Discourse’s newer AWS SDK version may have enabled this by default. so i went into the app: ./launcher enter app and uninstalled the current version of AWS SDK: gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms and installed the one that the backblaze guy said would work: gem install aws-sdk-core -v “~> 3.215.1” gem install aws-sdk-kms -v “~> 1.96.0” gem install aws-sdk-s3 -v “~> 1.177.0” then I rebuilt the app and it worked!

[imagem] AntiMetaman: I rebuilt the app and it worked! If you rebuilt the app then the changes made in the container are gone. Perhaps the backblaze folks fixed things while you were doing that.

I just commented out the S3 and rebuilt. I guess I’ll stick to local storage from now on.

Local storage works fine. It’s just deleting that does not work.

[imagem] metadaddy: This is because, in the S3 API definition, the DeleteObjects operation has httpChecksum.requestChecksumRequired set to true, in contrast to, say, PutObject, which sets it to false. So the SDK is honoring WHEN_REQUIRED, because the checksum is required. All of the AWS SDKs are now generated from the API definition, with minimal extra code to cover edge situations. The code sees that DeleteObjects requires a checksum, and the way to do that now is to use one of the new checksums, rather than Content-MD5. Unfortunately, AWS didn’t see fit to provide a ‘use Content-MD5 like you used to’ configuration. They don’t tend to consider the third-party object storage ecosystem when they make these sorts of changes, since they don’t really need to. The only time that stuff like this gets fixed is when it accidentally hoses one of their own services in some corner case. Thanks for posting and confirming there is no current workaround without downgrading the aws SDKs. I ran into issues with the b2 s3 apis from another project using the golang aws sdk, trying to back up a VictoriaMetrics database. Do you have any sense from your engineering team how or when they may choose to resolve this issue, or have any way to track/get updates on a supported workaround? I’m trying to decide if I should fork and recompile a project with a dependency change or just wait a little while for an update! Thanks!

Não é possível reconstruir devido ao aumento da versão da gem AWS SDK e às novas Proteções de Integridade de Dados da AWS

Suporte ao Produto Instalação

PatPatterson (metadaddy) 4 Novembro , 2025 15:58 53

Olá - sim, o Backblaze B2 adicionou suporte oficial aos cabeçalhos de checksum no início deste ano.

Backup upload failure due to uninitialized TransferManager

Tópico		Respostas	Vistas
Error Upgrading from 3.4.0.beta4-dev to 3.5.0.beta1 Product Support	2	275	6 Março , 2025
Configure an S3 compatible object storage provider for uploads Self-Hosting cdn , configuring , how-to , reference	267	54124	15 Setembro , 2026
Rake uploads:migrate_to_s3 error Self-hosting s3	8	1012	6 Janeiro , 2020
Cannot upload or backup to Amazon S3 Self-hosting backups , s3	3	2231	14 Outubro , 2015
Issues with AWS CDN and S3 Self-hosting cdn , s3	22	1291	30 Dezembro , 2025

Não é possível reconstruir devido ao aumento da versão da gem AWS SDK e às novas Proteções de Integridade de Dados da AWS

Related topics