Update to 3.1.0 - Error during starting [Fixed]

Hi,

Trying to update Peertube to 3.1.0, I get this error message when starting docker stack:
peertube_1 |
peertube_1 | > peertube@3.1.0 start /app
peertube_1 | > node dist/server
peertube_1 |
postgres_1 | 2021-03-25 08:57:29.950 UTC [71] ERROR: column « filename » of relation « videoFile » already exists
postgres_1 | 2021-03-25 08:57:29.950 UTC [71] STATEMENT: ALTER TABLE « public ».« videoFile » ADD COLUMN « filename » VARCHAR(255) DEFAULT NULL;
peertube_1 | npm ERR! code ELIFECYCLE
peertube_1 | npm ERR! errno 255
peertube_1 | npm ERR! peertube@3.1.0 start: node dist/server
peertube_1 | npm ERR! Exit status 255
peertube_1 | npm ERR!
peertube_1 | npm ERR! Failed at the peertube@3.1.0 start script.
peertube_1 | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
peertube_1 |
peertube_1 | npm ERR! A complete log of this run can be found in:
peertube_1 | npm ERR! /home/peertube/.npm/_logs/2021-03-25T08_57_29_973Z-debug.log

I switched back to release 3.0.1 and instance is back online.

Any advise for me please ?
Thanks

Stop PeerTube, and delete columns (filename, fileUrl, torrentFilename, torrentUrl if they exist):

alter table "videoFile" DROP column "filename";

Then restart it and check the logs to see what failed in this migration.

OK will try your solution.

Will I lose some data ? Don’t want to :wink:

No you won’t. What is your postgresql version?

I have the exact same error, caused by the first upgrade crashed during the xecuting 0585-video-file-names.js migration script. steps.

It was too long, and kubernetes killed the container :-/

Drop all column does the trick

Alter Table "public"."videoFile" DROP COLUMN "torrentFilename", DROP COLUMN "fileUrl", DROP COLUMN "filename", DROP COLUMN "torrentUrl";

No data loss as all columns were empty.

But the update process is sooooo long, currently 50minutes, on the steps Executing 0595-remote-url.js migration script., hoping it will no be killed again :crossed_fingers:

OK :+1:

Postgres version:
image: postgres:10-alpine

OK, so I executed the drop command and restarted docker stack with new Peertube release:

Here the log:

$ sudo docker-compose up
Creating network "peertube_default" with the default driver
Pulling peertube (chocobozzz/peertube:production-buster)...
production-buster: Pulling from chocobozzz/peertube
41fb1554a069: Pull complete
b0c9c4030d8b: Pull complete
bfe0c3c756be: Pull complete
79e08c4992ce: Pull complete
Digest: sha256:565851694a05ed71d17b8cc0dbeb6a3c76a3b6a195e2b9a1bfa96dc9c4d42ecd
Status: Downloaded newer image for chocobozzz/peertube:production-buster
Attaching to peertube_postgres_1, peertube_redis_1, peertube_postfix_1, peertube_peertube_1
postfix_1   | DNS records:
postgres_1  | 
postgres_1  | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1  | 
redis_1     | 1:C 25 Mar 2021 13:02:22.591 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis.conf
postgres_1  | 2021-03-25 13:02:21.445 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
postgres_1  | 2021-03-25 13:02:21.445 UTC [1] LOG:  listening on IPv6 address "::", port 5432
postfix_1   |     "T8XSVQqjABBANUu/Hl0DFDr02Rh87Z1vetQmTSFiei+PgrsrYXKqIo8Ink3LSj1xU9qoEHA190sIJGKk1SpoEzme/5pwsxeXTvXxnLbLz4T1L9nuh2hf8uVQXcKpIdm9qv+ps1CwIDAQAB" )  ; ----- DKIM key peertube for DOMAIN>
redis_1     | 1:M 25 Mar 2021 13:02:22.592 * monotonic clock: POSIX clock_gettime
redis_1     | 1:M 25 Mar 2021 13:02:22.593 * Running mode=standalone, port=6379.
postgres_1  | 2021-03-25 13:02:21.662 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postfix_1   | Starting OpenDKIM: opendkim.
postgres_1  | 2021-03-25 13:02:22.096 UTC [20] LOG:  database system was shut down at 2021-03-25 13:00:03 UTC
redis_1     | 1:M 25 Mar 2021 13:02:22.593 # Server initialized
redis_1     | 1:M 25 Mar 2021 13:02:22.594 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
postgres_1  | 2021-03-25 13:02:23.093 UTC [1] LOG:  database system is ready to accept connections
redis_1     | 1:M 25 Mar 2021 13:02:22.622 * Loading RDB produced by version 6.2.1
redis_1     | 1:M 25 Mar 2021 13:02:22.622 * RDB age 141 seconds
redis_1     | 1:M 25 Mar 2021 13:02:22.622 * RDB memory usage when created 14.42 Mb
postfix_1   | Starting Postfix Mail Transport Agent: postfix.
redis_1     | 1:M 25 Mar 2021 13:02:24.148 * DB loaded from disk: 1.554 seconds
redis_1     | 1:M 25 Mar 2021 13:02:24.148 * Ready to accept connections
postfix_1   | rsyslogd:  [origin software="rsyslogd" swVersion="8.1901.0" x-pid="52" x-info="https://www.rsyslog.com"] start
peertube_1  | 
peertube_1  | > peertube@3.1.0 start /app
peertube_1  | > node dist/server
peertube_1  | 

And, nothing. When I try to reach the URL, I’ve an error from my reverse-proxy: 502 Bad Gateway

Sorry, after a little time, it works !!

peertube_1  |
peertube_1  | > peertube@3.1.0 start /app
peertube_1  | > node dist/server
peertube_1  | 
postgres_1  | 2021-03-25 13:17:54.319 UTC [37] ERROR:  canceling autovacuum task
postgres_1  | 2021-03-25 13:17:54.319 UTC [37] CONTEXT:  automatic vacuum of table "peertube.public.videoFile"
redis_1     | 1:M 25 Mar 2021 13:18:44.158 * 100 changes in 300 seconds. Saving...
redis_1     | 1:M 25 Mar 2021 13:18:44.159 * Background saving started by pid 13
redis_1     | 13:C 25 Mar 2021 13:18:44.496 * DB saved on disk
redis_1     | 13:C 25 Mar 2021 13:18:44.497 * RDB: 0 MB of memory used by copy-on-write
redis_1     | 1:M 25 Mar 2021 13:18:44.560 * Background saving terminated with success

Thank you @LecygneNoir and @Chocobozzz for your help !!!

1 « J'aime »

Great!

On my instance, after the > node dist/server I have information about the upgrade scripts

Begin migrations.
Executing 0585-video-file-names.js migration script.
Executing 0590-trackers.js migration script.
Executing 0595-remote-url.js migration script.

That are missing in yours, I guess it should depends of the verbosity configured in peertube :+1:

For me, it’s not finished yet… 2hours and on the go! :smiley:

Oh yes, I don’t have those lines but should depends on configuration I guess.
Maybe with those lines I should have understood that something was running in background.

Migratin duration might depend on videos hosted by local instance; I don’t have many.

Anyway, it works thanks to you.
Thanks