Fabric: ThreadingGroupの実行にスリープが含まれている場合、ローカル端末のstdinがデタッチされます

考えられる2番目の再現可能な問題のケースとして＃1814を参照してください。

これは私には正当なバグのように聞こえますが、何が原因で問題が発生しているのかわかりません。 ターミナルパイプが一度に複数のサブプロセスに接続されている一般的なUnixの問題、または（特に＃1814の例では）パイプ状態の競合状態などのにおいがします。

原因/解決策を再現して混乱させようとします。

また、これはおそらくInvokeレベルでの修正が必要であり、純粋にそのドメイン内にある可能性があります（純粋なInvokeコンテキストでのスレッド化についてはまだ多くのことを行っていないため、insofarですが、たとえばpyinvoke / invoke＃194を参照してください-それはそこでも発生するはずです）。 その場合、これをそこのチケットに移動します。ファブリックの「修正」は、修正がリリースされたらInvokeをアップグレードすることです。

私は同じものに接続しているUbuntu16.04.2を使用していました。

＃1829の同じ問題の別のレポート。 これは私の次のバグ修正マイルストーンにあり、できれば次のOSS日（月）に焦点を当てます。

これ（2.0ブランチ、Python 3.6.4、macOS 10.12）を再現しようとしましたが、残念ながら再現できませんでした。 最初にdouble-localhostを試し、次に2つの別々のリモートクラウドインスタンスを試しました。どちらの方法でもサイコロはありません。 その後、私の端末は大丈夫です。

念のためLinuxコンテナを少し試してみますが、OPもmacOSにあるので、違いが出るかどうかはわかりません。 また、ループで実行して、たまにしか再現されないかどうかを確認します。

2.1で導入した場合に備えて、2.1でも試してみますが、これはほとんどありそうにありません。

@jensenak @nicktimkoこれを100％再現していますか？ 50％？ 5％？

@bitprophet on 2.1.3は、実際のワークフローでかなり頻繁に発生していました（> 80％、2

@bitprophetこれは私にとって100％の時間です。 念のため、ファブリックのみをインストールして新しいvirtualenvを開始しました。 2.0、2.1、および2.2をテストしました。 貼り付けたサンプルコードは、毎回説明されている動作を生成しました。 すべてのテストで、Ubuntu14.04リモートに接続していました。

別のバージョンのOSX（10.13）を使用しています。 おそらくそれは関連していますか？ @nicktimkoはOSXにはまったくありません

別のバージョンが問題になる場合は、virtualenvでpip freezeどのように表示されたかを次に示します。

asn1crypto==0.24.0
bcrypt==3.1.4
cffi==1.11.5
cryptography==2.3
fabric==2.2.1
idna==2.7
invoke==1.1.0
paramiko==2.4.1
pyasn1==0.4.4
pycparser==2.18
PyNaCl==1.2.1
six==1.11.0

これらはすべてファブリック2.2の依存関係としてインストールされているため、バージョンは同じように見えると思います。

助けるために私にできることがもっとあるなら、私は喜んで以上です。 他にどこを見ればいいのかよくわかりません。

どのコミットでテストする必要がありますか。 最近、物事に影響を与える可能性のある変更を加えましたか？ 上記のフリーズを試してみます。別のフリーズしたreqs.txtを提供することもできますが、それが機能するかどうかを確認できます。

@ nicktimko @ jensenak追加情報をありがとう。 私はここでそれを再現しようとし続けます。 20％で、私はそれをトリガーするのに十分に試していなかったでしょう。 私のリモートはMacといくつかの古いDebianでしたが、それが何らかの形でそれに固有である場合は、Ubuntu Trustyを試すことができます（これは奇妙ですが、これはすべて奇妙です）。

また、ローカルシェル環境は何ですか？ 私のは、tmux内の（ここでもmacOS 10.12）組み込みのTerminal.appのzshです。 また、その角度の周りのいくつかの順列を少し試してみます。

AHA。 これはbash固有のようです！ tmuxの外部でzshの下で再現することはまだできませんでしたが、bashの下で試してみると、すぐに上記の症状が発生します。 tmuxの内部も同じなので、tmuxには何の関係もありません。これはシェルの問題です。

_なぜ_これはbashとzshで異なる動作をするので、私にはすぐにはわかりません。 それらがどのように実装されているかに固有である可能性がありますか、または（より可能性が高いようです）私のzshドットファイルの何かが問題を防いでいる可能性がありますか？ 掘り下げる必要があります... Python側でソリューションを特定することは、どちらの方法でも最も可能性が高いですが。

編集：また、ローカルホストのsshdに同時に複数回接続した場合でも、再現が行われます。これはそれほど驚くことではありません。 したがって、リモートエンドは問題ではないようです。

また、「前回の実行を除いて、次の実行でのみ問題が発生しない」というメモを確認しようとしましたが、それは発生しませんでした。 私は関係なく毎回行動を起こします。

うめき声： sleepを削除して、何が起こるかを確認しました。 少し断続的になりましたが、まだ再現できます（ただし、これは自動ループで再現するのは簡単ではないため、すべて手動で再現します。つまり、テストケースの数が少なく、実際の発生率が実際になります。正確に測定するのは難しい。）

それも良いことです。奇妙なトリガーが少ないほど良いのです。 これは、どこかで基本的な、ばかげた糸脱毛の間違いであるはずのように聞こえます。これは、競合状態（またはw / e）の可能性を高める時間の長さを除けば、通常、リモートまたはローカルエンドに固有の影響を受けません。

これがpyinvoke / invoke＃552に関連しているかどうか疑問に思います。これは、スレッドの死の検出を台無しにした可能性のあるInvokeの例外処理スレッドサブクラス（ここではThreadingGroupで使用）に要約されます。

私がそれを理解していることを確認する必要があります（その潜在的な修正、pyinvoke / invoke＃553は、明らかに機能的なものを取得したのは奇妙に思えたので、インスタマージではなかったので、間違っています）、それを適用することでこの症状は消えます。

私は何が起こるかを見るために睡眠を取り除いた。 少し断続的になりましたが、まだ再現できます

私が持っていたテストケースのように聞こえますが、バグが発生する前に数回ヒットする必要がありました。 あなたはそれをうまく処理しているようです

今日、私も1か月前に説明した例外の動作を再現できないことに気づきました...残念ながら、そのとき何をしていたか覚えていません。 ：/

私は確かにここでbashを実行しています。 良い発見。 睡眠なしで問題が断続的に発生するという事実は、これが何らかの競合状態であるかどうか疑問に思います。

あなたはそれを言います、しかし今私はそれを再び再現することができないか、少なくともそれは非常に断続的です。 睡眠を元に戻すと、より頻繁に睡眠が発生します。 競合状態が大好きです。

そのInvokeの問題を見ると、記者は台無しにされた端末を症状として言及しています。 しかし不思議なことに、彼のコードでは、bashの下でもその症状を再現することはできません。 根本的な原因が同じである場合でも、驚くことはありません（スレッドの停止とstdinのクローズ、または終了前に適切に行方向のバッファリングに戻すことに関するいくつかのことと関係があります）。

ここでの再現ケースに対して、言及された他の問題のスポットをチェックします：

• ExceptionHandlingThread.is_deadビットは重要ではないようですが、おそらく正しいように表示されます。これは、スレッド内の例外を処理することを目的としており、これらのケースのいずれも実際には例外を処理しないため、ある程度意味があります。 is_deadは、3つのワーカースレッド（stdin / out / err）すべてでFalseです。
• サブプロセスのstdinを適切に閉じていないというアサーションは、マークに近づいているように感じます。 それが制御端末のstdinを今は死んでいるファイル記述子か何かに接続したままにしておくなら...？ （とにかく、この場合に何が起こるかを本当によく知っている必要があります。）
  
  
  
  • ただし、Fabricの場合は、ローカルサブプロセスがなく、ファイル記述子の直接パススルーもないため、そうではありません。
  
  
  • 問題は他の何かである可能性が高いという意味ですか？
  
  

別の方法を試してみてください...バグが発生した後のターミナル環境はどうなっていますか？ バグの破損がある場合とない場合の両方でbashの下でstty -a実行すると、私が見ることができる違いは次のとおりです。

• lflags ：バグアウトされた端末には-icanon 、 -echo 、 -pendin （通常の用語ではすべてマイナス記号がありません）。 それが意味することを仮定すると、エコーしないことは確かに問題のように思われます。
• iflags ：バグアウトには-ixanyとignpar （悪いセットアップで設定されているものの最初の例）
• oflagsとcflags同一であり、 ccharsも同じです（制御文字が変更された場合、私は本当に変になります...）

man sttyよると：

• icanonは、ERASEおよびKILL処理を制御します。 おそらく大きな違いではありません（なぜこれが設定されているのか、設定されていないのかが興味深いかもしれません）
• echoは、エコーするかどうかにかかわらず、どのように聞こえるかであり、明らかにバグの最大の実際的な問題です。
• pendinは、正規の切り替え後に入力（stdinを想定）が保留中であるかどうかを示し（ icanonが明らかに反転しているため...そうです）、読み取りが保留になるか、入力が増えると再入力されます到着。 これが重要である理由、またはバグが発生したときに正常に設定され、設定が解除される理由が明確ではありません（どちらかといえば後者を期待していました）。
• ixany使用すると、任意の文字で「出力を開始」できます（設定されていない場合は、STARTのみが許可されます。ok？）
• ignparは、パリティエラーのある文字を無視する（または設定を解除して無視しない）ことを意味します。

全体として、ユーザーがマッシュインするまで待つのではなく、一度に1バイトずつ読み取ることができるように、stdinを文字バッファー読み取りに設定する方法と同様に、より高いレベルの「モード」が端末に適用されているように感じます。

これは、表示されている動作のように聞こえます（一種の...）、そして私が以前に疑問に思っていたものです。 しかし、問題のコードを読むと（Invokeパッチでも言及されているため、re：thread deathですが）、モード変更はコンテキストマネージャーとして表現されているため、ループから抜け出す方法に関係なく、常に設定が解除されているはずです。 しかし、私は今それをトリプルチェックする必要があります。

マイナー：単純に言ってstty echoに設定するecho '修正'末端に十分です。 icanon 、 pendinなどがまだ設定されていない場合でも。 本当に役に立たないがねえ、私が推測することを知って良かった。

わかった！ そのcontextmanagerを見つめながら、私はそれを理解したと思います。これはおそらく、contextmanagerがブロックの終了時に復元するために現在の端末状態をスナップショットするためです。 しかし、この場合、私たちは何をしているのでしょうか？ _ 2つの別々の高レベルスレッド_を実行しており、それぞれがこのコンテキストマネージャーの_独自のコピー_を実行しています！

また、Invokeでは、スレッドセーフを目指していますが、現在、独自の低レベルIOスレッド以外はテストしていません。 「スレッドセーフ」の99％は、Fabric 1の恐ろしいグローバルモジュール状態ではなく、自己完結型のオブジェクト状態を使用することです。 したがって、この特定の状態保持ビットがそれ自体と同時に実行されることはありません（「状態」が文字通り制御端末であり、そのうちの1つしかないため、グローバル状態...）。

私はまだそれを100％証明していません（これから）が、これがそうではない方法はありません。 2番目に実行されるスレッドは、最初のスレッドがすでに文字バッファーモードに設定した後、制御端末属性のスナップショットを作成する可能性が高くなります。 次に、その2番目のスレッドも2番目に_終了_した場合（これもおそらく確実ではありませんが）、不良状態を「復元」し、最初のスレッドの復元を効果的に元に戻します。

たとえば、ECHOフラグは、最初以外のコンテキストマネージャーによって確実にスナップショットが作成され、同じものによって復元されていることを確認しました。 解決策に取り組んでいると、「setcbreakがすでに適用されているように見えるかどうかを確認し、その場合は、snapshot-modify-restoreダンスを実行する代わりにno-op」になると思います。

意図した効果があり、起動がわずかにクリーンで（setcbreak> 1回実行することはありません）、単純な修正でECHOなどが常に「オン」に設定される可能性があるコーナーケースを回避します。これは、問題のストリームがttyに似ていますが、エコーしないように_すでに_設定されていました。 （可能性は低いですが、確かですが、おそらく不可能ではありません。）

これは呼び出しのみの問題なので、そのトラッカーにホームを提供します-すぐにテストと修正が行われることを期待していますが、他に追加するものがある場合は、 httpsにアクセスして

明確にするために、それが修正されたら、Invoke 1.0.2 / 1.1.1（そして、同時にそれを取得した場合はおそらく1.2.0）でリリースする必要があり、ファブリックのアップグレードは_no_必要であり、Invokeのみである必要があります。

@bitprophet素晴らしい！ Invokeをアップグレードした後に機能します:)
あなたの努力に感謝。