파이썬 - PyCharm을 이용한 fork 디버그 방법
지난번에 설명한,
윈도우 개발자를 위한 리눅스 fork 동작 방식 설명 (파이썬 코드)
; https://www.sysnet.pe.kr/2/0/12811
fork의 작동 방식을 알았으면 이제 디버깅까지 알아봐야겠죠. ^^ 어떤 면에서는 다중 프로젝트 디버깅의 관점으로 생각할 수 있겠지만,
PyCharm - 다중 프로세스 디버깅 방법
; https://www.sysnet.pe.kr/2/0/12806
실제로 해보면 완전히 다르게 접근해야 합니다. 어떻게 바뀌나 아래의 예제로 한번 볼까요? ^^
import os
pid = os.fork()
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
elif pid == 0:
print('자식 프로세스의 실행 흐름', os.getpid())
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
우선, PyCharm은 fork 시 부모/자식 프로세스에 대해 모두 디버깅 환경을 제공합니다. 하지만, 저 상태에서 실행하면 (대개의 경우) PyCharm 콘솔 화면에는 다음과 같은 식의 부모 프로세스에 대한 출력만 보입니다.
Connected to pydev debugger (build 212.4746.96)
부모 프로세스의 실행 흐름 6295
모두 호출 6295
이런 결과는 PyCharm에서 실행할 때만 발생합니다. 직접 리눅스 환경에서 실행하면 "자식 프로세스의 실행 흐름" 메시지까지 모두 볼 수 있는데요, 아마도 PyCharm은 실행 대상의 "루트 프로세스"가 종료하면 자식 프로세스들까지 모두 강제로 종료하기 때문에 그런 것으로 보입니다.
따라서 PyCharm의 실행으로 자식 프로세스의 출력까지 보고 싶다면 부모 프로세스의 종료 시간을 지연해 줄 조치를 취해야 합니다. 대충 이런 식이 될 것입니다.
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
if os.getenv("IDE_PROJECT_ROOTS"):
time.sleep(1)
위의 코드를 추가하고 다시 PyCharm에서 Run/Debug로 실행하면 예상했던 출력을 확인할 수 있습니다.
부모 프로세스의 실행 흐름 6641
자식 프로세스의 실행 흐름 6645
모두 호출 6645
모두 호출 6641
그런데, 디버깅 관련해서 PyCharm에는 또 다른 이상한 규칙이 있는 것 같습니다. 저렇게 fork가 실행되는 경우, PyCharm은 가능한 이후에 실행되는 프로세스로 디버깅 세션을 연결한다는 것입니다.
일례로, 다음과 같이 BP를 걸어볼까요?
그럼, 디버그 시 PyCharm은 자식 프로세스와는 어떤 연동도 없으므로 그냥 부모 프로세스의 디버깅을 하게 돼 정상적으로 BP가 걸립니다.
반면, 다음과 같이 BP를 걸면,
자식 프로세스는 (부모 프로세스가 종료했으므로) 어떤 기회도 얻지 못해 PyCharm의 디버그 실행으로는 BP가 걸리지 않습니다. 만약 위의 상황에서 BP를 걸고 싶다면 이전에 언급한 대로 sleep을 줄 수 있는데요,
import os
import time
pid = os.fork()
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
if os.getenv("IDE_PROJECT_ROOTS"):
time.sleep(1)
elif pid == 0:
print('자식 프로세스의 실행 흐름', os.getpid())
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
저렇게 하고 "print('자식 프로세스의 실행 흐름', os.getpid())" 라인에 BP를 걸고 다시 PyCharm에서 Debug를 시작하면 이번에는 BP가 걸리긴 하지만 PyCharm의 디버깅 환경이 이내 해제가 되어버립니다. 왜냐하면, 이번에도 역시 부모 프로세스가 1초 후에 종료했으므로 현재 BP가 걸린 자식 프로세스까지 강제 종료되어 디버깅이 해제가 된 것입니다.
따라서, 위와 같은 경우에 마음 편히 자식 프로세스의 디버깅을 하고 싶다면 sleep을 크게 주든가, 아니면 아예 input 등의 함수를 실행하든가, os.waitpid 등의 방법을 강구해야 합니다.
import os
pid = os.fork()
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
if os.getenv("IDE_PROJECT_ROOTS"):
os.waitpid(pid, 0) # 자식 프로세스가 종료할 때까지 대기
elif pid == 0:
print('자식 프로세스의 실행 흐름', os.getpid())
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
위와 같은 경우, 부모 프로세스에서 자식 프로세스 종료까지 대기하므로 PyCharm에서 자식 프로세스에 대한 디버깅을 마음 편히 할 수 있습니다.
자, 그럼 다시 처음으로 돌아가서 "pid = os.fork()"에 BP를 걸면 어떻게 될까요? 원칙을 따지면 이해가 되는데, 처음에는 디버깅 과정이 좀 황당할 수 있습니다.
일단, BP를 걸고 PyCharm에서 디버깅을 시작하면 당연히 그 라인에서 실행이 멈춥니다. 이후 Step-Over로 다음 라인을 실행하면 그때까지만 해도 부모 프로세스를 디버깅하던 것이, 순간적으로 약간 멈칫하면서 자식 프로세스의 디버깅 세션으로 전환이 됩니다. 따라서, 이후 if 문에서는 언제나 "elif pid == 0" 내의 코드로 진입합니다.
즉, "pid = os.fork()" 라인 이전부터 디버깅을 시작하면 절대로 "if pid > 0" 내의 코드로 진입할 수 없습니다. 왜냐하면 PyCharm은 다중 디버깅은 지원하지만, 디버깅 세션 자체는 하나만 지원하기 때문입니다. 이 점이, 비주얼 스튜디오를 사용해 본 개발자들에게는 상식적이지 않아서 처음에는 PyCharm의 fork 디버깅에 대해 혼란스러울 수 있습니다.
그런데 또 하나의 문제가 있는데요, os.fork 후에 execl로 실행하는 프로세스에 대한 디버깅입니다.
import os
pid = os.fork()
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
elif pid == 0:
print('자식 프로세스의 실행 흐름', os.getpid())
os.execl(sys.executable, sys.executable, 'calc.py')
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
위와 같은 경우, python 자식 프로세스로 새롭게 calc.py 스크립트를 실행시키고 있는데 해당 소스 코드에 BP를 걸어봤자 PyCharm에서는 디버깅이 안 됩니다.
이것을 디버깅하려면 아래의 글에서 쓴 방법을 활용해야 합니다. (혹시 또 다른 방법이 있다면 덧글 부탁드립니다. ^^)
PyCharm - (반대로) 원격 프로세스가 PyCharm에 디버그 연결하는 방법
; https://www.sysnet.pe.kr/2/0/12800
따라서, "Python Debug Server" 유형의 "Run/Debug Configuration"을 하나 추가하고 execl로 실행하는 (위의 경우 calc.py) 소스 코드에는 이런 식으로 pydevd.settrace 코드를 호출해 주어야 합니다.
import os
import pydevd
pydevd.settrace('...pycharm의 Python Debug Server의 주소...', port=14444, stdoutToServer=True, stderrToServer=True)
print('calc.py', os.getpid())
그런데, 다시 한번 강조하지만 자식 프로세스가 디버깅하는 동안 (fork의) 부모 프로세스가 살아 있어야 하므로, 반드시 waitpid와 같은 방법을 써야 합니다.
...[생략]...
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
os.waitpid(pid, 0) # 자식 프로세스가 종료할 때까지 대기
...[생략]...
또는, fork가 아닌 subprocess.Popen으로 하면,
import os
import sys
import subprocess
pid = os.fork()
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
os.waitpid(pid, 0) # 자식 프로세스가 종료할 때까지 대기
elif pid == 0:
print('자식 프로세스의 실행 흐름', os.getpid())
subprocess.Popen([sys.executable, 'calc.py'])
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
이렇게 해도 calc.py에 있는 pydevd.settrace를 통한 디버깅 연결이 안 됩니다. 왜냐하면, 위의 경우에는 subprocess.Popen으로 곧바로 실행 반환이 되므로 해당 서브 프로세스(python calc.py)의 디버깅을 하는 동안 그것의 부모 프로세스인 fork의 자식 프로세스가 마찬가지로 종료가 돼 결국 그것의 자식 프로세스인 "python calc.py"도 종료되기 때문에 디버깅이 해제됩니다.
따라서, 위와 같이 Popen을 사용하면 (fork 된) 자식 프로세스에서도 waitpid를 해줘야 합니다.
import os
import sys
import subprocess
pid = os.fork()
if pid > 0:
print('부모 프로세스의 실행 흐름', os.getpid())
os.waitpid(pid, 0) # 자식 프로세스가 종료할 때까지 대기
elif pid == 0:
print('자식 프로세스의 실행 흐름', os.getpid())
child_process = subprocess.Popen([sys.executable, 'calc.py'])
os.waitpid(child_process.pid, 0) # 자식의 자식 프로세스가 종료할 때까지 대기
else: # pid < 0
print('fork 오류')
print('모두 호출', os.getpid())
이 정도면 대충 느낌 아시겠죠?!!!
참고로, 다음은 uwsgi를 execl로 실행한 경우입니다.
import os
import sys
pid = os.fork()
test_args = ['uwsgi', '--http', ':18090', '--chdir', '/mnt/d/pycharm/work/testconsole', '--wsgi-file', 'calc.py']
if pid > 0:
os.execl('/usr/local/bin/uwsgi', *test_args)
elif pid == 0:
else: # pid < 0
print('fork 오류')
저 경우에도 calc.py에서 pydevd.settrace를 제공하면 정상적으로 Python Debug Server에 연결해 디버깅이 진행됩니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]