ArgumentError: directory per pid=/.../unicorn.pid non scrivibile

Sto cercando di configurare Discourse su un server. L’ho già fatto alcune volte, poiché sto testando uno script per correggere vari aspetti degli archivi mbox di 18 anni di attività di mailing list prima di importarli in Discourse. Ha funzionato le volte precedenti.

Tornando a questo dopo aver messo in pausa il lavoro per un po’, ho eseguito ./discourse-setup e ho ricevuto errori da Let’s Encrypt a causa del superamento dei limiti di frequenza (poiché ho fatto molti tentativi in precedenza). Per aggirare il problema, ho modificato containers/app.yml per rimuovere i due template di Let’s Encrypt (non ho bisogno di HTTPS per i miei test) e ho eseguito ./launcher rebuild app.

Sfortunatamente, ora ricevo “502 Bad gateway – nginx” quando accedo al sito. L’output di ./launcher logs app contiene una serie di questi errori:

/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)

            raise ArgumentError, "directory for #{var}=#{path} not writable"
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
    from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (90) - No such process
config/unicorn_launcher: line 15: kill: (90) - No such process
(80) exiting

Dato che ha funzionato in passato, questo potrebbe avere diverse cause:

  • Una modifica recente in Discourse.
  • Il fatto che non sto usando Let’s Encrypt.
  • Il fatto che ho anche modificato le impostazioni email (dubito che questo sia rilevante, però).

Qualsiasi aiuto? Grazie.

Usa un sottodominio diverso. Non credo che discourse funzionerà più su http.

:frowning:

Se questo è previsto, non dovrebbe essere rimossa l’opzione per saltare SSL? Voglio dire, nessuna opzione di configurazione è meglio di un’opzione di configurazione che non funziona…

No. Potresti eseguire un proxy esterno che gestisce i certificati.

Quell’errore di scrittura è strano, però. Sembra un problema diverso dalla questione del certificato.

Il tuo disco non è pieno, vero?

No, non lo è.

root@ubuntu:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           193M  1.1M  192M   1% /run
/dev/vda1        78G   11G   67G  14% /
tmpfs           965M     0  965M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/vda15      105M  6.1M   99M   6% /boot/efi
overlay          78G   11G   67G  14% /var/lib/docker/overlay2/fa186c119fd0bc36dfbec9d7541b325bc8b099ff7aae53661aa992c66fb61c95/merged
tmpfs           193M  4.0K  193M   1% /run/user/0
1 Mi Piace

Ho scoperto che potrei usare la struttura di test di Let’s Encrypt, cosa che ho fatto usando questo diff:

diff --git a/templates/web.letsencrypt.ssl.template.yml b/templates/web.letsencrypt.ssl.template.yml
index ba5f551..17e5614 100644
--- a/templates/web.letsencrypt.ssl.template.yml
+++ b/templates/web.letsencrypt.ssl.template.yml
@@ -16,7 +16,7 @@
          - install -d -m 0755 -g root -o root $LETSENCRYPT_DIR
          - cd /root/acme.sh && LE_WORKING_DIR="${LETSENCRYPT_DIR}" ./acme.sh --install --log "${LETSENCRYPT_DIR}/acme.sh.log"
          - cd /root/acme.sh && LE_WORKING_DIR="${LETSENCRYPT_DIR}" ./acme.sh --upgrade --auto-upgrade
-         - cd /root/acme.sh && LE_WORKING_DIR="${LETSENCRYPT_DIR}" ./acme.sh --set-default-ca  --server  letsencrypt
+         - cd /root/acme.sh && LE_WORKING_DIR="${LETSENCRYPT_DIR}" ./acme.sh --set-default-ca  --server  letsencrypt_test

     - file:
        path: "/etc/nginx/letsencrypt.conf"

Ora, la certificazione sembra OK, ma l’errore è ancora presente, suggerendo che sia effettivamente irrilevante.

[Mon 14 Aug 2023 10:55:24 AM UTC] Your cert is in: /shared/letsencrypt/lilypond.community_ecc/lilypond.community.cer
[Mon 14 Aug 2023 10:55:24 AM UTC] Your cert key is in: /shared/letsencrypt/lilypond.community_ecc/lilypond.community.key
[Mon 14 Aug 2023 10:55:24 AM UTC] The intermediate CA cert is in: /shared/letsencrypt/lilypond.community_ecc/ca.cer
[Mon 14 Aug 2023 10:55:24 AM UTC] And the full chain certs is there: /shared/letsencrypt/lilypond.community_ecc/fullchain.cer
[Mon 14 Aug 2023 10:55:25 AM UTC] Installing key to: /shared/ssl/lilypond.community_ecc.key
[Mon 14 Aug 2023 10:55:25 AM UTC] Installing full chain to: /shared/ssl/lilypond.community_ecc.cer
[Mon 14 Aug 2023 10:55:25 AM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Mon 14 Aug 2023 10:55:25 AM UTC] Reload error for :
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
error 2 at 1 depth lookup: unable to get issuer certificate
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Ersatz Edamame E1
error 2 at 1 depth lookup: unable to get issuer certificate
Started runsvdir, PID is 6029
ok: run: redis: (pid 6040) 0s
ok: run: postgres: (pid 6041) 0s
supervisor pid: 6039 unicorn pid: 6062
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)

            raise ArgumentError, "directory for #{var}=#{path} not writable"
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (6062) - No such process
config/unicorn_launcher: line 15: kill: (6062) - No such process
(6039) exiting

Non sono sicuro di cosa fare dopo.

Solo per verificare, ora che la mia limitazione di quota Let’s Encrypt è scaduta, ho provato senza applicare la patch sopra. Questo è quello che ho ottenuto:

[Lun 14 ago 2023 19:57:34 UTC] Il tuo certificato si trova in: /shared/letsencrypt/lilypond.community_ecc/lilypond.community.cer
[Lun 14 ago 2023 19:57:34 UTC] La tua chiave certificato si trova in: /shared/letsencrypt/lilypond.community_ecc/lilypond.community.key
[Lun 14 ago 2023 19:57:34 UTC] Il certificato CA intermedio si trova in: /shared/letsencrypt/lilypond.community_ecc/ca.cer
[Lun 14 ago 2023 19:57:34 UTC] E i certificati della catena completa sono qui: /shared/letsencrypt/lilypond.community_ecc/fullchain.cer
[Lun 14 ago 2023 19:57:34 UTC] Installazione della chiave in: /shared/ssl/lilypond.community_ecc.key
[Lun 14 ago 2023 19:57:34 UTC] Installazione della catena completa in: /shared/ssl/lilypond.community_ecc.cer
[Lun 14 ago 2023 19:57:34 UTC] Esecuzione del comando di ricaricamento: sv reload nginx
warning: nginx: impossibile aprire supervise/ok: file non esiste
[Lun 14 ago 2023 19:57:34 UTC] Errore di ricaricamento per:
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
errore 2 in ricerca di 1 profondità: impossibile ottenere il certificato dell'emittente
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Ersatz Edamame E1
errore 2 in ricerca di 1 profondità: impossibile ottenere il certificato dell'emittente
Avviato runsvdir, PID è 6029
ok: run: redis: (pid 6038) 0s
ok: run: postgres: (pid 6041) 0s
supervisor pid: 6042 unicorn pid: 6062
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)

            raise ArgumentError, "directory for #{var}=#{path} not writable"
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (6062) - No such process
config/unicorn_launcher: line 15: kill: (6062) - No such process
(6042) exiting
ok: run: redis: (pid 6038) 1s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 9s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 17s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 24s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 32s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 39s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 47s
ok: run: postgres: (pid 6134) 0s
supervisor pid: 6126 unicorn pid: 6136
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)

            raise ArgumentError, "directory for #{var}=#{path} not writable"
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (6136) - No such process
config/unicorn_launcher: line 15: kill: (6136) - No such process
(6126) exiting
ok: run: redis: (pid 6038) 54s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 62s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 69s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 77s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 84s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 92s
ok: run: postgres: (pid 6193) 0s
supervisor pid: 6190 unicorn pid: 6195
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)

            raise ArgumentError, "directory for #{var}=#{path} not writable"
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
	from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (6195) - No such process
config/unicorn_launcher: line 15: kill: (6195) - No such process
(6190) exiting
ok: run: redis: (pid 6038) 94s

Sembra un problema di permessi della cartella. È piuttosto strano, dato che quella cartella si trova all’interno del filesystem del container e non è montata dall’host.

Puoi provare a entrare nel container in esecuzione e modificare manualmente i permessi della cartella. Se hai bisogno di aiuto, potresti condividere l’output di

docker exec -it app ls -lah /var/www/discourse/tmp/pids
2 Mi Piace
docker exec -it app chown discourse.www-data /var/www/discourse/tmp/pids
docker exec -it app chmod g+w /var/www/discourse/tmp/pids
./launcher rebuild app

Sto installando da zero ancora una volta e sto cercando di prestare maggiore attenzione ai messaggi di log della build dell’app questa volta.

Vedo questi:

153:C 16 Aug 2023 20:24:11.676 # oO0OoO0OoO0Oo Redis si sta avviando oO0OoO0OoO0Oo
153:C 16 Aug 2023 20:24:11.676 # Versione Redis=7.0.7, bit=64, commit=00000000, modificato=0, pid=153, appena avviato
153:C 16 Aug 2023 20:24:11.676 # Caricati i settaggi
153:M 16 Aug 2023 20:24:11.677 * orologio monotono: POSIX clock_gettime
153:M 16 Aug 2023 20:24:11.677 # Avviso: Impossibile creare il socket TCP del server *:6379: bind: Indirizzo già in uso
153:M 16 Aug 2023 20:24:11.678 # Impossibile ascoltare sulla porta 6379 (TCP), interruzione.

Anche questo:

I, [2023-08-16T20:24:26.172936 #1]  INFO -- : cd /var/www/discourse && su discourse -c 'yarn install --frozen-lockfile && yarn cache clean'
warning " > @glint/environment-ember-loose@1.0.2" has unmet peer dependency "@glimmer/component@^1.1.2".
warning " > @glint/environment-ember-template-imports@1.0.2" has unmet peer dependency "ember-template-imports@^3.0.0".
warning " > @mixer/parallel-prettier@2.0.3" has unmet peer dependency "prettier@^2.0.0".
warning Resolution field "babel-plugin-ember-template-compilation@2.0.0" is incompatible with requested version "babel-plugin-ember-template-compilation@^2.0.1"
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
warning " > babel-plugin-debug-macros@0.4.0-pre1" has unmet peer dependency "@babel/core@^7.0.0".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3@3.0.6" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3-multipart@3.1.3" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/xhr-upload@3.1.1" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0" has incorrect peer dependency "@uppy/core@^3.2.1".

(Proverò le modifiche manuali ai permessi quando finirà la compilazione.)

Prima di chown e chmod:

root@ubuntu-app:/var/www/discourse# ls -lah /var/www/discourse/tmp/pids
total 8.0K
drwxr-xr-x 2 root root 4.0K Aug 16 20:47 .
drwxr-xr-x 6 root root 4.0K Aug 16 20:53 ..

Dopo:

root@ubuntu-app:/var/www/discourse# ls -lah /var/www/discourse/tmp/pids
total 16K
drwxrwxr-x 1 discourse www-data 4.0K Aug 16 20:58 .
drwxr-xr-x 1 root      root     4.0K Aug 16 20:53 ..
-rw-r--r-- 1 discourse www-data    5 Aug 16 20:58 unicorn.pid

Ora la coda di ./launcher logs app appare così:

ok: run: redis: (pid 5790) 184s
ok: run: postgres: (pid 6154) 0s
supervisor pid: 6155 unicorn pid: 6159
config/unicorn_launcher: line 71: kill: (6159) - No such process
config/unicorn_launcher: line 15: kill: (6159) - No such process
(6155) exiting
ok: run: redis: (pid 5790) 188s
ok: run: postgres: (pid 6176) 0s
supervisor pid: 6177 unicorn pid: 6181
config/unicorn_launcher: line 71: kill: (6181) - No such process
config/unicorn_launcher: line 15: kill: (6181) - No such process
(6177) exiting
ok: run: redis: (pid 5790) 192s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 5790) 200s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 5790) 208s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 5790) 215s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 5790) 223s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 5790) 230s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 5790) 238s
ok: run: postgres: (pid 6264) 0s
supervisor pid: 6260 unicorn pid: 6266
config/unicorn_launcher: line 71: kill: (6266) - No such process
config/unicorn_launcher: line 15: kill: (6266) - No such process
(6260) exiting
ok: run: redis: (pid 5790) 244s
ok: run: postgres: (pid 6283) 0s
supervisor pid: 6284 unicorn pid: 6288

Il mio browser segnala un problema HTTPS con il sito e, quando scelgo l’opzione “pericolosa” per bypassare, ottengo la pagina “bad gateway” di nginx.

Sto riscontrando lo stesso problema con l’attuale git.

Ricostruire il container dopo chown e chmod annullerà i loro effetti.

Sto riscontrando lo stesso problema. L’ultima volta che Discourse si è bloccato è stato a causa di un problema non rilevato con i plugin. Sto utilizzando questi:

          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/tfpk/discourse-reveal-anonymous.git
          - git clone https://github.com/discourse/discourse-push-notifications.git
          - git clone https://github.com/discourse/discourse-data-explorer.git
          - git clone https://github.com/discourse/discourse-solved.git
          - git clone https://github.com/discourse/discourse-math.git

Possiamo confrontare le note? Ci sono problemi noti in questo momento con questi plugin?

Ecco altre informazioni. Nello stderr di gunicorn, vedo:

/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.7/lib/active_record/connection_adapters/postgresql_adapter.rb:87:in `rescue in new_client': connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: No such file or directory (ActiveRecord::ConnectionNotEstablished)
	Is the server running locally and accepting connections on that socket?

Nel log di PG, vedo:

2023-08-21 19:24:00.721 UTC [1681] LOG:  listening on Unix socket \"/var/run/postgresql/.s.PGSQL.5432\"
2023-08-21 19:24:00.728 UTC [1681] LOG:  could not open configuration file \"/etc/postgresql/13/main/pg_hba.conf\": Permission denied
2023-08-21 19:24:00.728 UTC [1681] FATAL:  could not load pg_hba.conf
2023-08-21 19:24:00.741 UTC [1681] LOG:  database system is shut down

inoltre:

# ls -l /etc/postgresql/13/main/pg_hba.conf
-rw-r----- 1 root root 4846 Aug 21 19:05 /etc/postgresql/13/main/pg_hba.conf

Sotto quale utente viene eseguito postgres all’interno del container? Con i permessi sopra indicati, deve essere root o qualcuno nel gruppo root.

Ok, ho eseguito chmod o+r /etc/postgresql/13/main/pg_hba.conf e ora il container è di nuovo attivo.

Tutto questo è un po’ preoccupante: perché il metodo di installazione consigliato non funziona subito? Lo stato dei miei plugin include attualmente quelli elencati sopra, ad eccezione di data explorer che ho disabilitato poiché aveva causato il fallimento l’ultima volta.

Cross-linking a

che riporta sintomi simili.

Aggiornamento: ho modificato il comando git nella sezione cmd del file app.yml per utilizzare sudo come descritto nel post collegato.

Dichiaro che questo fallimento è intermittente. In 3 tentativi (tra ogni tentativo ho completamente cancellato la directory shared) è riuscito una volta e fallito due volte. Quando fallisce, la correzione manuale dei tre permessi in questione e il successivo riavvio del container hanno portato a quello che sembra essere un sistema funzionante. Sarebbero utili un logging migliore e test automatici più efficaci per rilevare i fallimenti nell’avvio dei container.

Modificare i permessi su /var/www/discourse/tmp/pids e /etc/postgre/13/main/pg_hba.conf non funziona per me.

Avevo modificato la mia lista di plugin prima della ricostruzione, ma anche dopo aver ripristinato la lista dei plugin ottengo lo stesso ArgumentError. Siamo sicuri che sia la lista dei plugin a causarlo?

Dopo aver avviato il container vedo file scritti nella directory pids. Il mio log del launcher si interrompe dopo questo

ok: down: unicorn: 0s, normally up
run-parts: executing /etc/runit/3.d/10-redis
ok: down: redis: 0s, normally up
run-parts: executing /etc/runit/3.d/99-postgres
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 35
ok: run: redis: (pid 52) 0s
ok: run: postgres: (pid 55) 0s
supervisor pid: 42 unicorn pid: 75

C’è qualcos’altro che posso controllare?

Ho lo stesso problema descritto in questo thread. Ho provato a installare Discourse oggi su un nuovo server, ma non ci sono riuscito a causa della mancanza dei permessi di scrittura.

La “correzione” con chown/chmod non funziona per me, i permessi vengono reimpostati di nuovo su ./launcher rebuild app

Quindi sei riuscito a riprodurlo su un’installazione completamente nuova? Queste sono informazioni molto utili, poiché non riesco a riprodurlo aggiornando una esistente.

Sì, ho provato a installare discourse seguendo la guida e ho pensato di essere impazzito, dato che tutto “sembrava” funzionare ma ottengo solo un errore “502”.

Ho provato a cambiare i permessi all’interno del container senza ricostruire. Ora ottengo questo:

ok: run: redis: (pid 50) 4677s
ok: run: postgres: (pid 12224) 0s
supervisor pid: 12215 unicorn pid: 12226
config/unicorn_launcher: line 71: kill: (12226) - No such process
config/unicorn_launcher: line 15: kill: (12226) - No such process
(12215) exiting
ok: run: redis: (pid 50) 4686s
ok: run: postgres: (pid 12249) 0s
supervisor pid: 12240 unicorn pid: 12251
config/unicorn_launcher: line 71: kill: (12251) - No such process
config/unicorn_launcher: line 15: kill: (12251) - No such process
(12240) exiting
ok: run: redis: (pid 50) 4695s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 50) 4703s
ok: run: postgres: (pid 12279) 0s
supervisor pid: 12275 unicorn pid: 12281

Ho un secondo server, configurato esattamente come questo, in funzione da oltre un anno. Quello funziona, fermare il container, fare un git pull, ricostruire e avviare ha funzionato anche lì.

1 Mi Piace

Aggiungo questo come punto dati poiché non lo vedo in questo argomento.

Vedi un messaggio fatal: detected dubious ownership... nel log di unicorn? Sto ricevendo questo messaggio.

Aggiungere /var/www/discourse come safe.directory a gitconfig non ha alcun effetto per la mia installazione.

Quindi ho appena ottenuto un nuovo droplet con Ubuntu 22.04, ho eseguito la guida di installazione e ha funzionato correttamente. Non riesco a riprodurre questo problema né in un’installazione vecchia né in una nuova.

Quale distro stavi usando?

Niente di simile in un’installazione nuova di zecca:

root@test-install:/var/discourse# cat /var/discourse/shared/standalone/log/rails/unicorn.std*
I, [2023-08-22T17:16:33.594602 #2982]  INFO -- : Refreshing Gem list
I, [2023-08-22T17:16:38.624384 #2982]  INFO -- : listening on addr=127.0.0.1:3000 fd=10
I, [2023-08-22T17:16:43.003213 #2982]  INFO -- : starting 1 supervised sidekiqs
I, [2023-08-22T17:16:47.070059 #2982]  INFO -- : master process ready
I, [2023-08-22T17:16:50.490722 #3068]  INFO -- : worker=0 ready
I, [2023-08-22T17:16:52.394685 #3077]  INFO -- : worker=1 ready
I, [2023-08-22T17:16:53.139229 #3085]  INFO -- : worker=2 ready
I, [2023-08-22T17:16:53.518292 #3097]  INFO -- : worker=3 ready
Loading Sidekiq in process id 3059
2 Mi Piace