[解決済み] [Solved] nohup.outを取得せずにnohupコマンドを使用するにはどうすればよいですか？

質問

nohupコマンドで問題が発生しました。

ジョブを実行すると、データが大量にあるんです。出力されるnohup.outが大きくなりすぎて、プロセスが遅くなってしまいます。どうすればnohup.outを出さずにこのコマンドを実行できるでしょうか？

解決方法を教えてください。

その nohup コマンドは nohup.out の場合、出力はターミナルに送られます。コマンドの出力を他の場所にリダイレクトしている場合 - たとえば /dev/null - が代わりに表示されます。

 nohup command >/dev/null 2>&1   # doesn't create nohup.out

もし、あなたが nohup ということは、バックグラウンドでコマンドを実行するために、別の & を全体の末尾につけています。

 nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out

Linuxでは、ジョブを実行する際に nohup は自動的にその入力も閉じます。 他のシステム、特にBSDやmacOSではそうではないので、バックグラウンドで実行する場合は、入力を手動で閉じたいかもしれません。入力を閉じても nohup.out バックグラウンドのプロセスが標準入力から何かを読み込もうとした場合、そのプロセスは一時停止し、あなたがそれをフォアグラウンドに戻して何かを入力するのを待ちます。つまり、エクストラセーフバージョンは次のようなものです。

nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal 

ただし、これはコマンドが直接ターミナルにアクセスするのを防いだり、シェルのプロセスグループから削除したりするものではないことに注意してください。後者を行いたい場合、bash、ksh、zsh を実行している場合は disown を引数なしで次のコマンドとして実行します。これにより、バックグラウンド・プロセスはもはやシェルの "job"に関連づけられず、シェルからいかなるシグナルも転送されなくなります。(区別に注意してください。 disown 親シェルから自動的に転送されるシグナルはありません。 nohup を受信します。 HUP 信号が送信されます。 kill コマンドを使用します。 A nohup のプロセスは、すべての HUP シグナルがどのように送信されたとしても、です)。

説明する。

Unixyシステムでは、すべての入力元または出力先には、quot;ファイル記述子、略してquot;fd;と呼ばれる、それに関連する番号があります。実行中のプログラム（"process"）は、それぞれ独自のファイル記述子を持ち、新しいプロセスが起動したときには、すでに3つのファイル記述子が開いています： fd 0 である "standard input" は、プロセスが読み込むために開いており、 "standard output" (fd 1) と "standard error" (fd 2) はプロセスが書き込むために開いています。ターミナルウィンドウでコマンドを実行する場合、デフォルトでは、入力したものはすべてその標準入力に送られ、標準出力と標準エラーは両方ともそのウィンドウに送られます。

しかし、コマンドを起動する前に、これらのファイル記述子の一部または全部が指す場所を変更するようにシェルに依頼することができます。これは、リダイレクト( < , << , > , >> ) とパイプ ( | ) 演算子で行います。

この中で一番シンプルなのはパイプですが...。 command1 | command2 の標準出力を手配します。 command1 の標準入力に直接フィードする。 command2 . これは、UNIX ツールにおける特定のデザインパターンにつながっている非常に便利なアレンジメントです (そして、標準エラーの存在も説明しています。標準エラーは、プログラムの出力がパイプラインの次のプログラムに入っているにもかかわらず、ユーザーにメッセージを送信することを可能にします)。しかし、標準出力を標準入力にパイプするだけで、他のファイルディスクリプタをパイプに送ることは、多少の工夫をしなければできません。

リダイレクト演算子は、どのファイル記述子をリダイレクトするかを指定できるという点で、より友好的です。 そのため 0<infile という名前のファイルから標準入力を読み込みます。 infile 一方 2>>logfile という名前のファイルの末尾に標準エラーを追加します。 logfile . 番号を指定しない場合、入力リダイレクションのデフォルトは fd 0 ( < と同じです。 0< )、出力リダイレクションはデフォルトで fd 1 ( > と同じです。 1> ).

また、ファイルディスクリプタをまとめることができます。 2>&1 は "標準出力の行き先に標準エラーを送る" を意味します。これは、標準出力と標準エラーが混在した単一の出力ストリームを得ることを意味し、もはやそれらを分離する方法はありません、しかし、それはまた、標準エラーをパイプに含めることができることを意味します。

そこで、シーケンス >/dev/null 2>&1 は、標準出力を /dev/null "（これはあなたが何を書いても捨ててしまう特別なデバイスです） "そして標準エラーを標準出力の行き先に送ります"（これは今確認したところでは /dev/null ). 基本的には、このコマンドがいずれかのファイル記述子に書き込んだものはすべて捨ててください"。

いつ nohup は、標準エラーも出力もターミナルに接続されていないことを検出すると、わざわざ nohup.out しかし、出力はすでにユーザーが望む場所にリダイレクトされていると仮定します。

は /dev/null デバイスは入力にも使えます。 </dev/null この場合、そのコマンドが標準入力から読み込もうとすると、即座にend-of-fileに遭遇することになります。マージ構文は、同じ方向（入力または出力）に開かれている別のファイル記述子を指定するためにのみ機能します。シェルでは、次のようなことができます。 >/dev/null <&1 そのため、単にファイルの終端を叩くのではなく、読み込もうとすると致命的な "無効なファイル記述子" エラーを引き起こします。