
tty1 で実行すると、ps aux
Xorg がプロセスとしてリストされませんが、次のようなコマンドはkillall Xorg
正常に動作します。なぜ ps で Xorg がリストされないのでしょうか?
答え1
プロセスのコマンド ラインには実際には が表示されX
、 は表示されませんXorg
。
$ ps aux | grep -w X
muru 14702 0.0 0.0 15940 956 pts/6 S+ 12:33 0:00 grep -w X
root 30664 1.9 1.6 690024 136632 tty7 Ssl+ Jun16 215:33 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
$ pgrep X -a
30664 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
興味深いことに、pgrep Xorg
同じプロセスを返します。
$ pgrep Xorg -a
30664 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
さらに興味深いのは、拡大する pgrep
の検索条件は機能しません:
$ pgrep Xorg -fa
$
それの訳はX
(/usr/bin/X
)はラッパーであり、Xorg
. 私はそう信じていますが、確信はありません。exec
s なので、ps
表示されるコマンド ラインは変更されず、プログラムが異なります。これは、プロセスの/proc
ディレクトリを調べることで確認できます。
$ sudo ls -l /proc/30664/exe
lrwxrwxrwx 1 root root 0 Jun 24 08:09 /proc/30664/exe -> /usr/bin/Xorg
これが、pgrep Xorg
と がkillall Xorg
機能するがpgrep -f Xorg
失敗する理由です。pgrep -f
はコマンド ラインを検索しますが、 ではX
なく が依然として表示されますXorg
。そのため、通常はより良い結果を返すはずのアクションが、実際にはより悪い結果をもたらします。
確かにX
そうだと思いますexec
。このSOの答え:
$ nm -D /usr/bin/X | grep exec
U execv