Fabric: ThreadingGroup 실행에 절전 모드가 포함된 경우 로컬 터미널 stdin이 분리됨

재현 가능한 두 번째 문제 사례로 #1814를 참조하십시오.

이것은 나에게 합법적 인 버그처럼 들리고 무엇이 원인인지 잘 모르겠습니다. 터미널 파이프가 한 번에 여러 하위 프로세스에 연결되는 일반적인 Unix 문제이거나 (특히 #1814의 예에 따라) 파이프 상태 주변의 경쟁 조건 등의 냄새가 날 수 있습니다.

원인/해결책을 재현하고 혼란스럽게 만들 것입니다.

또한 이것은 아마도 Invoke 수준에서 수정해야 하고 순전히 해당 도메인에 있을 수 있습니다. 거기에서도 일어나야 함). 이 경우 이를 티켓으로 옮기고 Fabric "수정"은 수정 사항이 릴리스되면 Invoke를 업그레이드하는 것입니다.

나는 Ubuntu 16.04.2에 연결되어있었습니다.

#1829의 동일한 문제에 대한 또 다른 보고서. 이것은 내 다음 버그 수정 이정표에 있으며 다음 OSS 날(월)에 집중할 것입니다.

방금 이것을 재현하려고 시도했지만(2.0 분기, Python 3.6.4, macOS 10.12) 불행히도 할 수 없었습니다. 먼저 이중 로컬 호스트를 시도한 다음 두 개의 개별 원격 클라우드 인스턴스를 시도했습니다. 어느 쪽이든 주사위가 없습니다. 내 터미널은 나중에 괜찮습니다.

도움이 되는 경우를 대비하여 Linux 컨테이너를 조금 시도해 보려고 합니다. 하지만 OP가 macOS에도 있기 때문에 차이가 있을지 확신할 수 없습니다. 또한 루프에서 실행하여 가끔 반복되는지 확인하겠습니다.

우리가 2.1에서 그것을 어떻게든 도입한 경우를 대비하여 2.1에서도 그것을 시도할 것입니다.

@jensenak @nicktimko 이거 100% 재현하시나요? 50%? 5%?

@bitprophet 2.1.3에서는 실제 워크플로에서 상당히 자주 발생했습니다(>80%, 저도 2

@bitprophet 이것은 저에게 100% 시간이었습니다. 확실히 하기 위해 패브릭만 설치된 새로운 virtualenv를 시작했습니다. 2.0, 2.1 및 2.2를 테스트했습니다. 내가 붙여 넣은 예제 코드는 매번 설명된 동작을 생성했습니다. 모든 테스트에서 Ubuntu 14.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

이 모든 것이 Fabric 2.2의 종속성으로 설치되었기 때문에 귀하의 버전이 비슷할 것으로 예상됩니다.

제가 도울 수 있는 일이 더 있다면 기꺼이 도와드리겠습니다. 다른 곳을 봐야할지 잘 모르겠습니다.

어떤 커밋으로 테스트해야합니까? 최근에 영향을 미칠 수 있는 변경 사항이 있습니까? 위의 동결로 시도할 것입니다. 또 다른 동결된 reqs.txt 제공할 수도 있고 그것이 작동하는지/저에게 맞지 않는지 알 수 있습니다.

@nicktimko @jensenak 추가 정보 감사합니다. 나는 그것을 여기에서 재현하려고 계속 노력할 것입니다. 20%에서는 확실히 트리거할 만큼 충분히 시도하지 않았을 것입니다. 내 리모컨은 Mac과 일부 오래된 데비안이었고, 우분투 트러스티가 그것에 특정한 경우를 대비해 Ubuntu Trusty를 사용해 볼 수 있습니다(이상하지만 이 모든 것이 이상합니다.)

또한 로컬 쉘 환경은 무엇입니까? 내 것은 tmux 내부의 Terminal.app 내장 (다시 macOS 10.12)에서 zsh입니다. 나는 또한 그 각도에 대해 약간의 순열을 시도할 것입니다.

아하. 이것은 bash에만 해당되는 것 같습니다! 여전히 tmux 외부의 zsh에서 재현할 수 없었지만 bash에서 시도하는 순간 언급된 증상이 즉시 나타납니다. tmux 내부와 동일하므로 tmux에는 베어링이 없습니다. 이는 쉘 문제입니다.

_왜_ 이것은 bash와 zsh에서 다르게 동작할 것입니다. 즉각적인 아이디어는 없습니다. 구현 방법에 따라 다를 수 있습니까? 아니면 내 zsh dotfiles의 무언가가 문제를 방지하고 있습니까? 파기해야 할 것입니다 ... Python 측에서 솔루션을 식별하는 것이 어느 쪽이든 가장 가능성이 높습니다.

편집: 또한 내 로컬 호스트의 sshd에 동시에 여러 번 연결할 때도 재생산이 발생하는데, 이는 그리 놀라운 일이 아닙니다. 따라서 원격 끝은 중요하지 않은 것 같습니다.

또한 "이전 실행을 제외한 이전 실행은 다음 실행에 대한 문제를 방지함"에 대한 메모를 확인하려고 시도했지만 저에게는 발생하지 않았습니다. 나는 관계없이 매번 행동을 얻습니다.

Moar: 어떻게 될지 보기 위해 sleep 를 제거했습니다. 지금은 약간 더 간헐적이지만 여전히 재현할 수 있습니다(자동 루프에서 재현하기 쉽지 않기 때문에 모두 손으로 재현합니다. 즉, 테스트 케이스 수가 적고 실제 발생률이 실제일 것임을 의미합니다. 정확한 측정이 어렵습니다.)

그것도 좋습니다. 이상한 트리거가 적을수록 좋습니다. 이것은 어딘가에 기본적이고 멍청한 스레딩 실수일 것 같은 _should_이어야 합니다. 일반적으로 경쟁 조건(또는 w/e)을 더 많이 만드는 시간을 제외하고 원격 또는 로컬 끝의 특정 항목에 의해 영향을 받지 않습니다.

이것이 Invoke의 예외 처리 스레드 하위 클래스(여기서 ThreadingGroup에서 사용됨)로 요약되는 pyinvoke/invoke#552와 관련이 있는지 궁금하여 스레드 죽음 감지를 망쳤을 수 있습니다.

(잠재적 수정인 pyinvoke/invoke#553이 인스타 병합이 아니라는 점을 이해했는지 확인해야 합니다. 우리가 뭔가 명백하게 기능적이어서 잘못된 것을 얻은 것이 이상해 보였기 때문입니다.) 그런 다음 적용 여부를 확인해야 합니다. 이 증상이 사라집니다.

나는 무슨 일이 일어날지 보기 위해 잠을 제거했다. 지금은 약간 더 간헐적이지만 여전히 재현할 수 있습니다.

내가 가지고 있던 테스트 케이스처럼 들리는데, 버그가 발생하기 전에 몇 번 쳤어야 했습니다. 잘 다루시는 것 같습니다

나는 오늘 내가 한 달 전에 설명한 예외 동작을 재현할 수 없다는 것을 알게 되었습니다... 불행히도 나는 그때 무엇을 하고 있었는지 기억이 나지 않습니다. :/

나는 실제로 여기서 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 : bugged-out에는 -ixany 및 ignpar (잘못된 설정에서 설정되지 않은 것이 아니라 설정되는 첫 번째 예).
• oflags 및 cflags 동일, 같은있다 cchars (I 실제 지내지 할 것 제어 문자를 변경 한 경우 ...)

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가 블록을 닫을 때 복원을 위해 현재 터미널 상태를 스냅샷하기 때문일 것이다. 그러나 이 경우에 우리는 무엇을 하고 있습니까? 우리는 _두 개의 개별 상위 수준 스레드_를 실행하고 있으며, 각각은 이 컨텍스트 관리자의 _자체 사본_을 실행하고 있습니다!

그리고 Invoke에서는 스레드세이프를 시도하지만 현재 자체 저수준 IO 스레드 외에는 테스트하지 않습니다. "스레드 안전성"의 99%는 단순히 Fabric 1의 끔찍한 전역 모듈 상태 대신 자체 포함된 개체 상태를 사용하는 것입니다. 따라서 이 특정 상태 유지 비트는 그 자체와 동시에 실행되지 않습니다(부분적으로 "상태"가 말 그대로 제어 터미널이고, 그 중 하나는 단 하나이므로...전역 상태...).

나는 아직 그것을 100% 증명하지 않았지만(곧) 이것이 아닐 방법은 없습니다. 두 번째로 실행되는 스레드는 첫 번째 스레드가 이미 이를 문자 버퍼 모드로 설정한 _이후_ 제어 터미널 속성을 스냅샷할 가능성이 높습니다. 그런 다음, 그 두 번째 스레드가 두 번째로 _마감__하면(다시 말하지만 확실하지는 않지만) 잘못된 상태를 "복원"하여 첫 번째 스레드의 복원을 효과적으로 취소합니다.

예를 들어 ECHO 플래그가 첫 번째가 아닌 컨텍스트 관리자에 의해 확실히 스냅샷된 다음 동일하게 복원되는지 확인했습니다. 솔루션에 대한 작업은 "setcbreak가 이미 적용된 것처럼 보이는지 파악하려고 시도하고 스냅샷-수정-복원 댄스를 수행하는 대신 작동하지 않는" 것으로 끝날 것이라고 생각합니다.

의도한 효과가 있어야 하고 부팅하기에 약간 더 깨끗하고(setcbreak >1번 실행하지 않음) 순진한 수정이 항상 ECHO 등을 "on"으로 설정할 수 있는 코너 케이스를 피합니다. 문제의 스트림이 다음과 같은 상황에서 중단됩니다. tty와 비슷하지만 에코하지 않도록 _이미_ 설정되었습니다. (확실하지는 않지만 불가능하지는 않을 것입니다.)

이것은 Invoke 전용 문제이기 때문에 해당 트래커에 대해 설명하겠습니다. 곧 테스트 및 수정이 완료될 것으로 기대하고 있지만 추가할 다른 것이 있으면 https 로 이동

명확하게 하자면, 일단 수정되면 Invoke 1.0.2/1.1.1(동시에 가져오는 경우 1.2.0 가능)에 있어야 하며 _no_ 패브릭 업그레이드가 필요하고 Invoke만 있어야 합니다.

@bitprophet Invoke를 업그레이드 한 후 작동합니다 :)
당신의 노고에 감사드립니다.