Hello everyone, I’m running into an issue with PostgreSQL startup issue when I tried to rebuild my app, and I’m hoping to get some help. Here’s the log, it has been stuck on this status for more than 30 mins. Status: Image is up to date for discourse/base:2.0.20240825-0027 docker.io/discourse/base:2.0.20240825-0027 /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb /usr/local/bin/pups --stdin I, [2024-08-26T17:16:15.344712 #1] INFO -- : Reading from stdin I, [2024-08-26T17:16:15.357924 #1] INFO -- : File > /etc/service/postgres/run chmod: +x chown: I, [2024-08-26T17:16:15.362740 #1] INFO -- : File > /etc/service/postgres/log/run chmod: +x chown: I, [2024-08-26T17:16:15.367767 #1] INFO -- : File > /etc/runit/3.d/99-postgres chmod: +x chown: I, [2024-08-26T17:16:15.372845 #1] INFO -- : File > /root/install_postgres chmod: +x chown: I, [2024-08-26T17:16:15.377501 #1] INFO -- : File > /root/upgrade_postgres chmod: +x chown: I, [2024-08-26T17:16:15.377876 #1] INFO -- : Replacing data_directory = '/var/lib/postgresql/13/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.378854 #1] INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.379386 #1] INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.379835 #1] INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.380263 #1] INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.380761 #1] INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.381203 #1] INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.381901 #1] INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.382352 #1] INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/13/main/postgresql.conf I, [2024-08-26T17:16:15.382802 #1] INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres peer in /etc/postgresql/13/main/pg_hba.conf I, [2024-08-26T17:16:15.383231 #1] INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/13/main/pg_hba.conf I, [2024-08-26T17:16:15.383604 #1] INFO -- : Replacing (?-mix:^host.*all.*all.*::1\/128.*$) with host all all ::/0 md5 in /etc/postgresql/13/main/pg_hba.conf I, [2024-08-26T17:16:15.384079 #1] INFO -- : > if [ -f /root/install_postgres ]; then /root/install_postgres && rm -f /root/install_postgres elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1 fi 2024/08/26 17:16:15 socat[28] E connect(, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): Connection refused I, [2024-08-26T17:16:15.452500 #1] INFO -- : Generating locales (this might take a while)... Generation complete. I, [2024-08-26T17:16:15.453058 #1] INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main I, [2024-08-26T17:16:15.455944 #1] INFO -- : Terminating async processes 2024-08-26 17:16:15.500 UTC [30] LOG: starting PostgreSQL 13.16 (Debian 13.16-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit 2024-08-26 17:16:15.501 UTC [30] LOG: listening on IPv4 address "0.0.0.0", port 5432 2024-08-26 17:16:15.501 UTC [30] LOG: listening on IPv6 address "::", port 5432 2024-08-26 17:16:15.507 UTC [30] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2024-08-26 17:16:15.516 UTC [31] LOG: database system was interrupted; last known up at 2024-08-26 17:10:28 UTC 2024-08-26 17:16:15.769 UTC [31] LOG: database system was not properly shut down; automatic recovery in progress 2024-08-26 17:16:15.774 UTC [31] LOG: redo starts at 18F/E62D1458 2024-08-26 17:16:15.774 UTC [31] LOG: invalid record length at 18F/E62D1490: wanted 24, got 0 2024-08-26 17:16:15.774 UTC [31] LOG: redo done at 18F/E62D1458 2024-08-26 17:16:15.809 UTC [30] LOG: database system is ready to accept connections```

@here It looks like older versions of Docker is incompatible with the newer Docker image which we have released. Here are the steps to fix the problem: apt update apt install docker.io cd /var/discourse ./launcher rebuild app I’ve also bumped our launcher script to abort if we do not at least detect Docker 20.10.0 running.

Having the same issue… DO Droplet on Ubuntu 20.04. Tried to Upgrade Docker from within Discourse first but it kept getting an error code 137. So then I tried to rebuild Discourse from the command line and it hung on The database is ready to accept connections. Ctrl+C wouldn’t do anything so closed SSH and opened a new one and started Discourse again and it was still working but not updated. Rebooted the droplet and tried upgrading Docker again from Discourse and this time it worked! So I tried rebuilding Discourse again but it still hung on the same place. Closed SSH again and opened and started Discourse again but now I get the Oops screen! So now my Discourse site is down and the only way I’ve ever been able to recover from the Oops screen previously is by rebuild the app which I can’t do! So now I’m at a loss as my Discourse and Droplet experience is very limited and I’m not sure what I can do now. docker_manager is the only plugin used in my app.yml so I can only assume the error is due to Docker being a newer version and not jiving with my Discourse version? I don’t know. I last updated Discourse in January so it’s not that out of date… So my site is down until this issue can be figured out… Unless I start up a new Droplet and re-set up everything again and restore the Discourse backup that I took? Is that my only option at this point? :tired_face:

Error 137 is out of memory. I would try adding more swap. If you have only 1gb of ram I might resize to 2gb and perhaps also have 3 or 4 gb of swap. You might try a ./launcher start app But I suspect that the database has migrated too far for the old container. If you’re stuck and want paid support see Contact Us - Literate Computing Edit: But here’s what I’d do: [图片] Alan Tan: please PM me so that I can debug the problem on a server that has the problem

Hello, same error here. Workaround for now is to force version param in app.yml to v3.3.0. Arch AMD64, Ubuntu 18.04. Strange that a minor version failed, update to v3.3.0 passed without problem last week :neutral_face:

For anyone running into this problem and am comfortable giving me access to your server, please PM me so that I can debug the problem on a server that has the problem. I have tried multiple ways and cannot reproduce this problem which makes it harder to push a fix.

I don’t see a way in my profile to PM you…

You need to be at trust level 1 to send messages [图片]Understanding Discourse Trust Levels Get to trust level 1 by… Entering at least 5 topics Reading at least 30 posts Spend a total of 10 minutes reading posts Looking at the stats in your profile, you’re pretty close already

For anyone that is stuck with this issue with Discourse down, I’ve found you can at least get the old version of the forum up by restarting the VM and then running ./launcher start app. This command won’t work after attempting a rebuild without restarting your instance / VM. I should be able to bump the Ubuntu version on our affected VM on Monday, so will keep everyone posted on the outcome.

Ctrl+c doesn’t work when it is stuck, have to reboot system.

This command also doesn’t do anything. **/var/discourse**# ./launcher start app 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 + /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=techoforum.com -e DISCOURSE_DEVELOPER_EMAILS=techoforumd@gmail.com -e DISCOURSE_SMTP_ADDRESS=smtp.sendgrid.net -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=apikey -e DISCOURSE_SMTP_PASSWORD=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 -e DISCOURSE_SMTP_DOMAIN=gmail.com -e DISCOURSE_NOTIFICATION_EMAIL=techoforumd@gmail.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h discourseonubuntu2004-s-1vcpu-1gb-sfo3-01-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f8:99:7d:c3:d6 local_discourse/app /sbin/boot Unable to find image 'local_discourse/app:latest' locally docker: Error response from daemon: pull access denied for local_discourse/app, repository does not exist or may require 'docker login': denied: requested access to the resource is denied. See 'docker run --help'.

I’ve another forum on another droplet and that doesn’t give any issue with updating. It is weird why with same server configuration one droplet has issues while other doesn’t?

PostgreSQL在重建过程中卡住

产品支持安装

Moin 2024 年8 月 30 日 12:13 29

您需要达到信任等级 1 才能发送消息

查看您个人资料中的统计数据，您已经非常接近了

话题		回复	浏览量
Forum Full Crash (Test Pressing) Self-hosting	8	561	2024 年9 月 4 日
Stuck on update Self-hosting	2	353	2024 年9 月 4 日
Update Error Self-hosting	6	347	2024 年8 月 30 日
Issue with rebuilding Self-hosting	2	115	2026 年9 月 15 日
Postgres Errors on Rebuild Self-hosting	2	1760	2015 年9 月 16 日

PostgreSQL在重建过程中卡住

相关话题