特定の内部開発プロセスではnohupが機能しないのはなぜですか？
私はそれを次のように使用します：
/usr/bin/nohup process_a &
実行された端末を閉じ、psを介してまだ実行中であることを確認できます。ただし、ログアウトして再度ログインすると、プロセスは実行されなくなります。
内部的に開発された他のprocess_bで同じnohupコマンドを実行できます。ログアウトして再ログインしてもプロセスは終了しません。まだ実行中です。
process_aがログアウトしてから再度ログインしても生き残らないようにする「特別な」ものは何ですか？プロセスaとbはどちらもTCPサーバーソケットを開き、ロギングのためにファイル記述子を開きます。
私は同じ結果でbash、tcsh、zshシェルを試しました。
nohupで実行されている1つのプロセスはログアウト/ログインしたままですが、他のプロセスは維持されないのはなぜですか？開発者がコードで何かを変更できるとします。
私たちはかなり限られた環境で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 デバイスを使用します。