discourse -c 'bundle exec rake db:migrate'
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)
You must drop a column's default value before marking it as readonly
I, [2026-01-08T16:18:49.016491 #1] INFO -- : Terminating async processes
I, [2026-01-08T16:18:49.018961 #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: 46
I, [2026-01-08T16:18:49.020147 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 113
2026-01-08 16:18:49.019 UTC [46] LOG: received fast shutdown request
113:signal-handler (1767889129) Received SIGTERM scheduling shutdown...
2026-01-08 16:18:49.023 UTC [46] LOG: aborting any active transactions
2026-01-08 16:18:49.034 UTC [46] LOG: background worker "logical replication launcher" (PID 60) exited with exit code 1
2026-01-08 16:18:49.040 UTC [55] LOG: shutting down
2026-01-08 16:18:49.042 UTC [55] LOG: checkpoint starting: shutdown immediate
2026-01-08 16:18:49.057 UTC [55] LOG: checkpoint complete: wrote 32 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.007 s, sync=0.004 s, total=0.017 s; sync files=16, longest=0.002 s, average=0.001 s; distance=180 kB, estimate=180 kB
2026-01-08 16:18:49.067 UTC [46] LOG: database system is shut down
113:M 08 Jan 2026 16:18:49.108 # User requested shutdown...
113:M 08 Jan 2026 16:18:49.108 * Saving the final RDB snapshot before exiting.
113:M 08 Jan 2026 16:18:49.123 * DB saved on disk
113:M 08 Jan 2026 16:18:49.123 # Redis is now ready to exit, bye bye...
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 4483 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'
exec failed with the params {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
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.
I tried to rebuild just now, but it still failed. What is the reason?
I, [2026-01-09T05:09:31.402079 #1] INFO -- : > exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf
I, [2026-01-09T05:09:31.409979 #1] INFO -- : > sleep 10
4481:C 09 Jan 2026 05:09:31.416 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
4481:C 09 Jan 2026 05:09:31.416 # Redis version=7.0.15, bits=64, commit=00000000, modified=0, pid=4481, just started
4481:C 09 Jan 2026 05:09:31.416 # Configuration loaded
4481:M 09 Jan 2026 05:09:31.417 * monotonic clock: POSIX clock_gettime
4481:M 09 Jan 2026 05:09:31.418 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
4481:M 09 Jan 2026 05:09:31.418 # Failed listening on port 6379 (TCP), aborting.
I, [2026-01-09T05:09:41.418357 #1] INFO -- :
I, [2026-01-09T05:09:41.421210 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled: (StandardError)
You must drop a column's default value before marking it as readonly
/var/www/discourse/lib/migration/column_dropper.rb:15:in `mark_readonly'
/var/www/discourse/plugins/discourse-rewind/db/migrate/20260105171115_rename_discourse_rewind_disabled_to_enabled.rb:15:in `up'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/migration.rb:993:in `public_send'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/migration.rb:993:in `exec_migration'
/var/www/discourse/lib/freedom_patches/schema_migration_details.rb:8:in `block in exec_migration'
I, [2026-01-09T05:09:52.683547 #1] INFO -- : Terminating async processes
I, [2026-01-09T05:09:52.684945 #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: 45
112I, [2026-01-09T05:09:52.685640 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 112
:signal-handler (1767935392) Received SIGTERM scheduling shutdown...
2026-01-09 05:09:52.686 UTC [45] LOG: received fast shutdown request
2026-01-09 05:09:52.691 UTC [45] LOG: aborting any active transactions
2026-01-09 05:09:52.708 UTC [45] LOG: background worker "logical replication launcher" (PID 59) exited with exit code 1
2026-01-09 05:09:52.713 UTC [54] LOG: shutting down
2026-01-09 05:09:52.716 UTC [54] LOG: checkpoint starting: shutdown immediate
112:M 09 Jan 2026 05:09:52.718 # User requested shutdown...
112:M 09 Jan 2026 05:09:52.718 * Saving the final RDB snapshot before exiting.
2026-01-09 05:09:52.734 UTC [54] LOG: checkpoint complete: wrote 17 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.007 s, sync=0.004 s, total=0.020 s; sync files=14, longest=0.002 s, average=0.001 s; distance=71 kB, estimate=71 kB
2026-01-09 05:09:52.750 UTC [45] LOG: database system is shut down
112:M 09 Jan 2026 05:09:52.763 * DB saved on disk
112:M 09 Jan 2026 05:09:52.763 # Redis is now ready to exit, bye bye...
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 4484 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'
exec failed with the params {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
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.
Honestly, I don’t know what the problem is with your Discourse installation. I just rebuilt my second forum through the server terminal and everything is fine again. Now I’m going to rebuild my third forum, hopefully it’s fine too.
If you have made any changes to the Discourse files, I know that it can cause problems in the future. Or if you have manually added/installed any plugins.
Wait, be patient and those who know more than me will help. This is one of the reasons I like and switched to this system, the community, this is what makes it even greater.
Edit:
However, on my third forum, the rebuild didn’t work.
FAILED
Pups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ failed with return #<Process::Status: pid 4466 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn’
exec failed with the params {“cd”=>“$home”, “tag”=>“migrate”, “hook”=>“db_migrate”, “cmd”=>[“su discourse -c ‘bundle exec rake db:migrate’”]}
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.
63e30cde8c7295d25def35eef74dea30714627609c3d38b49a8f80865e5759cf
I also don’t have any manually installed plugins on my third forum, but after the failed rebuild, and the redirect to my second forum… I also checked the configuration file (nano containers/app.yml) and everything is fine there… what’s going on?
Not for me I have a server restore point luckily from 01-05-2026. For the second time I can neither update nor rebuild Discourse. Now I’m restoring it again, and one thing is clear:
Backup all topics/articles in a text file.
Hopefully this will be resolved either with a new installation of Discourse, or with another system (which I don’t want to do).
There’s something somewhere I’m missing and I don’t know what it is and it’s driving me crazy. But apparently the retrograde uranium is having its say. For now I’ll leave things like this, and go clean up some bugs in HELLDIVERS 2 because I’m sad
I understand your frustrations and I apologize. I tested my “fixes” locally on both my local dev database, and then on a brand new database and they both worked just fine. Then I tested on a hosted instance that I run for a community I manage and it worked fine there as well. It also passed all our public CIs (on GitHub) as well as our internal CIs and smoke tests.
As it happens, none of those databases had data that was affected by that migration …
I’m sorry you all had a bad experience and I’ll be more careful next time.
After I rebuilt, I found that the data was not the latest, so I restored it using the backup from the day before yesterday from the management backend. Currently, no issues have been found yet.
@here for those who are having issues, I think@david and I may have found the root cause but it’s complicated to reproduce locally.
Could any of you run the following SQL queries and report the results here?
Query #1
SELECT table_schema, column_name, column_default
FROM information_schema.columns
WHERE table_name = 'user_options'
AND column_name = 'discourse_rewind_disabled'
ORDER BY table_schema;
Query #2
SELECT n.nspname, n.oid
FROM pg_namespace n
JOIN pg_class c ON c.relnamespace = n.oid
WHERE c.relname = 'user_options'
ORDER BY n.oid;
Query #3
SELECT table_schema, column_default IS NOT NULL as has_default
FROM information_schema.columns
WHERE table_name = 'user_options'
AND column_name = 'discourse_rewind_disabled';
Query #4
SELECT nspname, oid FROM pg_namespace
WHERE nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast', 'public')
AND nspname NOT LIKE 'pg_temp%'
AND nspname NOT LIKE 'pg_toast_temp%'
ORDER BY oid;