Ejecuto Discourse en Debian 11 con Docker como un solo contenedor.
Intenté actualizarlo usando ./launcher rebuild app
Falla con este mensaje:
I, [2023-01-04T20:53:09.920876 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
rake aborted!
No encuentro una manera de volver a ponerlo en funcionamiento.
¿Alguna idea?
Veo que el propietario es incorrecto
drwxr-xr-x 15 sshd netdev 4096 Jan 4 21:43 .
drwxr-xr-x 3 root root 4096 Jan 3 2018 ..
drwxr-xr-x 3 1000 www-data 4096 Jan 3 2018 backups
drwxr-xr-x 8 sshd netdev 4096 Feb 2 2021 letsencrypt
drwxr-xr-x 4 sshd netdev 4096 Jan 3 2018 log
drwxr-xr-x 2 systemd-timesync systemd-resolve 4096 Jan 3 2018 postgres_backup
drwx------ 19 systemd-timesync systemd-resolve 4096 Jan 4 21:53 postgres_data
drwx------ 19 sshd netdev 4096 Jan 4 20:49 postgres_data_new
drwxrwsr-x 6 systemd-timesync systemd-resolve 4096 Jan 4 21:53 postgres_run
drwxr-xr-x 2 systemd-resolve kvm 4096 Jan 4 21:53 redis_data
drwxr-xr-x 2 sshd netdev 4096 Jan 22 2021 ssl
drwxr-xr-x 2 sshd netdev 4096 Jan 21 2021 ssl_old
drwxr-xr-x 4 sshd netdev 4096 Jan 3 2018 state
drwxr-xr-x 4 1000 www-data 4096 Jan 4 21:28 tmp
drwxr-xr-x 4 1000 www-data 4096 Jan 5 2018 uploads
Inicio el contenedor usando ./launcher start app. Luego entro al contenedor: ./launcher enter app.
Restauro la propiedad chown -R postgres:postgres /shared/
Después de eso se corrige. Pero cuando reconstruyo la aplicación de nuevo, el propietario vuelve a ser incorrecto…
Este no es el error, será más arriba, necesitaremos ver más del registro.
2023-01-04 20:48:05.355 UTC [41] LOG: iniciando PostgreSQL 13.9 (Debian 13.9-1.pgdg110+1) en x86_64-pc-linux-gnu, compilado por gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-01-04 20:48:05.377 UTC [41] LOG: escuchando en la dirección IPv4 «0.0.0.0», puerto 5432
2023-01-04 20:48:05.377 UTC [41] LOG: escuchando en la dirección IPv6 «::», puerto 5432
2023-01-04 20:48:05.566 UTC [41] LOG: escuchando en el socket Unix «/var/run/postgresql/.s.PGSQL.5432»
2023-01-04 20:48:05.734 UTC [44] LOG: el sistema de bases de datos se cerró a las 2023-01-04 20:46:17 UTC
2023-01-04 20:48:05.878 UTC [41] LOG: el sistema de bases de datos está listo para aceptar conexiones
I, [2023-01-04T20:48:09.779985 #1] INFO -- :
I, [2023-01-04T20:48:09.780390 #1] INFO -- : > su postgres -c 'createdb discourse' || true
2023-01-04 20:48:10.014 UTC [54] postgres@postgres ERROR: la base de datos «discourse» ya existe
2023-01-04 20:48:10.014 UTC [54] postgres@postgres STATEMENT: CREATE DATABASE discourse;
createdb: error: la creación de la base de datos falló: ERROR: la base de datos «discourse» ya existe
I, [2023-01-04T20:48:10.017003 #1] INFO -- :
I, [2023-01-04T20:48:10.017425 #1] INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
2023-01-04 20:48:10.188 UTC [58] postgres@discourse ERROR: el rol «discourse» ya existe
2023-01-04 20:48:10.188 UTC [58] postgres@discourse STATEMENT: create user discourse;
ERROR: el rol «discourse» ya existe
129:M 04 Jan 2023 20:48:21.224 # Falló la escucha en el puerto 6379 (TCP), abortando.
No veo otros errores.
Dentro del contenedor intento iniciar el servicio postgresql y obtengo un error.
root@server /var/discourse # ./launcher enter app
Se detecta la arquitectura x86_64.
root@discourse:/var/www/discourse# service postgresql start
[FAIL] Iniciando el servidor de base de datos PostgreSQL 13: main[....] Error: El propietario de la configuración (postgres:105) y el propietario de los datos (systemd-timesync:101) no coinciden, y el propietario de la configuración no es root ... ¡falló!
falló!
root@discourse:/var/www/discourse#
Si ha cambiado los propietarios de los archivos dentro de la carpeta compartida, romperá la instalación. Una opción es reinstalar y restaurar una copia de seguridad, mientras que la otra es arreglar manualmente esos propietarios.
@Falco: ¡gracias!
Cambié los propietarios después de que fallara la actualización. Encontré la pista de chown en alguna parte de una publicación.
¿Cómo puedo crear una copia de seguridad en el estado actual?
¿Cómo puedo arreglar los propietarios manualmente?
¡Gracias de nuevo!
Dentro del contenedor intenté discourse backup. Informa que Redis no se está ejecutando. En el registro de Redis “actual” encontré las siguientes líneas al final…
10316:M 05 Jan 2023 08:05:27.314 # Servidor inicializado
10316:M 05 Jan 2023 08:05:27.314 # ADVERTENCIA: overcommit_memory está configurado en 0. El guardado en segundo plano puede fallar en condiciones de poca memoria. Para solucionar este problema, agregue 'vm.overcommit_memory = 1' a /etc/sysctl.conf y luego reinicie o ejecute el comando 'sysctl vm.overcommit_memory=1' para que esto tenga efecto.
10316:M 05 Jan 2023 08:05:27.314 # No se puede manejar la versión 10 del formato RDB
10316:M 05 Jan 2023 08:05:27.314 # Error fatal al cargar la base de datos: Argumento no válido. Saliendo.
10321:C 05 Jan 2023 08:05:28.345 # oO0OoO0OoO0Oo Redis se está iniciando oO0OoO0OoO0Oo
10321:C 05 Jan 2023 08:05:28.345 # Versión de Redis=6.2.3, bits=64, commit=00000000, modificado=0, pid=10321, recién iniciado
10321:C 05 Jan 2023 08:05:28.345 # Configuración cargada
10321:M 05 Jan 2023 08:05:28.346 * reloj monotónico: POSIX clock_gettime
10321:M 05 Jan 2023 08:05:28.347 * Modo de ejecución=standalone, puerto=6379.
10321:M 05 Jan 2023 08:05:28.347 # ADVERTENCIA: La configuración del backlog TCP de 511 no se puede aplicar porque /proc/sys/net/core/somaxconn está configurado en el valor inferior de 128.
10321:M 05 Jan 2023 08:05:28.347 # Servidor inicializado
10321:M 05 Jan 2023 08:05:28.347 # ADVERTENCIA: overcommit_memory está configurado en 0. El guardado en segundo plano puede fallar en condiciones de poca memoria. Para solucionar este problema, agregue 'vm.overcommit_memory = 1' a /etc/sysctl.conf y luego reinicie o ejecute el comando 'sysctl vm.overcommit_memory=1' para que esto tenga efecto.
10321:M 05 Jan 2023 08:05:28.348 # No se puede manejar la versión 10 del formato RDB
10321:M 05 Jan 2023 08:05:28.348 # Error fatal al cargar la base de datos: Argumento no válido. Saliendo.
Arreglé los permisos de esta manera (dentro del contenedor):
Después reinicié el contenedor con ./launcher restart app. Ahora puedo acceder a Discourse. Pero es la versión antigua 2.8.3 a la que intenté actualizar a 3.0.0.beta16 ayer.
No estoy seguro de cómo proceder para actualizar Discourse.
Creo que mi problema está relacionado con este hilo: Problem upgrading multi-site/multi-containers Discourse instance - #5 by jtraulle
Recuerdo que tuve problemas de actualización antes, pero nunca los investigué.
./launcher rebuild app
Pude establecer la versión en 2.9.0.beta2 (id de commit: 88a8584348ed93a28286839bfc1c32b06bd50b3f) estableciendo el id de commit como “version” en app.yml. Esta vez la actualización funcionó. Después de eso, pude actualizar a 3.0.0.beta16.
Gracias a todos.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.