If Dev Then ?

`multiprocessing` 자식 프로세스에서만 -X 옵션이 사라진다면: PR #146005가 정리한 “인터프리터 플래그 전달” meta_description: CPython PR #146005는 subprocess/multiprocessing이 자식 파이썬 프로세스를 띄울 때 -X 옵션을 누락 없이 전달하도록 수정한다. dev/tracemalloc/importtime 등 런타임 디버그 옵션이 부모에서는 켜졌는데 자식에서만 꺼지는 문제를 줄인다. 운영/디버깅 관점에서 어떤 증상이 사라지는지, 어떤 -X 옵션이 특히 중요하며, 호환성/주의점은 무엇인지 정리한다. meta_keywords: python, multiprocessing, subprocess, -X, xoptions, dev mode, tracemalloc, importtime, faulthandler, debugging, child process, CI, production, practical meta_robots: index,follow 운영 디버깅에서 제일 짜증나는 버그 유형이 있다. 부모 프로세스에서는 디버그 옵션이 켜져 있는데 자식 프로세스(특히 multiprocessing 으로 띄운)에서는 꺼져 있다 그래서 로그가 갈라지고, 재현이 흐려진다. -X tracemalloc 은 켰는데, 자식에서 스냅샷이 없다 -X importtime 켰는데, 자식 프로세스의 import 시간은 안 찍힌다 -X dev 켰는데, 자식에서만 경고가 안 뜬다 PR #146005(gh-146004)는 이 ‘갈라짐’을 줄이는 방향으로 subprocess 쪽 플래그 전달을 정리한다. 핵심은 간단하다. 부모 인터프리터에 설정된 -X 옵션(xoptions)을, 자식 파이썬 프로세스 실행 인자에 일관되게 전달한다. 1) PR #146005가 바꾼 것: “일부만 전달” → “전부 전달(정렬해서)” diff의 핵심은 Lib/subprocess.py ...

`shell=True`인데 returncode가 음수가 아니라서 당황했다면: PR #146255가 정리한 “셸의 책임” meta_description: POSIX에서 subprocess의 returncode는 보통 신호 종료면 -N이라고 배웠지만, shell=True 나 asyncio.create_subprocess_shell() 에서는 그 규칙이 깨질 수 있다. CPython PR #146255는 “returncode는 셸의 종료 상태를 반영하며, 신호를 128+N 같은 코드로 매핑할 수 있다”는 점을 문서로 명확히 했다. 운영 코드에서 재현/로깅/알람을 어떻게 설계해야 덜 흔들리는지 정리한다. meta_keywords: subprocess, asyncio, returncode, shell=True, create_subprocess_shell, create_subprocess_exec, POSIX, signal, 128+N, Bash, exit status, SIGTERM, SIGKILL, 프로세스, 종료코드, 운영, 재현, 로깅, 알람, 파이썬 meta_robots: index,follow 운영하다 보면 이 상황을 한 번은 만난다. 프로세스가 SIGTERM으로 죽었으니 returncode == -15 일 거라고 생각했는데 실제 로그에는 143 이 찍혀 있다(= 128 + 15) 어떤 경우는 또 -15 로 찍힌다 그래서 대시보드가 갈라지고, “이번 장애는 신호 종료냐? 정상 종료냐?” 분류가 흔들린다. CPython PR #146255는 이 혼란의 원인을 문서로 깔끔하게 정리한다. 핵심은 한 줄이다. shell=True 면 returncode는 ‘자식 프로세스’가 아니라 ‘셸(/bin/sh)의 종료 상태’를 반영한다. 셸은 신호를 그대로 “음수”로 내보내지 않을 수 있고, 대신 128+N 같은 규칙으로 매핑할 수 있다(참고자료). 1) PR #146255가 실제로 추가한 문장(요약) diff를...