long_running_proc호스트에 대한 TCP 연결을 사용하여 장기 실행 프로세스가 있다고 가정해 보겠습니다 host.example.com.
운영 체제나 셸은 포그라운드 프로세스와 백그라운드 또는 백그라운드 프로세스로 실행될 때 프로세스를 다르게 처리합니까 screen?
예를 들어:
~ long_running_proc --connect host.example.com
...
그리고
~ screen
~ long_running_proc --connect host.example.com
[ctrl-a] + d
~
그리고
~ long_running_proc --connect host.example.com &
[1] 67539
~
인터럽트나 컨텍스트 전환을 처리하는 데 다른 규칙이 있습니까? 우선순위가 낮나요? 프로세스를 차단/백그라운드로 인해 TCP 시간 초과가 발생할 가능성이 더 높습니까?
답변1
일반적으로 말하자면,기본유일한 차이점은 백그라운드에서 tty에 읽기(또는 쓰기)를 시도하면 SIGTTIN(또는 SIGTTOU) 신호를 수신한다는 것입니다.
우선 순위 또는 더 높은 컨텍스트 전환에 관한 다른 차이점은 screen쉘(또는)이 프로세스의 "좋은" 번호를 변경하거나 특정 CPU에 바인딩하는 등 이와 같은 작업을 수행할 의향이 있는지 여부와 해당 CPU가 이러한 작업을 수행하는지 여부에 따라 달라집니다. 방해를 많이 받습니다. 일반적으로 쉘은 요청되지 않는 한 그러한 작업을 수행하지 않습니다.
TCP 시간 초과 확률이 높을수록 프로세스가하다위의 신호 중 하나에 의해 차단되었습니다(tty 액세스 시도로 인해). 이 경우 네트워크 트래픽을 수신하여 응답할 기회가 없습니다.
생각해 보면 데몬은 아마도 프로세스의 가장 "배경"일 것이며 확실히 2류 프로세스는 아닙니다.
screen분리가 무엇을 하는지 정확히 알 수는 없지만 해당 문서에 따르면 분리된 프로세스는 계속 실행되고 screen 분리된 프로세스는 계속 실행됩니다.그 자체tty이므로 프로세스는 본질적으로 일반 포그라운드 또는 백그라운드 작업과 구별할 수 없이 계속됩니다. 그러나 대화형 터미널은 프로세스의 가상 터미널과 분리되어 있기 때문에 명령을 실행하는 데 어려움이 있습니다. 어느 시점에서 터미널로부터 입력이 필요한 경우 이는 프로세스에 해로울 수 있습니다.