私読む2つのユニットファイルフォルダがあります（ユーザーモードではありません）。
/usr/lib/systemd/system/: units provided by installed packages
/etc/systemd/system/: units installed by the system administrator
これらの理解と矛盾するのは、次の質問に対する答えです。Systemd用の起動スクリプトを作成する方法。何が起こっているのかを理解するために、誰かが欠けている情報を埋めることができますか？ （更新：答えが更新され、私の理解が答えと競合しなくなりました。)
また、スクリプトは/etc/systemd/system/フォルダ内のサブフォルダで構成されているようです。
getty.target.wants
multi-user.target.wants
別の場所で私は別の場所があることを読んだ。これはユーザー固有のサービスのようです。
/usr/lib/systemd/user/ where services provided by installed packages go.
/etc/systemd/user/ where system-wide user services are placed by the system administrator.
~/.config/systemd/user/ where the user puts its own services.
2015年8月31日に更新されました：
他の人の利益のために私が最近質問した関連質問へのリンクは次のとおりです。システムデバイスで実行されているスクリプトをどこに配置する必要がありますか？
答え1
最高の場所システムユニットファイル： /etc/systemd/system
[インストール]セクションの下にターゲットを追加したことを確認してください。詳しくは「どうすればわかりますか？」をご覧ください。 修正する：/usr/local/lib/systemd/system別のオプションです。詳しくは「グレーエリア」をご覧ください。 」
最高の場所ユーザーユニットファイル： /etc/systemd/userまたは、$HOME/.config/systemd/user
権限と状況によって異なります。また、ユーザーサービスは、ユーザーセッションがアクティブなときにのみ実行されます。
事実は、システムユニット（または紹介では「単位構成」と呼ばれる）が次のことを実行できることです。どこかに—手動でシンボリックリンクを作成し、注意事項を理解しているとします。デバイスをsystemctl daemon-reload簡単に見つけることができる場所に配置すると、生活が楽になります。その理由は次のとおりです。
- 標準位置を使用することは、システムジェネレータがその場所を見つけて起動時に簡単にアクティブにすることを意味します
systemctl enable。これは、ユニットがユニット依存ツリー（ユニットキャッシュ）に自動的に追加されるためです。 - 正しい権限を持つユーザーだけが指定された領域に書き込むことができるため、権限について心配する必要はありません。
どうすればわかりますか？
systemctl enable一体シンボリックリンクを作成する場所をどのように知ることができますか？そのセクションの下のデバイス自体にハードコードできます[install]。通常、次のような行があります。
[Install]
WantedBy = multi-user.target
ファイルシステムの事前定義された場所に対応します。これにより、systemctlそのユニットが名前付きユニットファイルセットに依存していることがわかりますmulti-user.target（「ターゲット」は、ユニット依存グループを指定するために使用される用語です。List all groupsを使用できますsystemctl list-units --type target）。ターゲットと共にロードされたユニットファイルグループはtargetname.target.wantsディレクトリに配置されます。これはシンボリックリンク（または実際のもの）でいっぱいのディレクトリです。セクションにあるとされている場合、[Install]そのセクションへのシンボリックリンクがディレクトリにないとロードされませんWantedBy。システムユニットジェネレータが起動時に依存性ツリーキャッシュにユニットファイルを追加すると（ジェネレータを手動でトリガできます）、シンボリックリンクを配置する場所を自動的に知ることができます。この場合、有効にするとディレクトリにあります。multi-user.targetmulti-user.target.wantssystemctl daemon-reload/etc/systemd/system/multi-user.target.wants/
マニュアルの重要なポイント：
他のユニットは、そのユニットのロードパスにないディレクトリからsystemd（「リンク」）にロードできます。 systemctl(1) のリンクコマンドを参照してください。
systemctlで以下を見つけてください。ユニットファイルコマンド
ユニットファイルのロードパス
次の引用の最初の文を読んで理解してくださいman systemd.unit。これは、systemdが別のパスにコンパイルされている場合、ここで説明したすべてのパスが適用されない可能性があるためです。
ユニットファイルは、次の2つの表で説明されているように、コンパイル中に決定された一連のパスからロードされます。以前にリストされたディレクトリのユニットファイルは、リストのサブディレクトリにある同じ名前のファイルを上書きします。
変数が設定されると、
$SYSTEMD_UNIT_PATH変数の内容が単位ロードパスを上書きします。空のコンポーネント（"："）で終わると、$SYSTEMD_UNIT_PATH一般的な単位ロードパスが変数の内容に追加されます。
表1と表2はどちらもman systemd.unit大丈夫です。
システムモードで実行するときにpath（）をロードします--system。
/etc/systemd/systemローカル構成/run/systemd/systemランタイムユニット/usr/lib/systemd/systemパッケージがインストールされる単位（または/lib/systemd/system場合によってはお読みくださいman systemd.unit）
ユーザーモードランタイムロードパス（--user）
の間に違いがありますユーザーごとユニットと全体/グローバルユーザー単位。
ユーザーによって異なります
$XDG_CONFIG_HOME/systemd/userユーザー設定（$XDG_CONFIG_HOME設定中にのみ使用）$HOME/.config/systemd/userユーザー設定（$XDG_CONFIG_HOME設定されていない場合にのみ使用）$XDG_RUNTIME_DIR/systemd/userランタイム単位（$XDG_RUNTIME_DIR設定時にのみ使用）$XDG_DATA_HOME/systemd/userホームディレクトリにインストールされているパッケージ単位（$XDG_DATA_HOME設定時にのみ使用）$HOME/.local/share/systemd/userホームディレクトリにインストールされているパッケージ単位（$XDG_DATA_HOME設定されていない場合のみ使用）
--global(すべてのユーザー)
すべてのユーザーが利用できる組織 - 各ユーザーが所有することを意味します。したがって、管理者が起動時にサービスを有効にしても、各ユーザーはこれらのサービスを停止できます。
/etc/systemd/userすべてのユーザーのローカル構成（systemctl --global enable userunit.service）/usr/lib/systemd/userすべてのユーザーのためにシステム全体にインストールされたパッケージ単位（または/lib/systemd/system場合によってはman systemd.unitを読む）/run/systemd/userランタイムユニット
グレーエリア
一方では、ファイル階層標準（またman file-hierarchy）/etcバイナリを実行しないためのローカル設定を指定します。一方、/usr/local/「ソフトウェアをローカルにインストールするときにシステム管理者が使用する」と指定されています。 （組織の目的だけでなく）すべてのシステム単位ファイルが以下にあると主張するかもしれませんが、/usr/local/lib/systemd/systemこれはパッケージマネージャから来るのではなく、「ソフトウェア」に属する単位ファイルにも当てはまります。システム全体に対応するシステムユーザー単位を含めることができます
/usr/local/lib/systemd/user。
一時的な単位
存在しないもう一つの忘れられた場所！おそらくあまり知られていないプログラムは、systemd-run一時セルを動的に実行するために使用できます。望むよりman systemd-run。
たとえば、明日の午前4時に再起動をスケジュールするには、次の手順を実行します（--force再起動が必要な場合があります）。
systemd-run -u restart --description="Restarts machine" --on-calendar="2020-12-18 04:00:00" systemctl --force reboot
これは一時単位ファイルrestart.serviceとそのタイマーを生成します（--on-calendar生成された一時単位定義に表示されます）。transient=yes
/run/systemd/transient/restart.service
# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Unit]
Description=Restarts machine
[Service]
ExecStart=
ExecStart="/usr/bin/systemctl" "--force" "reboot"
カーネルがすぐに停止するように指示するより危険なdouble forceオプションもあります--force --force（何をしているのかわからない場合は、電源を切るのとほぼ同じですので安全ではありません）。
答え2
/etc/systemd/systemそこがあなたが置いた場所です。あなたのスクリプト、パックマンを置くパックスクリプトから/usr/lib/systemd/system。
発行すると、からまでのシンボリックリンクがsystemctl enable foo.service生成されます。詳しくは、デバイスのロードパスのセクションをご覧ください。/usr/etcman systemd.unit(5)
答え3
systemdがユニットファイルを探す場所を知りたい場合は、次のコマンドが役に立ちます。
使用systemd-analyze注文する:
含めることができるすべてのフォルダユーザー提供する:
ここにユーザー固有の設定を配置できます。
systemd-analyze --user unit-paths
管理ユーザーの場合は、構成を次のフォルダーに配置することをお勧めします（このフォルダーはすべてのユーザーに影響します）。
systemd-analyze --global unit-paths
含めることができるすべてのフォルダシステム提供する:
これには、パッケージマネージャによってインストールされたサービスが含まれる可能性が高く、システム全体に影響を与えます。
systemd-analyze --system unit-paths
望むより：マンページ
答え4
検索パス
systemdこうすれば見物する場所が多くなるsystemctl enable <unit-name>。見つかった場所ごとに内部のどこかに象徴的に接続されています/etc/systemd。
man systemd.unit(5)完全なリストを確認するか、systemd-analyze他の回答で説明されているコマンドを使用できます。次のいずれかの場所にユニットファイルを配置できます。しかし、precedence課に注意を払う必要がありますscope。
Precedence同じ名前のユニットファイルが見つかった場合、systemdは最初にどのフォルダを選択するかを決定します。
Scopeユーザー、グローバル、システムなど。
フォルダの選択
たとえば、単位ファイルをに挿入した場合を~/.config/systemd/user.control使用してそのファイルを有効にする必要がありますsystemctl enable --user <unit-file>。
通常、単位ファイルはサービス用で、サービスは通常ホスト用です。だから私は主にシステム全体にカスタムユニットを作成し、名前/etc/systemd/systemが競合する場合に備えて何よりも優先的に使用しました。
pkg-config systemd --variable=systemdsystemconfdir
pkg-config systemd --variable=systemduserunitdir
pkg-config systemd --variable=systemduserconfdir
私のシステムでは、以下が順番に返されます。
/etc/systemd/system
/usr/lib/systemd/user
/etc/systemd/user