kill이 PID와 작업 번호에 다른 영향을 미치는 이유는 무엇입니까?

kill이 PID와 작업 번호에 다른 영향을 미치는 이유는 무엇입니까?

친구에게 작업 제어권을 보여 주려고 했을 때 예상치 못한 동작이 발생했습니다. 일부 명령의 경우 kill은 작업 번호에서는 작동하지만 프로세스 ID에서는 작동하지 않습니다.

내가 원하는 행동의 예:

user@host:~$ sleep 1h &
[1] 4518
user@host:~$ sleep 2h &
[2] 4519
user@host:~$ kill %2
[2]+ Terminated   sleep 2h
user@host:~$ kill 4518
[1]+ Terminated   sleep 1h

두 경우 모두 수면이 종료됩니다. 하나는 작업 번호를 기반으로 하고 다른 하나는 PID를 기반으로 합니다. 이제 처음에는 cat 명령을 사용하여 이 작업을 시도했지만 예상대로 작동하지 않았습니다.

user@host:~$ cat &
[1] 4521
user@host:~$ cat &
[2] 4522

[1]+ Stopped   cat
user@host:~$ kill %2
[2]+ Terminated   cat
user@host:~$ kill 4521
user@host:~$ jobs
[1]+ Stopped   cat
user@host:~$ kill 4521
user@host:~$ jobs
[1]+ Stopped   cat
user@host:~$ kill %1
[1]+ Terminated   cat

따라서 kill은 내 프로세스의 PID에서는 작동하지 않지만 작업 번호에서는 작동합니다. 나는 이런 일이 일어나서는 안 된다고 생각한다. 왜 그럴까요?

저는 Debian 9와 bash 4.4.12(1) 릴리스를 사용하고 있습니다.

편집: 이 문제를 해결하려고 시도하는 동안 cat의 "중지" 상태로 인해 기본 신호 SIGTERM에 응답하지 않을 수 있다는 것을 깨달았습니다. 그러나 이것이 사실이라면 프로세스 ID 및 작업 번호와 함께 kill 명령이 실패해야 합니다. 그렇지 않습니까?

답변1

kill이러한 경우 내장 함수가 실제로 수행하는 작업은 Bourne Again 쉘 매뉴얼에는 문서화되어 있지 않지만 Z 쉘 및 Korn 쉘 매뉴얼에는 문서화되어 있습니다.

  • 코헨 쉘:
    전송된 신호가 TERM(종료) 또는 (중단)인 경우 HUP작업이나 프로세스가 중지 CONT되면 (계속) 신호가 전송됩니다 .
  • Z 쉘:
    전송된 신호가 KILL또는 가 CONT아니면 CONT작업이 중지될 때 신호가 전송됩니다.

Bourne Again 쉘 매뉴얼은 다음과 같습니다:

전송된 신호가 TERMOR HUP이고 대상 프로세스가 작업의 일부인 경우 CONT작업이 중지되거나 현재 터미널에서 작업 제어를 사용할 수 없을 때 신호가 작업으로 전송됩니다.

그것이 실제로 하는 일이기 때문입니다.

관련 정보