メモリ(RAM)が不足し、OOMキラーがsshdなどのランダムなプロセスを終了させて、接続が切れたり問題が発生したりしている可能性があります。
OOMキラーが作動している場合、dmesgの出力、/var/log/messages、またはjournalctlの出力に何らかの記録が残っているはずです。
メモリ(RAM)が不足し、OOMキラーがsshdなどのランダムなプロセスを終了させて、接続が切れたり問題が発生したりしている可能性があります。
OOMキラーが作動している場合、dmesgの出力、/var/log/messages、またはjournalctlの出力に何らかの記録が残っているはずです。
RAM が不足していることが私の問題だとは思えません。むしろ、私が頑なに PuTTY コンソール を使い続け、DO コンソール を使っていないことが原因でしょう。
そこで、@pfaffman さんの 上記の提案 に従って切り替えることにします。特に、PuTTY コンソールは Discourse の管理とは全く関係のない作業をしている最中にも切断されてしまうことが判明したためです。
RAMが原因かもしれません。スワップ領域は設定されていますか?
キープアライブ設定を調整してみられましたか?こちらのような設定です。
@pfaffman 何も指定していません。すべての Droplet のデフォルト設定を使用し、合理的な動作を DO 側で保証してもらうことに依存しています。
まず、@omarfilip が上記で提案した keep-alive を設定してみます。次にスワップ領域の状況を確認し、その後、@pfaffman が提案した DO 標準のコンソールを使用する方法を検討します(keep-alive の設定により PuTTY コンソールの使用を継続できる場合は、DO の同等機能よりもはるかに使いやすい PuTTY コンソールを利用します)。
多くの親切な方々にご支援いただいていることに感謝し、Ghost と Discourse を統合しようとする私の目的を改めて述べさせていただきます。私の考えでは、これは技術文書を作成し、その文書に関する議論に最適なサポートを提供するための理想的なツールです。私の計画では、いくつかの興味深い PaaS 型 IAM プロバイダーを用いて、アイデンティティとアカウント管理(IAM)について取り扱います。このトピックは、少なくとも私が長年これらのサービスを利用してきた経験に基づけば、十分に文書化されているとは言えません。
この Ghost と Discourse を統合したツールを「ベータテスト」するために、ツールの作成とテストの全過程について詳しく説明することにしました。したがって、私を支援してくださる皆様には、この取り組みが Discourse、Ghost、そして Digital Ocean のコミュニティ全体に貢献することを目的としていることをお伝えしておきます。
DigitalOcean の 1 クリックインストールを使用し、Discourse 公式の標準インストールを行っていない場合、スワップが設定されていない可能性が高いです。そのため、2GB 以上のメモリを持っていない限り、再構築時にメモリ不足に陥ります。
以下のコマンドを実行してみてください。
cd /var/discourse
./discourse-setup
必要に応じて、これでスワップが自動的に作成されます。
DigitalOcean の 1 クリックインストールについてサポートを受けたい場合や、「DigitalOcean 側の対応に任せて適切な動作を保証してもらいたい」のであれば、彼らにサポートを依頼すべきです。
ただし、すでに投稿しているついでに、PuTTY の設定が原因ではないことを確認するより簡単な方法として、コンソールを試すことをお勧めします(これにより、PuTTY のパラメータを無駄に調整する時間を節約できます)。もしまだ discourse-setup を実行していないのであれば、問題の原因はスワップ領域にあると確信しています。
@pfaffman 僕は、公式の Discourse インストール手順 https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md に忠実に従って作業を行いました。その公式インストールドキュメントで言及されている PuTTY の使用も含まれます。
あなたが「1 クリックインストールで Digital Ocean(DO)を使った」と推測し、「DO のサポートに依存すべきだ」という見解を持たれた可能性はあります:
もし Digital Ocean の 1 クリックインストールに関するサポートを受けたい、かつ「DO の担当者が適切な動作を保証してくれることに依存したい」のであれば、彼らにサポートを頼むべきです。
僕が「1 クリックインストール」に言及した理由は、Discourse からの最近のメールによるものです:
やったぞ、Discourse の新バージョンが利用可能です!
現在のバージョン:2.7.0.beta1
新しいバージョン:2.7.0.beta2
- 簡単な ブラウザ上の 1 クリックアップグレード でアップグレードしましょう
現状をまとめますと:
./launcher rebuild app コマンドを正常に実行できたことで、2.7.0.2.beta2 へのアップグレードは驚くほど簡単に行えました。解決策の一部を提供してくれた皆さんに心から感謝します。
あら!私の落ち度!本当にごめんなさい!
では、swap は存在しているようで、私の推測は完全に的外れでしたね。残念です。簡単な解決策になるはずだったのに。![]()
誤ってあなたを非難してしまった後の安堵感です!
それに、PuTTY がこんなに酷いとは驚きですね。なぜ今でも Windows 向けの推奨 SSH クライアントとして使われ続けているのか、理解できません。
Linux サブシステムの一部になっているクライアントもあるようですが、私が普段使っていた Windows のバージョンは Windows 98 でした。
問題が解決してよかったですね!
すべての最新のオペレーティングシステムには、標準で SSH クライアントが同梱されています。サードパーティ製クライアントは不要です。Windows Terminal でも、単に「SSH」と入力するだけで使用できます。Windows が最新に更新されていれば、問題なく動作するはずです。
なんてことだ。ほんとうに?私が(思ったように)最後に確認したときは、難しそうなインストールが必要だったのに。
それに、通常の SSH キーが使えるんであって、あの PEM なんていう厄介なものは使わなくていいの?
この長い物語はハッピーエンドで結ばれ、まさに「茶番」のようでした。Discourse について多くを学び、その結果として今後もここに留まるつもりです。以下に、そのハッピーエンドの詳細を箇条書きで記します。
Beta1 から Beta2 へのアップグレードで発生した問題は、PuTTY コンソールがタイムアウトすることとして現れました。私はこれを Discourse のアップグレードタスクの大規模なクラッシュと誤解し、Discourse の「内部」を学ぶことに多くの時間を費やしました。無駄だったとわかっていても、この「ウサギの穴」に飛び込むのはとても楽しかったです。
問題の解決策は(どこを「押す」かさえわかれば)極めてシンプルです。以下に 1、2、3 と示します。
@Falco が「集合知」を働かせ、Windows 10 の組み込み OpenSSH を使うよう指摘してくれたことで目が覚めました(Scott Hanselman 氏に感謝)。
すでに @codinghorror 氏には、Discourse を理解する手助けをしてくれたこと(および彼のチームへの感謝)の謝辞として、世界に向けて Discourse を紹介する最高級のドキュメントを書くことを約束していました。そのため、@pfaffman 氏に依頼し、@Falco 氏の提案を私のドキュメントの第一部分として採用させていただくことになりました。
tmuxの使用をお勧めします。これにより、クライアントがタイムアウトしても、再構築を実行中のセッションに再接続できます。
@md-misko 貴重なご指摘をありがとうございます。
tmux の素晴らしい点は、複数のペインを同時に開き、それぞれが独自のシェルを実行しながら、同じ単一の SSH 接続を共有できることです。さらに、複数の「ウィンドウ」を同時に開くことも可能です。これは、より多くのペインを含むタブのようなものです。
@sunjam さん、こんにちは。この問題は、gem の新バージョン「omniauth-vkontakte 1.7.0」で解決できるようです。
プラグインのメンテナに対してプルリクエストを作成しました。一時的な回避策として、app.yml 内の GitHub リンクを以下に変更して再ビルドしてください。
- git clone https://github.com/rapekas/discourse-vk-auth