私は Debian Jessie サーバーで Nginx、FCGI、および Request Tracker を実行しています。Request Tracker は Nginx によって提供されますが、FCGI はそれらの中間にあります。重要なことは、FCGI サーバーが時々失敗し、RT のユーザーに 502 エラーが表示されることです。修正は簡単ですが、それは私がここ 1 か月ほどの間に何度も実行したからです。私がいなくて、他の誰かが FCGI サーバーを再起動する必要がある場合、その人は困難に直面する可能性があります。さらに、サーバーの停止と再起動は面倒ですが、RT に変更を適用するにはそれを行う必要があります。
これらすべてから、私は次の結論に至りました。コマンドをもっと簡単にするにはどうしたらよいでしょうか。スクリプトですか? サービスにして、 に存在させるのですか/etc/init.d? それとも他の何かですか? 私は Debian や Linux 全般について初心者なので、自分の選択肢や、それぞれがどの程度複雑になるのか、よくわかりません。発行する必要があるコマンドは次のとおりです。
netstat -antp | grep LIST | grep 12345
(これにより、ポート 12345 にバインドされている FCGI サーバーが検出され、PID を取得できます。PID は 8091 だとします。)
kill 8091
spawn-fcgi -u someUser -g someGroup -a 127.0.0.1 -p 12345 /opt/rt4/sbin/rt-server.fcgi
ここでの重要な注意点は、コマンドが何も返さない可能性があるということですnetstat。返された場合は、FCGI サーバーがサイレントに失敗しているため、killコマンドをスキップして、1 に直接進みますspawn-fcgi。それ以外の場合は、killコマンドをそのままにしておきます。
理想的には、 のようなものに開始/停止/再起動のオプションがあればいいのです/etc/init.d/rt-fcgi-serverが。ただし、最初に PID を見つける必要があるため、プロセスを強制終了するにはどうすればよいかわかりません。ファイルの使用も考えました.pidが、ファイルを使用するように指示する方法や、ファイルがあったとしてもそのファイルをどうすればよいかがわかりませんspawn-fcgi。それが私の希望どおりに機能するかどうかもわかりません (コマンドの使用を避けるために PID を保持しますnetstat)。
これですべてが理解できたと思います。基本的に、コマンド/etc/init.dの結果を制御するために、 1 つのコマンド、または に関連付けられた何かspawn-fcgiを用意したいと考えています。私よりも Linux についてあまり知らない非 root ユーザーがログインして 1 つのコマンドを実行できるようにしたいのですが、 を使用せずにこのプロセスのステータスを照会する方法があればnetstat、それを強制終了するために PID を取得する必要がなくてもかまいません。この方法により、サーバーが失敗した場合に Monit などを使用してサーバーを自動的に再起動できます。
答え1
この回答は FreeBSD の観点から書きますが、Linux や Debian にも適用できるはずです...パッケージ名などは変更される可能性があります。
私は spawn-fcgi にも同様に不満を感じていました。FreeBSD では rc.d スクリプトがありますが、rc.d ルールに従っていません (たとえば、「再起動」できません)。
しかし、spawn-fcgi マニュアルの下部には supervise について書かれています。検索してみると、「daemontools」が見つかりました... FreeBSD には、daemontools と daemontools-encore のパッケージがありました。-encore の方が新しく、機能も充実しているようだったので、こちらを選択しました。私のバージョンは daemontools-encore の 1.10_1 です。
FreeBSD では、svscan 用の rc.d スクリプトが提供されています。FreeBSD では、このスクリプトは /var/service のサブディレクトリをスキャンし、各サブディレクトリに対して「supervise」を実行します。私はこのデフォルト設定を受け入れ、svscan_enable="YES"/etc/rc.conf に記述しました。Linux の場合、rc スクリプトについてはわかりませんが、/service がデフォルト ディレクトリであると書かれています。
/var/service 内に rt-fcgi を作成し、rt-fcgi 内に run を作成しました。「run」には次の内容が含まれています。
#!/bin/sh
spawn-fcgi -u www -g www -s /tmp/rt.sock -n -- /usr/local/sbin/rt-server.fcgi
当然ですが、Linux では、使用しているユーザーとグループ、および rt-server.fcgi の場所が必要です。
svscan システムは、プロセス タイトルの最後の数行のエラーを通知するようです。他のオプションもあります。私の場合は次のようになります。
46495 - IJ 0:00.01 /usr/local/bin/readproctitle service errors: ...tory (/var/run/rt44/data/gpg). GnuPG support has been disabled (/usr/local/lib/perl5/site_perl/RT/Config.pm:790)\n[52465] [Tue Mar 7 21:09:54 2017] [warning]: The requested port (443) does NOT match the configured WebPort (80). Perhaps you should Set($WebPort, 443); in RT_SiteConfig.pm, otherwise your internal hyperlinks may be broken. (/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm:1328)\n
... つまり、gnupg が正しく構成されていないということです。svscan のログを構成しない限り、そこでエラーなどを探す必要があるようです。
これは fcgi 1 つに対してかなり強引なビットですが、既成であり、機能します。何らかの理由で終了するスクリプトを処理しますが、PID ファイルまたはソケット (ソケット ファイルの作成以外) は管理しません。
私はこの混乱よりも WSGI 標準に魅了されていると言わざるを得ません。