動き

以上
(打ち間違えすぎ)(pgrepは-aがfullなので-lは冗長)

まとめ

(テーブル記法にパイプ使えない)
コマンド毎の不要な出力増加数。
(sudo)は有無が結果に影響しないと考えている部分。

プロセス名を対象とした場合

`ps ax | grep hoge`

grep自身がgrepに引っかかり、+1

`(sudo) ps ax | sudo grep hoge`

grep自身とsudoが引っかかり、+2

`pgrep hoge`

コマンドラインには反応しないので、+0

`sudo pgrep hoge`

コマンドラインには反応しないので、+0

`pgrep -f hoge`

grepと異なり、自身は対象外になるのか、+0

`sudo pgrep -f hoge`

sudoのコマンドラインに反応して、+1

`(sudo) ps ax | sudo grep hoge | (sudo) grep -v grep`

grep -v grepが、sudo grep hoge、grep hoge、grep -v grepを消し、+3 → +0。最後にsudoを付けても同様に+4 → +0(推測)

冗長そうなgrep -v grepが一番安全。
pgrepも-fを付けずプロセス名に限定するならば安全。
だが、引数駆動している場合、ex)php ファイル名
コマンドラインが対象で全体含めて検索したいなら該当してしまう。

メモ

プロセスチェックしませんか。重複起動防止などに。

ps ax | grep hoge
すると、grep hogeしようとしているgrepコマンド自体も引っかかってしまうことは有名。
なので更に
grep -v hogeしたり、
wc -lの結果から1引いたり、
pgrepつかおう！
となります。

一方sudoは、うっかりapacheユーザーで権限エラーが出るのを防いだり、実行コマンドがログとして残ったり、~~パスが通ってなくて死んだり~~おまじない的、セキュリティ的に付与されることがあります。

私もいっとき全部のコマンド呼び出しにsudo追加してくれと言われたり、逆に毎分の処理でログが出過ぎてなんとかして欲しいなどと言われました。

そんなsudoは、あくまでsudoで一コマンド。後続の実行コマンドはというと、

sudo は、コマンドを実行するとき、まず fork(2) を呼び、実行環境を上記のように設定してから、子プロセスで execve システムコールを呼び出す。メインの sudo プロセスは、コマンドが完了するまで wait し、完了したら、コマンドの終了ステータスをセキュリティポリシーの close 関数に渡してから、終了する。
Man page of SUDO

と子プロセスで(sudoなしのコマンドがroot権限で)実行されます。
このことはpsをツリー表示したらわかるんだと思います。

 > sudo ps axf 
.
.
.
11379 pts/1    S      0:07          \_ fish
21115 pts/1    S+     0:00              \_ sudo ps axf
21116 pts/1    R+     0:00                  \_ ps axf
.
.
.

なので、子プロセスが自身のコマンドをリストに表示・検索対象にするかしないかに関わらず、
実行時点で親プロセスのsudoが子プロセスのコマンドを抱えたままプロセスリストに載ってしまい、
場合によっては一つHIT数が増えてしまいます。

ps,pgrepはよく調べず既存のオプションを流用することがあるので(今回まともに調べた)、不要なオプションがあるかもしれないし、そうであるならば外した方が安全そうだ。sudo含めて。

重複起動防止だけだとアドバイザリロックしたいんですが、
実行時間を見たり自殺したり他殺したり¹ロックファイルと併用していたり他の特殊動作があったりそもそもチェック方法何種類も点在してたりとカオスなのでつらい。

参考

PHPでバッチ処理するときの二重起動防止対応の手法をなるべく丁寧にまとめる - Qiita
sudo - Wikipedia
Man page of SUDO
pgrep/pkillを使おう - Qiita
改めてsudoについて調べてみた - Qiita

lessでファイル見てたら殺された。と報告されたこともあった… ↩