私はsystemdサービスを使って実行しているスクリプトを実行して、その後に.tacファイルを実行するシンプルなアプリケーションを作っています。キャッシュをウォームアップで処理するとねじれてしまいました。
アプリケーションは、t.w.sr.iteに組み込まれ、t.a.i.TCPServerを提供するt.w.r.Resourceに組み込まれたJSON RPCエンドポイント（fastjsonrpc）として構成され、すべてがt.a.Applicationにパックされています。これは正常に動作します。
問題が発生するのは、起動時にキャッシュをウォームアップしようとするときです。このウォーミングアッププロセスはかなり遅く（〜300秒）、システムのタイムアウトを引き起こし、プロセスを終了させます。タイムアウトを増やすことは、実際には実行可能な選択肢ではありません。これは、システムのブートをブロックしたくないからです。
類似コードは、Apacheおよびwsgi内からFlaskで実行される別のスタックで使用されます。そのサーバーはそれ自体をオフにして、キャッシュを構築する時間がかかる間にsystemdを続行させます。この動作は私にとっては問題ありません。
私はtwrResourceのセットアップ関数内で、次を使用してウォームアップ関数を呼び出してみた：
reactor.callLater(1, ep.warmup, None)
私はまだにsystemdの中からこれを使用してみていませんでした、とtwistdから、それをテストしてきました直接コマンドラインで実行します。サーバーは期待通りに動作しますが、SIGINT（^ C）には応答しません。 callLaterを削除するだけで、サーバーがSIGINTに応答できるようになります。
ウォームアップ機能が直接呼び出された場合（callLaterではなく、ウォームアップが完了するのを待っている間にsystemdを放棄するような配置ではありません）、結果として得られるサーバーも引き続きSIGINTに応答します。
- このような長時間実行されるウォームアップコードを処理する優れた方法がありますか？
- リアクトルがtwisted/SIGINTに反応しないのはなぜですか？私はここに何かを逃していますか
私は300秒間反応器をブロックすることに問題はありませんが、その後反応器を通常反応させる必要があります。原子炉は正常に機能しますが、もはやSIGINT/SIGTERMに応答せず、SIGKILLを停止する必要があります。 deferToThreadは、私のキャッシュがかなり複雑なPythonオブジェクトのネットワークであるため、うまく動作しない可能性があります。 –
また、「暖機」ルーチンを書き直して遅延を返すことで、制御を定期的に炉に行うことができます。私は、これがあなたが見ている信号の振る舞いに関係するかどうかはわかりませんが、それを行うより良い方法です。 1つの方法は、@inlineCallbacksを使用して、非常に多くのループ反復（ループの場合）ごとに "yield"することです。 – meejah