SIGTERM handler에서 printf와 malloc을 호출하려 합니다. async-signal-safe가 필요한 이유와 안전한 종료 신호 처리 패턴은 무엇인가요?

printf와 malloc은 일반적인 signal handler에서 호출하지 않는 것이 맞습니다. thread-safe는 여러 thread가 정상 호출을 동시에 수행해도 안전하다는 뜻일 수 있지만, async signal은 같은 thread가 함수 내부의 stdio lock·buffer 또는 allocator free list를 갱신하는 임의의 순간에 끼어듭니다. 그 handler가 다시 printf를 호출하면 자신이 보유한 내부 lock을 기다리거나 중간 buffer를 훼손할 수 있고, malloc도 중간 자료구조를 재진입해 불변식을 깨뜨릴 수 있습니다. POSIX portable 경로는 signal-safety(7)의 async-signal-safe 함수 집합으로 좁혀야 하며, errno를 다룬다면 진입 시 저장하고 반환 전 복구합니다.

안전한 패턴은 handler가 volatile sig_atomic_t flag를 세우거나 self-pipe의 write처럼 제한된 통지만 수행하고, main loop가 정상 문맥에서 accept 중단·worker drain·로그·free·join을 처리하는 구조입니다. 예를 들어 SIGTERM을 받으면 flag가 1이 되고 loop가 다음 작업 경계에서 종료 절차를 시작합니다. pipe가 가득 차 write가 EAGAIN이어도 flag로 요청을 보존해야 합니다. signal은 진행 중인 DB commit이나 외부 메일을 자동 rollback하지 않으므로 graceful shutdown의 순서와 취소 정책은 본문 thread가 별도로 결정합니다.

flag 패턴도 종료를 즉시 보장하는 것은 아닙니다. main loop가 긴 blocking call 안에 있으면 signal 도착 후 다음 관찰 지점까지 지연될 수 있고, SA_RESTART 설정에 따라 system call의 EINTR 관찰이 달라질 수 있습니다. 그래서 graceful shutdown 테스트에서는 새 요청 수락 시각, 현재 작업의 commit 경계, worker join 완료를 순서대로 검사합니다. 전용 sigwait를 쓰면 복잡한 정리를 정상 thread에서 할 수 있지만, 시작 전에 모든 worker가 signal을 block했는지 확인해야 합니다.