Linux man 페이지 섹션과 syscall 추적: man 1·2·3·5·7·8

Linux에서 open을 검색했는데 서로 다른 문서가 나오는 이유는 같은 이름이 command, system call, library function으로 겹칠 수 있기 때문이다. 이때 manual section을 지정하면 찾으려는 interface의 층위를 분명히 할 수 있다. raw event, event metadata, system call을 하나의 고정된 처리 단계로 묶기보다 각 도구의 문맥에서 따로 정의하는 편이 정확하다.

man section 번호가 뜻하는 것

Linux man-pages의 대표 section은 다음과 같다.

section	다루는 대상	예시
1	일반 사용자가 실행하는 command	man 1 printf
2	kernel이 제공하는 system call interface	man 2 open
3	C library function	man 3 printf
4	device와 special file	man 4 null
5	file format와 convention	man 5 passwd
6	game	man 6
7	overview, convention, protocol과 기타	man 7 signal
8	system administration command	man 8 ip
9	kernel routine	배포판과 설치 문서에 따라 제공 범위가 다름

문법은 section을 이름 앞에 두는 방식이다.

man 1 printf
man 3 printf
man 2 open
man 2 openat
man 5 passwd
man 7 signal
man 8 ip

man -f open 또는 whatis open은 이름이 일치하는 manual entry를 찾고, man -k 'open file' 또는 apropos는 description keyword로 찾는다. 설치한 package와 배포판에 따라 보이는 문서가 다를 수 있다.

command·library wrapper·system call은 같은 것이 아니다

shell에서 실행하는 command는 process다. 그 process 안의 program은 library function을 호출할 수 있고, library wrapper는 필요할 때 system call interface를 거쳐 kernel에 작업을 요청한다. 이름이 같아도 책임이 다르다.

shell command
    → program logic
    → C library 또는 language runtime
    → system call interface
    → kernel

예를 들어 C의 open()은 man section 2에 설명되는 system call interface이면서 user space에서 호출하는 libc wrapper를 통해 제공될 수 있다. 특정 libc와 architecture에서는 wrapper가 내부적으로 다른 kernel entry point를 사용할 수도 있다. 고수준 함수 한 번이 system call 하나와 항상 1:1로 대응한다고 가정하면 안 된다.

Python의 os.open()도 운영체제의 저수준 file descriptor interface를 노출하지만, Python 코드의 모든 함수 호출이 system call인 것은 아니다. buffering이 있는 file object는 여러 write를 모을 수 있고, 반대로 import나 name resolution 같은 한 작업이 여러 file 관련 system call을 만들 수 있다.

strace로 실제 경계를 관찰한다

Linux의 strace는 process가 수행한 system call과 signal을 관찰할 때 쓴다. 먼저 전체 호출을 길게 쏟아내기보다 summary로 범위를 잡는다.

strace -f -c -- your-command

file access만 보고 싶다면 system call 이름을 무작정 나열하기보다 qualifier를 쓸 수 있다.

strace -f -e trace=%file -s 80 -- your-command

특정 호출만 확인할 때는 다음처럼 좁힌다.

strace -f -e trace=openat,read,write -s 80 -- your-command

결과에 openat이 보였다고 해서 program source가 반드시 openat()을 직접 호출했다는 뜻은 아니다. runtime이나 libc wrapper가 선택했을 수 있다. 반대로 vDSO로 처리되는 일부 기능처럼 일반적인 system call trap을 거치지 않는 경로도 있다. trace 결과는 source-level event가 아니라 관찰된 OS interface 경계로 읽는다.

metadata와 raw event는 도구별 용어다

event metadata는 보통 timestamp, process ID, thread ID, user ID, file descriptor, return value처럼 event를 해석하는 문맥 정보다. Linux 전체가 ‘원시 이벤트 → 메타데이터 → 시스템 콜 이벤트’라는 단일 pipeline을 정의하는 것은 아니다.

raw event도 분야마다 뜻이 다르다.

• perf에서는 CPU PMU의 raw hardware event encoding을 가리킬 수 있다.
• input subsystem에서는 device가 전달한 저수준 input event를 뜻할 수 있다.
• packet capture에서는 decode 전후의 frame이나 packet을 느슨하게 부를 수 있다.
• observability system에서는 가공 전 log·trace record라는 제품별 의미로 쓸 수 있다.

따라서 문서에서 이 말을 만나면 event schema, source, timestamp 기준과 수집 지점을 먼저 확인한다. 이름만 보고 system call보다 ‘더 아래 단계’라고 일렬로 세우지 않는다.

trace 전에 확인할 안전 경계

strace 출력에는 file path, command argument, environment에서 파생된 값, socket 주소와 읽고 쓴 data 일부가 포함될 수 있다. 운영 환경에서 무제한으로 수집하면 비밀 정보와 개인정보가 log로 복제될 수 있다. tracing 자체의 overhead도 workload와 option에 따라 달라진다.

• 본인이 관리하거나 명시적으로 허가받은 process만 추적한다.
• -e와 -s로 범위와 문자열 길이를 줄인다.
• 짧은 시간에 재현하고 민감 정보가 없는 저장 위치를 쓴다.
• ptrace 권한과 container·namespace 경계를 우회하지 않는다.
• 분석이 끝나면 trace file의 보관 기간과 접근 권한을 정리한다.

kernel 내부 동작과 interrupt·workqueue의 경계는 Linux system call·IRQ·workqueue, process memory 관찰은 프로세스 메모리 구조에서 연결해 볼 수 있다.

참고 자료

• Linux man-pages: man-pages(7)
• Linux man-pages: syscalls(2)
• Linux man-pages: open(2)
• Linux man-pages mirror: strace(1)
• Python 표준 라이브러리: os.open