迷宮からの脱出：systemdの手順書（.service）を効率よく探すコツ

FedoraなどのLinuxディストリビューションでは、/usr/lib/systemd/system/ の中に数百、数千というファイルが並んでいます。これを一つずつ目視で探すのは非効率です。

ここでは、エンジニアが実践している「お目当てのファイルに最短で辿り着く」ための3つの手法を紹介します。

1. `systemctl status` で「出所」を言わせる

これが最も確実で速い方法です。ファイル名がわからなくても、サービス名さえわかればOSが場所を教えてくれます。

systemctl status keyd

.実行結果

wakaba@fedora ~ % systemctl status keyd          
● keyd.service - key remapping daemon
     Loaded: loaded (/usr/lib/systemd/system/keyd.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2026-03-08 15:07:20 JST; 2h 35min ago
 Invocation: 9965bfdf42334cd39279073d14da50cd
   Main PID: 822 (keyd)
      Tasks: 1 (limit: 9270)
     Memory: 35.9M (peak: 132.4M)
        CPU: 25.766s
     CGroup: /system.slice/keyd.service
             └─822 /usr/bin/keyd

ここをチェック：
出力の3行目あたりに注目してください。
Loaded: loaded (/usr/lib/systemd/system/keyd.service; ...)
この括弧の中にあるパスが、現在実行されている「手順書（ユニットファイル）」の正体です。

2. `grep` で絞り込む

「名前はうろ覚えだけど、それっぽいものを一覧から探したい」という時は、パイプ（|）と grep を使います。

# 全体から "keyd" という文字列を含むファイルだけを抽出
ls /usr/lib/systemd/system/ | grep keyd

# 実行結果例：
# keyd.service

3. マニュアル（man）とプロセス（ps aux）の連携

手順書を見つけた後、そのプログラムが「どの設定ファイルを使っているか」まで知りたい場合は、以下の合わせ技を使います。

① ps aux で「実行時の姿」を見る

ps aux は、現在動いている全プロセスを詳細に表示するコマンドです。
（a: 全ユーザー、u: ユーザー詳細、x: 端末のないサービスも含む）

ps aux | grep keyd

.実行結果

wakaba@fedora ~ % ps aux | grep keyd
root         822  0.2  0.5  40172 40132 ?        SLs  15:07   0:26 /usr/bin/keyd
wakaba     19887  0.0  0.0 231264  2608 pts/0    S+   17:47   0:00 grep --color=auto keyd
wakaba@fedora ~ % man keyd

もし ExecStart=/usr/bin/keyd -c /etc/my-config.conf のように実行されていれば、ここに設定ファイルのパスが表示されます。

② man で「デフォルトの設計」を知る

コマンドラインにパスが表示されない場合は、そのプログラムの「既定の動作」を調べます。

man keyd

CONFIGURATION セクションの記載例:
Config files are stored in /etc/keyd/ and loaded upon initialization.

「あぁ、このツールはオプションを付けなければ /etc/keyd/ を見に行くんだな」と確信が持てます。

まとめ：エンジニアの調査ロジック

systemctl で「手順書（.service）」の場所を特定する。
cat で手順書の中身を見て、特別な設定パスがないか確認する。
man または ps aux で、動いているプログラムの「実態」を裏付ける。

この「逆引き」の習慣がつくと、ブラックボックスだったLinuxシステムが、透明な設計図のように見えてくるはずです。

【番外編】 `man` がない！そんな時のエンジニアの次の一手

man tiny-dfr と打って No manual entry for tiny-dfr と出ても、諦めるのは早いです。マニュアルがないツールの場合、以下の3つの方法で「正解」に辿り着けます。

1. `--help` オプションを試す

ほとんどの Linux プログラムは、引数に -h や --help を付けると、自分自身の使い方や設定ファイルの場所を教えてくれます。

tiny-dfr --help

2. `strings` でバイナリからパスを抽出する

これが一番「エンジニアらしい」泥臭い方法です。プログラムの本体（バイナリファイル）の中に書き込まれている「パスっぽい文字列」を強制的に探し出します。

# バイナリの中に含まれる /etc 関連の文字列を検索
strings /usr/bin/tiny-dfr | grep /etc

もし設定ファイルの場所がプログラム内に直書きされていれば、これで /etc/tiny-dfr/config.toml のような文字列がヒットします。

3. 実行中のファイルを `lsof` で監視する

「今、そのプログラムが実際に開いているファイル」をリアルタイムでリストアップする強力なコマンドです。

# root権限で tiny-dfr が開いているファイルを表示
sudo lsof -p $(pgrep tiny-dfr)

これを使えば、tiny-dfr が起動中にどの設定ファイルを読み込んでいるかが一目瞭然です。

結論：マニュアルがなくても「現場」に答えがある

man はあくまで「説明書」に過ぎません。説明書がなければ、「動いている実体（プロセス）」 や 「プログラムの体（バイナリ）」 に直接聞くのが、エンジニアの最も確実な調査術です。

strings の出力結果をどう読み解くか？

strings コマンドの結果は、プログラム内部のメモリ構造がそのまま露出するため、非常に読みづらいのが普通です。

...略...
/usr/share/tiny-dfr/config.tomlConfigProxyMediaLayerDefault...
...略...
/etc/tiny-dfr/config.tomlsrc/display.rsProperty not found...

【プロの視点：ノイズをフィルタリングする】
エンジニアは、この中から以下の「キーワード」が組み合わさった場所を探します。

/etc/ で始まっているか？（設定ファイルの定位置）
config という単語が入っているか？
.toml などの拡張子で終わっているか？

今回の場合、/etc/tiny-dfr/config.toml という文字列がノイズに挟まって存在していることから、「このツールはこのパスを読みに行くようにプログラミングされている」と確信できるのです。

# 「/etc/」で始まり、何らかの文字が続いて、最後が「.toml」で終わるものだけを抽出
strings /usr/bin/tiny-dfr | grep -E "/etc/.*\.toml"

ただ、実際には.tomlの他にも.confや.rcもありますので。

ヒント：拡張子がわからない時の「欲張り検索」

「.conf か .toml か、あるいは .yaml かわからない...」という時は、以下のようにパイプで grep を繋ぐか、拡張子の候補を並べて検索します。

# よくある拡張子のどれかにヒットすれば表示する
strings /usr/bin/対象のバイナリ | grep -E "\.(conf|toml|yaml|ini|json)$"

このように「予測されるパターン」を網羅することで、未知のツールでも設定ファイルの場所を素早く突き止めることができます。