백그라운드 실행과 nohup

터미널 연결이 끊긴 뒤에도 실행하려면

명령 끝에 &를 붙였다는 사실만으로 셸과 터미널의 수명이 분리되지는 않아. 로그아웃 때 SIGHUP을 받거나 표준 입력과 출력이 닫힌 터미널을 계속 가리킬 수 있어. nohup, disown, setsid는 서로 다른 연결을 바꾸므로 어떤 실패를 막으려는지 먼저 정해야 해.

• nohup ./script &: SIGHUP을 무시하도록 시작하고 터미널 출력의 기본 목적지를 바꿀 수 있어.
• ./script & disown: 실행 중인 작업을 현재 대화형 셸의 작업 표에서 떼어 내.
• setsid ./script &: 제어 터미널이 없는 새 세션에서 시작해.

표준 입력과 로그 목적지를 명시해

nohup ./script < /dev/null > out.log 2>&1 &
pid=$!
printf '%s
' "$pid" > run.pid

터미널이 사라진 뒤 입력을 기다리거나 출력 쓰기에 실패하지 않게 작업 성격에 맞는 목적지를 정해. 로그 파일이 무한히 커지지 않게 회전과 보존 정책도 필요해. PID를 저장했다면 나중에 같은 PID가 다른 프로세스에 재사용되지 않았는지 명령과 시작 시각을 함께 확인해.

다시 화면에 붙을 작업과 서비스는 다르게 관리해

사람이 나중에 화면으로 돌아와 대화형으로 확인할 작업은 tmux 세션이 잘 맞아. 부팅 뒤 자동 시작, 실패 재시작, 선언된 환경과 일관된 중지가 필요한 프로세스는 launchd나 systemd 같은 서비스 관리자가 소유해야 해. 단순한 백그라운드 실행을 장기 서비스 계약으로 확대하지 마.

프로세스 존재 여부를 안전하게 확인해

kill -0 "$pid" && echo "process exists or is signalable"
ps -p "$pid" -o pid,lstart,command

kill -0은 실제 신호를 보내지 않지만 성공은 호출자가 해당 PID를 대상으로 삼을 수 있다는 뜻일 뿐이야. 실패는 프로세스가 없거나 권한이 부족한 경우 모두 가능해. 종료하려면 기록한 PID의 명령과 시작 시각이 기대한 작업과 같은지 다시 확인해.

nohup은 재시작 관리자가 아니야

nohup은 HUP 신호 처리와 일부 입출력 기본값을 바꾸지만 프로세스가 실패했을 때 다시 시작하거나 부팅 뒤 복원하지 않아. 종료 상태 회수, 단일 인스턴스 보장, 의존 서비스 순서와 건강 검사는 별도 계약이야. 중요한 작업은 결과를 누가 확인하고 실패를 누가 알릴지도 정해야 해.

살아 있음과 정상 작동을 구분해

PID가 존재해도 작업이 교착됐거나 잘못된 입력을 반복 처리할 수 있어. 최근 로그 시각, 결과 파일 증가, 처리량과 애플리케이션 건강 검사처럼 의미 있는 상태를 함께 봐. 실행 중이라는 운영체제 사실과 요청한 일을 올바르게 수행한다는 애플리케이션 사실은 서로 다른 증거야.