Hola, tengo dos grandes problemas al detener y volver a iniciar Discourse.
Primero
Después de 2 o 3 veces que lo hago (no importa si es con ./launcher stop o deteniéndolo desde Portainer), el contenedor se niega a iniciar nuevamente y queda continuamente bloqueado en “rm: cannot remove ‘/shared/nginx.http.sock’: Is a directory”. (Acabo de notar que el socket no está en el directorio “shared”, sino en “shared/standalone”, ¿es solo un error en el mensaje?)
Por alguna razón aún desconocida para mí, este socket, quizás después de detenerlo, se convierte en un directorio, y la plantilla no puede eliminarlo porque intenta eliminar un directorio en lugar de un socket. Eliminarlo manualmente no cambia nada; reaparece cada vez.
Segundo ./launcher rebuild app se queda bloqueado en “FATAL: the database system is starting up”, después del primer mensaje “PANIC could not locate a valid checkpoint record”. He leído y probado todo lo que encontré sobre este problema, y la única “solución” que funciona que encontré fue eliminar el directorio de Discourse con todo su contenido y configurar todo de nuevo… obviamente, ¡no es una solución real!
Parece que a veces detener el contenedor de Discourse deja la base de datos en mal estado, y no puede continuar porque “está iniciándose”, quizás intentando corregir algo. Pero aún no he encontrado cómo solucionar este problema, que parece surgir después de algunos ciclos de detener e iniciar.
¿Alguna pista? ¿Algún método para dejar que Postgres solucione sus problemas?
No, no es un error. Este archivo está en el volumen que se monta en el contenedor, por lo que tiene rutas diferentes según el punto de vista, es decir, dentro del contenedor frente a fuera del contenedor.
Esto ocurre cuando el contenedor no se detiene correctamente. PostgreSQL necesita tiempo para apagarse adecuadamente, y nosotros lo hacemos cuando detienes el contenedor con nuestro comando del lanzador. Sin embargo, si tu instancia es lo suficientemente grande o hay demasiadas transacciones en ejecución, la base de datos podría tener dificultades para detenerse correctamente dentro del plazo que recibe.
Pero también encuentro que este “nginx.http.sock” se crea en “shared/standalone” en el sistema de archivos del host. Inicialmente es de color rosa, como un socket, pero después de un tiempo, quizás tras una parada, se vuelve azul, como un directorio, y el contenedor se niega a iniciar, atascado al intentar eliminar un socket… que se ha convertido en un directorio.
Entonces, ¿qué podemos hacer para solucionarlo? Hasta ahora solo estoy experimentando, pero si voy en línea con algunas cientos de personas conectadas y cientos de miles de publicaciones, ¿correré el riesgo de perderlo todo solo porque PostgreSQL no maneja bien una interrupción abrupta? Habrá que hacer algo para reparar una base de datos dañada. ¿Puede Discourse ejecutarse con una base de datos PostgreSQL externa, algo que podamos gestionar si el contenedor de Discourse no inicia? En resumen, en caso de “PANIC” o “FATAL”, debería haber alguna solución…
En realidad, estoy intentando resolver el problema (para el futuro) configurando un Postgres “contenerizado” y adjuntándolo a Discourse, con la esperanza de no dañar la base de datos (o al menos poder realizar algún mantenimiento incluso con Discourse detenido) al detener Discourse.