ウィンドウマネージャーから起動したアプリケーションからの出力はどこに行きますか?


10

端末からアプリケーションを起動すると、stdoutとstderrへの出力が表示されますが、アプリケーションがウィンドウマネージャーから起動された場合、これらのファイルへの出力は通常どこに行きますか?/ dev / nullに?


1
提案:ps fauxプロセスに関連付けられているtty / ptsを確認するために使用します。なしまたは「?」の場合 それはおそらく空洞で失われるでしょう。(これは単なるアイデアです。間違っている可能性があります)
mveroone 2013

@クワイオ:値は疑問符(?)なので、あなたが言うように、それはおそらく空で失われます。
8月のカールストロム2013

2
グラフィカルシェルをgdmまたはkdmから起動した場合、出力は次の場所にあります~/.xsession-errors
Shadur

回答:


8

ウィンドウマネージャから起動されたアプリケーションの出力は、ウィンドウマネージャ自体からの出力と同じ場所に送られます。(アプリケーションがリダイレクトしない限り、通常のGUIアプリケーションはリダイレクトしません。)

ファイル記述子1(標準出力)とファイル記述子2(標準エラー)で開かれているWMを見れば、WMの出力先がわかります。通常、両方とも同じファイルに移動します。ウィンドウマネージャのプロセスIDを調べます(例えば試すpgrep metacitypidof metacityのMetacityがあなたのウィンドウマネージャである場合-あなたはウィンドウマネージャのプロセス名がわからない場合、プロセスツリーの一つの根を見てから報告されps fたりpstree)。ウィンドウマネージャーのプロセスIDが1234であるとすると、次のコマンドを実行します。

lsof -p1234

そして、ファイル記述子1と2に対応する行を探します。

または

ls -l /proc/1234/fd

関連するファイル記述子のフィルタリングを自動化できます。

lsof -p1234 | awk '$4 ~ /^[12][^0-9]/'
ls -l /proc/1234/fd/[12]

(注:上記のすべてのコマンドはLinux pgrep用です。他のuniceの間で共通であり、lsofほとんどどこにでもインストールできます。psオプションと/proc内容は、異なるunice間で異なります。)

ターミナルエミュレーターで実行されているシェルからコマンドを実行している一般的な状況(xterm、konsole、gnome-terminalなど。ただし、画面またはtmuxで使用する場合は不可)では、ターミナルエミュレーターの出力の場所を簡単に確認できます。ターミナルエミュレータはシェルの親プロセスであるため、端末エミュレーターが追加の特権で実行されている場合、これは機能しません。これは、一部のシステムでは、端末エミュレーターがログインユーザーリスト(utmp)に書き込みできるようにするために発生します。

lsof -p$PPID
ls -l /proc/$PPID/fd

多くのディストリビューションは、Xセッションの出力をに送信し~/.xsession-errorsます。


私の場合、WMから始まる子と親の階層はブラックボックス<-lightdm <-lightdm <-initであり、すべてのttyの値は "?"です。出力はどこにも行きません。
8月カールストロム2013

@AugustKarlstromその後、pidof blackboxまたはpgrep blackboxウィンドウマネージャのPIDを取得するために、または直接lsof -p$(pidof blackbox)。Ttyはこれとは何の関係もありません。
Gilles「SO-邪悪なことをやめなさい」2013

1
ああ、もちろん。このコマンドls -l /proc/<blackbox-id>/fdは、stdoutがに移動し/dev/null、stderrがに移動することを教えてくれ~/.xsession-errorsます。
8月カールストロム

1

ウィンドウマネージャーはXサーバーの子であるため、ウィンドウマネージャーとその子の出力はXサーバーと同じ場所に送られます。

自分が唯一のユーザーであり、グラフィカルにログインする場合、一部のシステムはXサーバーインスタンスを出力コンソールから置き換えます。つまり、そのVTに切り替えてそれを表示できます。事例として、通常の配置はalt-ctrl-f1Xインスタンスの出力コンソールでalt-ctrl-f7あり、Xディスプレイですが、確認できる限りいくつでもチェックできます。最初の6つは通常、ログインを生成しますが、実際には生成せず、空白またはパイプ出力で表示される可能性があります。initからの出力の一部があるかもしれませんが、Xからの出力と混同しないでください。私の経験では、Xと子供は常にかなりの量の警告とメッセージを表示します(フォントの欠落、呼び出しの減価など)。

GUI経由でログインしない場合は、Xを起動したVTになります。これは、終了するまで表示されないため問題です。GUIログインでは、XDM(グラフィカルログイン)は特権プロセスとして実行されるため、出力をにパイプすることができます/dev/tty7startx 1>&2> /dev/tty7適切なスーパーユーザー権限があれば、()もできます。


1
直接startxまたはxinit直接の場合、~/.xinitrc必要なexecウィンドウマネージャーで実行する前に、必要に応じて常にリダイレクトを行うことができます。私自身、この種の出力を見逃したことはありません。GUIアプリケーションが生成しているものに興味がある場合は、ターミナルから実行します。しかし、実際にはそれが役立つかもしれないので、私はstdoutとstderrを~/.xinitrcにリダイレクトしました~/.xinitrc.out
ミロスラフコシュカール2013

0

あなたが取る場合はその典型的には、1つのプログラムでは、一連の操作を実行して別のを開始man 2 forkし、man 2 execve記述子が開いたままに、デフォルトのファイルで、そのプロセスで、その後。

したがって、答えは、通常、出力/エラーは親プロセスの出力/エラーが分岐時間を指していたところに行きます(もちろん、親プログラムがいくつかのリダイレクトを行わない限り)。親プログラムの名前が正確にわからない限り、これ以上具体的なことはできないと思います。ウィンドウマネージャープロセスは、他のプログラムを直接起動することはほとんどありません。

例えば私の場合

  • Ctrl + P(xmonadウィンドウマネージャーで処理)を押すと起動しますdmenu_run
  • dmenu_run私の入力を処理し、いくつかのアプリケーションを起動します(例。xkill

出力は、に行きます/dev/tty1ので、

  • xkill によって開始されました dmenu_run
  • dmenu_run によって開始されました xmonad
  • xmonad によって開始されました X
  • X によって開始されました startx
  • startx 最初の仮想コンソールから手動で開始した /dev/tty1

参考までに、出力/エラーがどこに行くのかを見つけたい場合、または特定のプロセス(既知のPIDを持つ)に対して開かれたファイル記述子は何かをよりよく言いたい場合は、

$ lsof -p PID
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.