pgrep 대기 루프가 안 끝나거나 일찍 끝날 때: macOS에서 직접 만든 상황으로 시험한 결과

한 줄 요약: 이 맥(26.6.2)의 pgrep -f는 기본으로 자기 자신과 상위 프로세스를 빼므로 대기 루프가 안 끝나면 먼저 매칭된 줄을 출력해 누구인지 보고, 가능하면 문자열 대신 PID로 기다려라.

작업이 끝나길 기다리려고 until ! pgrep -f 작업이름; do sleep 1; done 을 썼는데 작업은 끝났는데도 루프가 계속 돌거나, 반대로 작업이 아직 도는데 루프가 먼저 끝난다. 이 글은 이 맥에서 pgrep을 직접 돌려 루프를 붙잡는 상황과 일찍 끝나는 상황을 내가 만들어 시험표로 가르고, 문자열 대신 PID로 기다리는 코드를 준다. 확인한 환경은 macOS 26.6.2 arm64의 /usr/bin/pgrep과 bash 3.2.57이고, Linux는 시험하지 않았다.

용어 몇 개. pgrep은 프로세스 이름이나 명령줄로 PID(프로세스 번호)를 찾는 명령이고, 하나도 못 찾으면 종료 코드 1을 낸다. -f는 이름 대신 전체 명령줄을 본다. 상위 프로세스는 나를 실행한 셸처럼 거슬러 올라가는 부모들이다.

자기 자신에게 걸린다는 말부터 시험했다

내 작업 메모에는 “until ! pgrep -f 패턴 은 자기 자신의 명령줄에 매칭돼 영원히 안 끝난다”는 줄이 있었다. 그 설명대로라면 패턴이 대기 스크립트의 명령줄에 들어 있기만 해도 루프는 끝나지 않아야 한다. 같은 모양을 작게 만들어 워커 없이 돌려 봤다. 패턴 nightjob-4271을 인자로 받는 대기 스크립트다(/tmp/wait.sh로 저장).

#!/bin/bash
n=0
while /usr/bin/pgrep $1 "$2" >/dev/null; do
  n=$((n+1))
  [ $n -ge 6 ] && { echo "3초 안에 안 끝남, 매칭된 것:"; /usr/bin/pgrep -l $1 "$2"; exit 1; }
  sleep 0.5
done
echo "루프 종료, 폴링 ${n}회"

chmod +x /tmp/wait.sh
/tmp/wait.sh -f nightjob-4271

결과는 루프 종료, 폴링 0회였다. 스크립트 이름을 wait-nightjob-4271.sh로 바꿔 파일 이름에까지 패턴을 넣어도 같았다. 여러 경우를 묶은 시험 스크립트를 두 번 돌렸고 PID와 임시 폴더 이름을 지우면 출력이 같았다. 메모에는 당시 환경이 적혀 있지 않아서, 그 증상이 어디서 났는지는 이 시험으로 설명되지 않는다. 이 맥의 기본 동작에서는 재현되지 않았다는 데까지만 말할 수 있다.

설명은 이 맥의 man pgrep에 있다. -a는 상위 프로세스를 결과에 포함시키는 옵션이고, 기본값은 현재 pgrep 프로세스와 그 모든 상위 프로세스를 제외한다고 적는다. man 문장대로라면 대기 스크립트를 실행한 셸과 그 위의 모든 상위 프로세스가 기본으로 빠진다. 이 글의 시험으로 확인한 것은 대기 스크립트 자신(직계 부모)이 빠진다는 데까지다.

-a 를 주면 설명 그대로 걸린다

같은 스크립트에 -a를 붙이면 상황이 바뀐다.

/tmp/wait.sh -fa nightjob-4271

3초 안에 안 끝났고 매칭된 것은 /bin/bash /tmp/pgrep-lab.…/wait.sh -fa nightjob-4271 한 줄, 곧 대기 스크립트 자신이었다(내 시험 스크립트가 만든 임시 폴더 경로라 위에서 저장한 /tmp/wait.sh로 돌리면 경로만 다르게 나온다). 대기 스크립트가 -a를 쓰고 패턴이 그 스크립트의 명령줄에 들어 있다면 워커가 없어도 이 줄 때문에 루프가 안 끝난다.

흔한 처방인 패턴의 한 글자를 대괄호로 감싸는 방법도 시험했다. [n]ightjob-4271은 정규식으로는 nightjob-4271과 같은 문자열을 찾지만, 명령줄에 적힌 글자 [n]ightjob-4271 자체에는 매칭되지 않는다. 스크립트 이름에 패턴이 없을 때는 -fa로도 루프가 폴링 0회에 끝났다. 그러나 스크립트 파일 이름이 wait-nightjob-4271.sh처럼 패턴을 포함하면 다시 걸렸다. 괄호는 패턴 인자만 감추지 파일 이름은 감추지 못한다.

Linux 쪽은 공개 매뉴얼의 문장만 확인했다. procps-ng의 pgrep(1)은 “The running pgrep, pkill, or pidwait process will never report itself as a match.“라고 적고, 따로 --ignore-ancestors(“Ignore all ancestors of pgrep, pkill, or pidwait.”) 옵션을 둔다. 이 옵션이 있다는 것만 확인했고, Linux에서 상위 셸이 실제로 걸리는지는 시험하지 못했다.

tail -f 와 정규식 점은 루프를 붙잡을 수 있었다

맥의 pgrep -f는 기본으로 자기 자신과 상위 프로세스를 빼 준다. 내가 만든 시험 상황에서 루프를 붙잡은 것은 tail -f와, 정규식의 . 때문에 매칭된 다른 작업이었다. 둘 다 일부러 심은 상황이고(이 두 시험은 위의 /tmp/wait.sh가 아니라 같은 조건을 거는 시험 스크립트 안의 함수로 돌렸다), 실제 사고를 재현한 것이 아니다.

첫째, 작업 로그를 보려고 tail -f 를 띄워 둔 경우다. 로그 경로에 작업 이름이 들어 있으면 그 tail의 명령줄이 패턴과 맞는다. 워커가 없는데도 3초 안에 안 끝남이 나왔고 매칭된 것은 tail -f /tmp/pgrep-lab.…/nightjob-4271.log 한 줄이었다. tail을 종료하자 같은 패턴이 바로 비었다. tail은 대기 스크립트의 상위 프로세스가 아니라서 기본 제외에 걸리지 않는다.

둘째, 패턴의 .이다. 점은 프로세스가 아니라 패턴 문자이고, 그 점 때문에 매칭된 것이 다른 작업이다. pgrep의 패턴은 정규식이라 .은 임의의 한 글자다. nightjob.4271로 찾으면 이름이 nightjob_4271.sh인 다른 작업까지 걸려서, 정작 기다리던 작업이 없는데도 루프가 끝나지 않았다. nightjob-4271로 쓰면 그 다른 작업은 걸리지 않았다.

시험(안 끝남은 3초 상한에서 중단한 결과)	명령(대기 루프의 조건)	결과
기준선: 워커가 2초 일함	pgrep -f nightjob-4271	워커 PID 매칭, 폴링 4회 뒤 종료
패턴이 인자와 파일 이름에 있음, 워커 없음	pgrep -f nightjob-4271	폴링 0회에 종료
같은 상황에서 상위 프로세스 포함	pgrep -fa nightjob-4271	대기 스크립트 자신이 걸려 안 끝남
같은 상황, 괄호 패턴, 스크립트 파일 이름에 패턴 없음	pgrep -fa '[n]ightjob-4271'	폴링 0회에 종료
같은 상황, 괄호 패턴, 파일 이름에 패턴 있음	pgrep -fa '[n]ightjob-4271'	안 끝남
워커 없고 tail -f 로그 가 살아 있음	pgrep -f nightjob-4271	tail 이 걸려 안 끝남, tail 종료 뒤 종료
워커 없고 nightjob_4271.sh 가 도는 중	pgrep -f 'nightjob.4271'	그 작업이 걸려 안 끝남
같은 상황, 점 대신 하이픈	pgrep -f 'nightjob-4271'	폴링 0회에 종료

이 표에서 내가 세운 해석은 이렇다. 이 맥에서 pgrep -f 대기 루프가 안 끝날 때 의심할 후보는 -a 옵션, 같은 문자열을 명령줄에 가진 다른 프로세스, 정규식 문자다. 시험한 경우가 직접 만든 상황 몇 개뿐이라 어느 쪽이 더 흔한지 비율은 모른다.

반대로 일찍 끝나는 경우

-f를 빼면 문제가 반대로 난다. 스크립트를 실행한 워커를 pgrep nightjob-4271.sh로 찾으면 워커가 살아 있는데도 아무것도 나오지 않았다(kill -0으로 확인하면 살아 있었다). pgrep은 -f가 없으면 프로세스 이름만 보는데, ps로 보면 스크립트 워커의 이름은 /bin/bash이고 스크립트 경로는 인자에 있다. 같은 워커에 pgrep -f nightjob-4271.sh는 종료 코드 0, -f 없는 쪽은 1이었다. 그래서 until ! pgrep nightjob-4271.sh; do … 는 조건이 처음부터 참이라 대기 없이 다음 단계로 넘어갈 것이다. 이 루프를 직접 돌려 본 것은 아니고 종료 코드 1에서 따진 결과다. 확인한 워커도 #!/bin/bash로 시작하는 스크립트 하나뿐이어서, 인터프리터 없이 직접 실행되는 바이너리는 -f 없이도 이름으로 잡힐 수 있다(이 추측은 시험하지 않았다).

Linux의 매뉴얼은 이름 매칭에 길이 제한도 있다고 적는다. “The process name used for matching is limited to the 15 characters present in the output of /proc/pid/stat.” 이 맥의 man pgrep은 “Without -f names over 19 characters will silently fail”이라고 적는다. 15자와 19자로 숫자가 다르니 Linux의 숫자를 이 맥에 그대로 옮기지 말고, 긴 이름은 이 맥에서도 -f로 찾는 것이 안전하다고만 알아 두자. 19자 제한 자체는 시험하지 않았다.

문자열을 버리고 PID로 기다린다

문자열 매칭의 함정이 이만큼이면 PID를 직접 쥐는 쪽이 안전하다. 작업을 내 스크립트가 띄웠다면 $!로 PID를 받아 wait을 쓴다.

./nightjob.sh & job=$!
wait "$job"; echo "종료 코드 $?"

시험에서 wait은 워커가 끝날 때까지 기다렸다가 종료 코드 0을 돌려줬다. 내 자식이 아니라 다른 곳에서 띄운 같은 사용자의 작업이면 PID만 알면 kill -0으로 살아 있는지를 본다(시험은 같은 셸의 서브셸에서 한 것이다).

while kill -0 "$pid" 2>/dev/null; do sleep 1; done

이 루프도 워커가 끝나자 종료했다. 작업이 PID를 파일에 쓴다면 pgrep -F 파일도 된다. 워커가 살아 있을 때는 파일의 PID를 출력했고, 끝난 뒤에는 출력 없이 종료 코드 1이었다. 이 종료 코드는 until ! pgrep -F 파일 >/dev/null; do sleep 1; done 같은 루프 조건에 쓸 수 있는 모양이다(이 루프 자체를 돌려 보지는 않았다).

시험하지 않은 것도 적는다. PID가 재사용되는 경우, 부모가 회수하지 않은 좀비 프로세스에 대한 kill -0, 내 자식도 형제 서브셸도 아닌 완전히 무관한 프로세스에 대한 kill -0(kill -0은 권한이 없는 다른 사용자의 프로세스에는 실패로 답하므로 루프가 일찍 끝날 위험이 있다. 이 부분은 시험하지 않고 알려진 동작을 적은 것이다), Linux의 pgrep, bash 4 이상, 다른 macOS 버전이다. 셸은 bash 3.2 스크립트로만 시험했다.

안 끝나는 루프에서 먼저 할 일

대기 루프가 안 끝나면 조건을 바꾸기 전에, 루프 조건에 쓴 것과 같은 옵션에 -l만 더해 출력해 본다. 이 명령은 멈춘 루프 바깥의 다른 터미널이 아니라 대기 스크립트 안(루프 바로 앞이나 while 안)에서 돌려야 한다.

pgrep -l 루프에_쓴_옵션 패턴

밖에서 따로 치면 대기 루프 자신이 같이 찍힌다. 루프 안의 pgrep은 대기 스크립트를 상위 프로세스로 보고 기본으로 빼지만, 바깥 터미널의 pgrep에게 그 스크립트는 상위가 아니라서 빠지지 않는다. 이 점은 내 시험으로 직접 재현하지는 않았고 상위 제외 규칙에서 이끌어 낸 해석이다.

나온 줄을 보고 가른다. 기다리던 작업이면 작업이 아직 도는 것이다. tail이나 편집기 같은 다른 명령이면 패턴이 넓다. 대기 스크립트 자신이나 그 상위의 셸이 찍히면 -a를 쓰고 있을 수 있다. 기본 옵션인데도 상위 셸처럼 보이는 줄이 나온다면, 그것이 정말 상위 프로세스인지부터 의심한다. 기본 동작은 상위 프로세스를 빼므로 실행 도구가 따로 띄운 래퍼 같은 다른 프로세스일 수 있다. 괄호 요령은 자기 명령줄의 패턴 글자만 가리고, 상위 프로세스의 명령줄에 평문으로 든 패턴은 못 가린다. bash -c 'echo 패턴 …; pgrep -fal "[n]패턴"' 모양으로 돌려 보니 bash -c 쪽이 걸렸다. 아무것도 안 나오는데 작업이 살아 있다면 -f를 빠뜨렸거나, 패턴의 오타, 이름 불일치, 긴 이름 제한을 의심한다. 내가 시험한 것은 이 가운데 -f 누락뿐이다.

Linux나 다른 실행 도구에서는 상위 셸이 걸릴 수도 있다. 그 가능성의 근거는 --ignore-ancestors 옵션이 있다는 사실뿐이고 시험하지 않았다. 원인이 어느 쪽이든 마지막 해결은 같다. 작업을 직접 띄울 수 있으면 PID를 잡고, 아니면 PID 파일을 받는다.

세 줄 요약

• 이 맥(26.6.2)의 pgrep은 기본으로 자기 자신과 상위 프로세스를 제외하고, 직접 만든 시험 상황에서는 -a를 쓰면서 패턴이 대기 스크립트 명령줄에 있을 때, tail -f, 정규식 점이 루프를 멈췄다. 흔한 정도는 모른다.
• -f를 빼면 bash 스크립트 워커를 찾지 못해(종료 코드 1) until 루프는 대기 없이 일찍 끝날 것이다. 이 루프는 돌려 보지 않았다.
• 안 끝나면 pgrep -l 로 매칭된 줄을 먼저 보고, 가능하면 문자열 대신 PID를 쥐고 wait, kill -0, pgrep -F 중 하나로 기다린다.