"작업"은 더 이상 존재하지 않는 실행 중인 프로세스를 표시합니다.

백그라운드에서 bash를 통해 장기 실행 파이프라인을 실행하고 있습니다.

find / -size +500M -name '*.txt' -mtime +90 |
   xargs -n1 gzip -v9 &

파이프라인의 두 번째 단계는 크고 오래된 파일이 여러 개 있기 때문에 완료하는 데 오랜 시간(시간)이 걸립니다.

대신 파이프라인의 첫 번째 부분이 즉시 완료되고, 파이프라인이 가득 차지 않고 완료되므로 find성공적으로 종료됩니다.

부모 프로세스가 자식 프로세스에 적합한 bash것 같습니다 .wait

find다음 중 하나에 따라 실행되는 (pid 20851)이 없기 때문에 이렇게 말할 수 있습니다 .

     ps alx | grep 20851
     pgrep -l find

좀비 프로세스가 없으며 20851프로세스 ID가 있는 프로세스가 시스템 어디에서도 발견되지 않았습니다.

Bash 내장 기능은 jobs프로세스 ID 없이 작업을 한 줄로 올바르게 표시합니다.

[1]+  Running find / -size +500M -name '*.txt' -mtime +90 | xargs -n1 gzip -v9 &

/bin/jobsOTOH: 우연히 다음과 같은 별도의 작업 제어 명령( )을 발견했습니다 .

[1]+ 20851 Running         find / -size +500M -name '*.txt' -mtime +90
     20852 Running         | xargs -n1 gzip -v9 &

그리고 (잘못) 종료된 20851찾기 프로세스를 "실행 중"으로 표시합니다.

이것은 CentOS(편집: 더 정확하게는: Amazon Linux 2 AMI) Linux에 있습니다. 이는 /bin/jobs두 줄의 스크립트로 밝혀졌습니다 /bin/sh.

#!/bin/sh
builtin jobs "$@"

나는 이것이 나를 놀라게 했다. 다른 프로그램( )에서 시작된 별도의 프로세스는 해당 프로세스가 완료되고 종료되어 좀비 프로세스가 아닌 후에 sh다른 프로그램( )이 관리하는 프로세스의 내용을 어떻게 알 수 있습니까?bash

pid추가: 시스템의 다른 메소드( ps, )가 알 수 없는 pgrep경우 종료된 프로세스(포함)에 대한 세부사항을 어떻게 알 수 있습니까 ?

편집하다:

(1) Billy 삼촌이 댓글에서 지적했듯이 이 시스템에서 /bin/sh및 /bin/bash는 동일하지만( /bin/sh에 대한 심볼릭 링크 /bin/bash) /bin/jobs셔뱅 라인이 있는 스크립트이므로 별도의 프로세스에서 실행됩니다.

(2) 또한 Billy 삼촌 덕분에 번식이 더 쉬워졌습니다. /bin/jobs이것은 붉은 청어입니다. 나는 그것이 출력을 생산하는 것이라고 잘못 생각했습니다. jobs놀라운 출력은 다음과 같이 호출될 때 bash 내장 함수에서 나온 것 같습니다 -l.

$ sleep 1 | sleep 3600 &
[1] 13616
$ jobs -l
[1]+ 13615 Running                 sleep 1
     13616 Running                 | sleep 3600 &
$ ls /proc/13615
ls: cannot access /proc/13615: No such file or directory

따라서 프로세스 13615는 존재하지 않지만 bash 내장 작업 제어에 의해 "실행 중"으로 표시됩니다 jobs -l.

그 존재는 /bin/jobs나를 혼란스럽게 하고, 그것이 범인임에 틀림없다고 생각하고(아니요), 혼란스럽고 의심스러워 보입니다. 나는 그것이 쓸모가 없기 때문에 시스템에서 제거되어야 한다고 생각합니다( sh어차피 호출자의 작업을 표시할 수 없는 별도의 프로세스에서 실행되는 스크립트).