Potresti essere a corto di RAM e il killer OOM potrebbe terminare alcuni processi casuali, come sshd, disconnettendoti e causando problemi?
Se il killer OOM è attivo, dovresti trovare qualcosa nell’output di dmesg, in /var/log/messages o nell’output di journalctl.
Dubito che il problema sia la mancanza di RAM; è più probabile che io stia testardamente usando la console PuTTY invece della console DO.
Quindi, passerò al suggerimento di @pfaffman sopra, tanto più che ho scoperto che la console PuTTY si disconnette anche quando la sto usando per qualcosa di completamente diverso dalla gestione di Discourse.
Potrebbe essere la RAM. Hai lo swap?
Hai provato a regolare l’impostazione keep alive, come in questo esempio?
@pfaffman Non ho specificato nulla: ho utilizzato tutte le impostazioni predefinite per i droplet, affidandomi al team di DO per garantire un comportamento ragionevole.
Per prima cosa, proverò a impostare keep-alive come suggerito da @omarfilip sopra, poi esaminerò la situazione dello swap space, seguito dal suggerimento di @pfaffman di utilizzare la console originale di DO (se l’impostazione keep-alive mi permetterà di continuare a usare la console PuTTY, la userò poiché è molto più user-friendly rispetto all’equivalente di DO.
Avendo così tante persone amichevoli che mi aiutano, desidero ribadire le mie ragioni per cercare di mettere insieme Ghost e Discourse: a mio avviso, è lo strumento ideale per chi desidera scrivere documentazione tecnica e offrire il miglior supporto per discuterne. Il mio piano è affrontare l’Identity and Account Management (IAM) utilizzando diversi interessanti provider PaaS per l’IAM; questo argomento non è documentato in modo sufficiente (almeno a mio parere, basandomi su anni di utilizzo di tali servizi).
Al fine di effettuare un “beta test” del mio strumento integrato Ghost/Discourse, ho deciso di descrivere tutti i dettagli del processo di creazione e test di questo strumento. Pertanto, tutte le persone che mi stanno aiutando dovrebbero sapere che questo sforzo è inteso a supportare le community di Discourse, Ghost e Digital Ocean.
Se hai utilizzato l’installazione in un clic di Digital Ocean e non l’installazione standard ufficiale di Discourse, è probabile che non abbia configurato lo swap; quindi, quando esegui una ricostruzione, la memoria RAM si esaurisce a meno che tu non abbia > 2 GB.
Puoi provare a eseguire
cd /var/discourse
./discourse-setup
e creerà lo swap per te se necessario.
Se desideri assistenza con l’installazione in un clic di Digital Ocean e vuoi “affidarti al team di DO per garantire un comportamento ragionevole”, dovresti affidarti a loro per il supporto.
Ma dato che sto già scrivendo, un modo più semplice per confermare che il problema non sia PuTTY (il che potrebbe farti risparmiare molto tempo a modificare inutilmente i parametri di PuTTY) è provare la console. Se non hai ancora eseguito discourse-setup, sono quasi certo che il problema sia lo spazio swap.
@pfaffman Ho seguito alla lettera il processo ufficiale di installazione di Discourse, incluso l’uso di PuTTY menzionato in quel documento ufficiale.
È possibile che tu abbia dedotto che ho utilizzato l’installazione one-click di Digital Ocean e che pensi che dovrei affidarmi a DO:
Se vuoi aiuto con l’installazione one-click di Digital Ocean e desideri “affidarti al team di DO per garantire un comportamento ragionevole”, allora dovresti affidarti a loro per il supporto.
Il mio riferimento all’installazione one-click deriva dalla recente email di Discourse:
Evviva, è disponibile una nuova versione di Discourse!
La tua versione: 2.7.0.beta1
Nuova versione: 2.7.0.beta2
- Aggiorna facilmente tramite il nostro aggiornamento one-click dal browser
Quindi, la situazione attuale è la seguente:
, sapendo che guadagni aiutando le persone con Discourse. Nonostante io non sembri un potenziale cliente, hai dedicato tempo a tirarmi fuori dai guai../launcher rebuild app.Molte grazie a tutti coloro che hanno fornito parti della soluzione.
Oh! Mea culpa! Mi scuso sinceramente!
Allora hai davvero lo swap e la mia ipotesi era sbagliata. Che peccato, perché sarebbe stato un rimedio semplice. 
È un sollievo dopo avervi accusato ingiustamente!
È terribile scoprire che Putty sia così scadente. Non capisco come continui a essere il client SSH consigliato per Windows.
Credo che ora esista un client che fa parte di quella cosa del sottosistema Linux, ma la versione di Windows che usavo regolarmente era Windows 98.
Sono contento che tu abbia risolto!
Tutti i moderni sistemi operativi includono client SSH nativamente, quindi non c’è bisogno di client di terze parti. Anche su Windows Terminal posso semplicemente digitare SSH. Dovrebbe funzionare, a condizione che Windows sia aggiornato.
Oddio. Davvero? L’ultima volta che (credevo di) aver controllato, richiedeva un’installazione che sembrava complicata.
E può usare una normale chiave SSH e non quella roba assurda del PEM?
Questa lunga storia ha un lieto fine e potrebbe essere definita un ‘tempesta in un bicchiere d’acqua’. Ho imparato molto su Discourse e, di conseguenza, ho intenzione di rimanere qui per un tempo indeterminato. Ecco la descrizione dettagliata del lieto fine:
Il mio problema nell’aggiornare da Beta1 a Beta2 si manifestava con il timeout della console PuTTY. L’ho interpretato come un enorme crash nel processo di aggiornamento di Discourse e ho dedicato molto tempo a studiare gli “interni” di Discourse: una tana del bianconiglio che sono felice di aver esplorato inutilmente.
La soluzione al mio problema è estremamente semplice (una volta che si sa dove “spingere”) - semplice come 1, 2, 3 qui sotto:
@Falco ci ha “aperto gli occhi” collettivi suggerendo di utilizzare semplicemente OpenSSH integrato in Windows 10 (grazie a Scott Hanselman).
Dato che avevo già promesso a @codinghorror di scrivere il miglior documento possibile per presentare Discourse al mondo, come ringraziamento per il suo aiuto (e quello del suo team) nel farmi capire Discourse, @pfaffman mi ha permesso di includere il suggerimento di @Falco come prima parte del mio documento.
Consiglio di utilizzare tmux, in questo modo puoi riconnetterti alla sessione in esecuzione per la ricostruzione anche se il tuo client va in timeout.
@md-misko grazie per il consiglio:
La cosa fantastica di tmux è che ti permette di avere più pannelli aperti contemporaneamente, ognuno con la propria shell in esecuzione, ma utilizzando un’unica connessione SSH. Inoltre, puoi anche avere più “finestre” aperte contemporaneamente, un po’ come le schede con più pannelli al loro interno
Ciao @sunjam, sembra che il problema possa essere risolto con la nuova versione del gem omniauth-vkontakte 1.7.0.
Ho creato una pull request per il maintainer del plugin. Come soluzione temporanea, puoi cambiare il link di GitHub nel tuo app.yml in
- git clone https://github.com/rapekas/discourse-vk-auth
e ricostruire.