특정 내부 개발 프로세스에서는 nohup이 작동하지 않는 이유는 무엇입니까?
나는 그것을 다음과 같이 사용합니다 :
/usr/bin/nohup process_a &
실행된 터미널을 닫고 ps를 통해 아직 실행 중인지 확인할 수 있습니다. 그러나 로그아웃했다가 다시 로그인하면 프로세스가 더 이상 실행되지 않습니다.
내부적으로 개발된 다른 process_b에서 동일한 nohup 명령을 실행할 수 있으며 로그아웃했다가 다시 로그인해도 프로세스가 종료되지 않습니다. 아직 실행 중입니다.
process_a가 로그아웃했다가 다시 로그인해도 살아남지 못하도록 하는 "특별한" 것이 무엇인지 궁금합니다. 프로세스 a와 b는 모두 TCP 서버 소켓을 열고 로깅을 위해 파일 설명자를 엽니다.
나는 동일한 결과로 bash, tcsh 및 zsh 쉘을 사용해 보았습니다.
nohup에서 실행되는 한 프로세스는 로그아웃/로그인 상태에서 유지되지만 다른 프로세스는 유지되지 않는 이유는 무엇입니까? 개발자가 코드에서 뭔가를 변경할 수 있다고 가정합니다.
우리는 상당히 제한적인 환경에서 RHEL 6을 실행하고 있습니다(screen, tmux 등은 대안으로 사용할 수 없음).
고쳐 쓰다:
process_a가 살아남는다
kill -s HUP PID
따라서 이 경우 SIGHUP은 nohup에 의해 성공적으로 처리된 것으로 보입니다. 하지만 로그아웃하면 여전히 죽습니다.
답변1
process_a의 코드가 명시적으로 SIGHUP(hangup 신호)을 포착하거나 기본 핸들러(즉, 없음, 즉 종료)로 재설정한 경우 이는 현재 보고 있는 동작을 설명합니다. 개발자는 코드를 검색하여 SIGHUP코드가 수행하는 작업을 확인하라는 요청을 받습니다.
그러나 사용할 수 없는 strace"상당히 제한적인 환경"이 있으므로 프로그램에서 실행할 수 있으면 이를 더 잘 진단할 수 있습니다 . strace더 빠르게 테스트하고 더 실행 가능한 포렌식 결과를 생성할 수 있는 경우
- 프로세스 시작(
nohup process_a &), - 보고된 PID를 기록해 두십시오.
- 몇 초, 몇 분만 기다리세요.
- 프로세스가 알려진 PID로 실행되고 있는지 확인합니다(예
ps: - 하다,
kill -HUP PID - 프로세스를 다시 확인하세요.
- 몇 초 또는 몇 분 정도 기다린 후 프로세스를 다시 확인하세요.
답변2
nohup에서 실행될 때 프로세스가 로그아웃/로그인을 유지할 수 없는 구체적인 이유는 Motif를 활용하기 때문입니다. 이 프로세스의 컨텍스트에서는 GUI가 호출/구현되지 않지만 코드는 main()(c 코드)에서 XtAppMainLoop를 사용하게 됩니다. 어쩌면 Motif 라이브러리가 신호로 뭔가를 할 수도 있습니다.
다른 답변/의견에 제안된 다른 이유:
프로세스가 명시적으로 SIGHUP을 포착/재설정합니다.
프로세스는 tty 장치를 사용합니다.