감사(audit) 훅이 소켓을 느리게 죽인다: PR #146248이 보여준 관측 코드의 메모리 누수 패턴 meta_description: CPython PR #146248은 socket 모듈에서 audit hook을 통해 참조(reference)와 버퍼(buffer)가 새는 문제를 수정했다. 보안/관측을 위해 sys.addaudithook를 붙였는데, 의도치 않게 객체 수명을 늘려 메모리 누수처럼 보일 수 있다. 운영 코드에서 audit hook를 안전하게 쓰는 패턴(최소 정보만 복사, 객체 저장 금지, 버퍼 처리, 샘플링/비동기화)을 정리한다. meta_keywords: python, socket, audit hook, sys.addaudithook, CPython, memory leak, reference leak, buffer leak, observability, security, GC, tracemalloc, weakref, logging, sampling, asyncio, 운영, 메모리 meta_robots: index,follow 운영에서 메모리가 서서히 오르는 서비스를 잡다 보면, 진짜 원인이 비즈니스 로직이 아닌 경우가 꽤 많다. 디버그 로그 트레이싱/계측(telemetry) 보안/감사(audit) 즉, 관측 코드 가 시스템을 갉아먹는 케이스. CPython PR #146248(gh-146245)은 이걸 아주 교과서적으로 보여준다. socket 모듈이 audit hook과 엮이는 과정에서 reference/buffer leak 이 생길 수 있었고, 그걸 고쳤다. 이 글은 PR을 번역하려는 글이 아니다. 실무에서 바로 쓰는 관점으로 정리한다. audit hook가 왜 메모리 누수처럼 보일 수 있는지 sys.addaudithook를 붙일 때 뭘 저장하면 위험한지 로그를 남기면서도 객체 수명을 늘리지 않는 방법 1) PR #146248 한 줄 요약: 감사 훅이 데이터를 잡고 있었다 ...
`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를...