온 man 페이지 , 그냥 말한다 :
-m 작업 제어가 활성화되었습니다.
그러나 이것이 실제로 무엇을 의미합니까?
나는 SO 질문 에서이 명령을 보았습니다. OP와 같은 문제가 있습니다. “직물은 바람둥이를 시작할 수 없습니다”. 그리고 set -m이것을 해결했습니다. OP는 조금 설명했지만 잘 모르겠습니다.
이 명령은 백그라운드 작업에서 발생했으며 명령이 종료되면 종료됩니다.
해결책은 간단합니다. “set -m;”만 추가하면됩니다. 명령 앞에 접두사.
답변
bash 문서 인용 (에서 man bash) :
JOB CONTROL
Job control refers to the ability to selectively stop
(suspend) the execution of processes and continue (resume)
their execution at a later point. A user typically employs
this facility via an interactive interface supplied jointly
by the operating system kernel's terminal driver and bash.
따라서 set -m(대화식 쉘의 기본값)을 사용하면 fgand와 같은 내장 기능을 사용할 bg수 있으며 set +m(비 대화식 쉘의 기본값)에서 비활성화됩니다 .
그것은 연결이 작업 제어 및하지만, 출구의 백그라운드 프로세스를 죽이는 사이에 무엇을 나에게 분명 아니지만, 나는 일이 있음을 확인할 수 있습니다 실행 set -m; (sleep 10 ; touch control-on) &한 입력이 명령 한 후 쉘 권리를 종료하지만, 경우 파일을 만듭니다 set +m; (sleep 10 ; touch control-off) &하지 않습니다.
대답은 다음 문서의 나머지 부분에 있다고 생각합니다 set -m.
-m Monitor mode. [...] Background pro‐
cesses run in a separate process group and a line con‐
taining their exit status is printed upon their comple‐
tion.
이것은 시작된 백그라운드 작업 set +m이 실제 “백그라운드 프로세스”가 아님을 의미합니다 ( “백그라운드 프로세스는 프로세스 그룹 ID가 터미널의 프로세스 그룹과 다릅니다”). 즉, 자체 프로세스를 시작하지 않고이를 시작한 쉘과 동일한 프로세스 그룹 ID를 공유합니다. 적절한 백그라운드 프로세스와 같은 프로세스 그룹. 이것은 셸이 일부 백그라운드 작업 전에 종료 될 때 관찰 된 동작을 설명합니다. 올바로 이해하고 종료하면 셸과 동일한 프로세스 그룹의 프로세스로 신호가 전송 set +m되지만 백그라운드 작업 종료는에서 시작됩니다 ) 다른 프로세스 그룹의 사람들에게 (따라서 진정한 백그라운드 프로세스 만 남겨 두십시오 set -m).
따라서 귀하의 경우 startup.sh스크립트는 백그라운드 작업을 시작합니다. 이 스크립트가 링크 된 질문에서와 같이 SSH를 통해와 같이 비 대화식으로 실행되면 작업 제어가 비활성화되고 “백그라운드”작업이 원격 쉘의 프로세스 그룹을 공유하므로 쉘이 종료되는 즉시 종료됩니다. 반대로, 해당 쉘에서 작업 제어를 사용하면 백그라운드 작업이 자체 프로세스 그룹을 획득하고 상위 쉘이 종료 될 때 종료되지 않습니다.
답변
나는 이것을 github 이슈 목록에서 찾았으며 이것이 실제로 귀하의 질문에 대답한다고 생각합니다.
실제로 SSH 문제는 아니며 BASH 비 대화식 / 대화식 모드와 프로세스 그룹에 대한 신호 전파에 대한 미묘한 동작입니다.
다음은 /programming/14679178/why-does-ssh-wait-for-my-subshells-without-t-and-kill-them-with-t/14866774#14866774
및 http를 기반으로합니다
. //www.itp.uzh.ch/~dpotter/howto/daemonize ( 일부 가정은 완전히 검증되지는 않았지만 이것이 어떻게 작동하는지 테스트).pty / tty = 거짓
시작된 bash 쉘은 시작된 프로세스의 stdout / stderr / stdin에 연결되며 소켓에 연결된 것이없고 자식이 종료 될 때까지 계속 실행됩니다. 좋은 데몬 프로세스는 자식이 종료 될 때까지 기다리지 않고 자식 프로세스를 분기 한 다음 종료합니다. 이 모드에서는 SSH를 통해 SIGHUP이 하위 프로세스로 전송되지 않습니다. 나는 이것이 스스로 deamonizing을 처리하고 백그라운드가 필요없는 프로세스를 실행하는 대부분의 스크립트에서 올바르게 작동한다고 생각합니다. init 스크립트가 프로세스를 백그라운드 화하기 위해 ‘&’를 사용하는 경우 주된 문제는 백그라운드 프로세스가 stdin에서 읽으려고 시도하는지 여부입니다. 세션이 종료되면 SIGHUP을 트리거하기 때문에 stdin에서 읽습니다.
pty / tty = true *
init 스크립트가 프로세스가 시작된 백그라운드를 배경으로하는 경우, 상위 BASH 쉘은 종료 코드를 SSH 연결로 리턴하며, 이는 하위 프로세스가 종료되기를 기다리지 않고 stdout에서 차단되지 않기 때문에 즉시 종료되는 것으로 보입니다. / stderr / stdin. 이로 인해 SIGHUP이 상위 bash 쉘 프로세스 그룹으로 전송됩니다. bash의 비 대화식 모드에서 작업 제어가 사용 불가능하므로 방금 시작한 하위 프로세스가 포함됩니다. 분기 또는 분기 프로세스에서 데몬 프로세스가 새 프로세스 세션을 명시 적으로 시작하는 경우 해당 하위 프로세스는 BASH 상위 프로세스 종료로부터 SIGHUP을받지 못합니다. 이는 SIGTERM이 표시되는 일시 중단 된 작업과 다릅니다. 나는이 작업에 대한 문제가 때로는 약간의 경쟁 조건과 관련이 있다고 생각합니다.
http://www.itp.uzh.ch/~dpotter/howto/daemonize 에서 코드에서 새 세션이 분기 프로세스에 의해 생성되어 부모가 종료되기 전에 실행되지 않을 수 있으므로 임의의 결과가 발생 함을 알 수 있습니다. 위에서 언급 한 성공 / 실패 행위. 수면 명령문은 분기 프로세스가 새 세션을 작성하기에 충분한 시간을 허용하므로 일부 경우에는 작동합니다.pty / tty = true이고 bash에서 작업 제어가 명시 적으로 사용 가능합니다.
SSH는 bash 쉘 또는 시작된 하위 프로세스의 stdout / stderr / stdin에 연결되지 않으므로 상위 bash 쉘이 요청 된 명령 실행을 시작하자마자 종료됩니다. 이 경우, 작업 제어가 명시 적으로 사용 가능한 경우, bash 쉘에 의해 시작된 모든 프로세스는 ‘&’로 시작하여 즉시 별도의 세션에 배치되며 BASH 세션에 대한 상위 프로세스가 종료 될 때 SIGHUP 신호를 수신하지 않습니다 ( 이 경우 SSH 연결).
고치는 데 필요한 것
백그라운드 프로세스 / 서비스를 사용할 때 특별한 경우로 실행 / 스도 운영 문서에서 솔루션을 명시 적으로 언급하면된다고 생각합니다. 기본적으로 ‘pty = false’를 사용하거나 불가능한 경우 작업 제어를 첫 번째 명령으로 명시 적으로 사용 가능하게 설정하면 올바르게 작동합니다.
에서 https://github.com/fabric/fabric/issues/395
