man systemd 日本語訳

man systemd で表示されるマニュアルの日本語訳。

名前

systemd, init - systemd システムとサービスを管理するマネージャー。

概要

/lib/systemd/systemd [OPTIONS...]
init [OPTIONS...] {COMMAND}

説明

systemd は、 Linux オペレーティングシステム用のシステムとサービスを管理するマネージャーです。
起動時に最初のプロセスとして(PID 1 として)実行すると、ユーザースペースサービスを起動ならびに管理する init システムとして機能します。

SysV との互換性のために、 systemd が init として呼び出され、 PID が 1 でない場合、 telinit が実行され、すべてのコマンドライン引数が変更されずに渡されます。
つまり、通常のログインセッションから呼び出された場合、 init と telinit はほぼ同等です。
詳細については、 telinit(8) を参照してください。

systemd をシステムインスタンスとして実行すると、 systemd は構成ファイル system.conf および system.conf.d ディレクトリ内のファイルを解釈します。
ユーザーインスタンスとして実行すると、 systemd は構成ファイル user.conf および user.conf.d ディレクトリ内のファイルを解釈します。
詳細については、 systemd-system.conf(5) を参照してください。

オプション

次のオプションが理解されます。

--test

起動シーケンスを決定し、ダンプして終了します。
これはデバッグのみに役立つオプションです。

--dump-configuration-items

理解されたユニット構成アイテムをダンプします。
これにより、ユニット定義ファイルで認識される構成アイテムの簡潔で完全なリストが出力されます。

--dump-bus-properties

公開された bus プロパティをダンプします。
これにより、 dbus に公開されるプロパティの簡潔で完全なリストが出力されます。

--unit=

起動時にアクティブにするデフォルトの単位を設定します。
指定しない場合、デフォルトは default.target です。

--system, --user

• --system の場合、プロセス ID が 1 でなくても、 systemd がシステムインスタンスを実行するように指示します。
  つまり、 systemd は init プロセスとして実行されません。

• --user は反対のことを行い、プロセス ID が 1 であってもユーザーインスタンスを実行します。

通常、 systemd は開始されたモードを自動的に検出するため、これらのオプションを渡す必要はありません。
これらのオプションはほとんど使用されません。
デバッグ用です。
これは、 systemd が --system モードで実行されている完全なシステムの起動と管理はサポートされていませんが、 PID は 1 ではありません。
実際には、 --system を明示的に渡すことは --test と組み合わせた場合にのみ役立ちます。

--dump-core

クラッシュ時にコアダンプを有効にします。
このスイッチは、ユーザーインスタンスとして実行している場合は効果がありません。
この設定は、ブート時に systemd.dump_core オプションを介してカーネルコマンドラインで有効にすることもできます。
以下を参照してください。

--crash-vt = VT

クラッシュ時に特定の仮想コンソール(VT)に切り替えます。
1 から 63 の範囲の正の整数、またはブール値の引数を取ります。
整数が渡された場合、どの VT に切り替えるかを選択します。
yes の場合、 VT カーネルメッセージが書き込まれる場所が選択されます。
no の場合、 VT 切り替えは試行されません。
このスイッチは、ユーザーインスタンスとして実行している場合は効果がありません。
この設定は、ブート時に systemd.crash_chvt オプションを介してカーネルコマンドラインで有効にすることもできます。
以下を参照してください。

--crash-shell

クラッシュ時にシェルを実行します。
このスイッチは、ユーザーインスタンスとして実行している場合は効果がありません。
この設定は、ブート時に systemd.crash_shell オプションを介してカーネルコマンドラインで有効にすることもできます。
以下を参照してください。

--crash-reboot

クラッシュ時にシステムを自動的に再起動します。
このスイッチは、ユーザーインスタンスとして実行している場合は効果がありません。
この設定は、ブート時に systemd.crash_reboot オプションを介してカーネルコマンドラインで有効にすることもできます。
以下を参照してください。

--confirm-spawn

プロセスを生成するときに確認を求めます。
このスイッチは、ユーザーインスタンスとして実行する場合は効果がありません。

--show-status=

ブール引数または特別な値 auto を取ります。

• on : 起動時とシャットダウン時にコンソールに簡潔なユニットステータス情報が表示されます。
• off :ステータス情報は表示されません。
• auto :動作は off に似ていますが、最初のユニットの障害または重大な起動遅延が発生するとすぐに、自動的に on に切り替わります。 このスイッチは、ユーザーインスタンスとして呼び出された場合は無効です。 指定した場合、カーネルコマンドライン設定 systemd.show_status と構成ファイルオプション ShowStatus= の両方を上書きします。 systemd-system.conf(5) を参照してください。

--log-target=

ログターゲットを設定します。
引数は下記のいずれかである必要があります。

• console
• journal
• kmsg
• journal-or-kmsg
• null

--log-level=

ログレベルを設定します。
引数として、数値のログレベルまたはよく知られている syslog(3) シンボリック名(小文字)を受け入れます。

• emerg
• alert
• crit
• err
• warning
• notice
• info
• debug

--log-color=

重要なログメッセージを強調表示します。
引数はブール値です。
引数を省略するとデフォルトで true になります。

--log-location=

ログメッセージにコードの場所を含めます。
これは主にデバッグに関連しています。
引数はブール値です。
引数を省略するとデフォルトで true になります。

--default-standard-output=, --default-standard-error=

すべてのサービスとソケットのデフォルト出力またはエラー出力をそれぞれ設定します。
つまり、 StandardOutput= および StandardError= のデフォルトを制御します(詳細については、 systemd.exec(5) を参照してください)。
引数として以下のいずれかを取ります。

• inherit
• null
• tty
• journal
• journal+console
• syslog
• syslog+console
• kmsg
• kmsg+console

引数を省略すると、 --default-standard-output= はデフォルトで journal に、 --default-standard-error= は inherit に設定されます。

--machine-id=

ハードドライブの machine-id セットを上書きします。
ネットワークブートやコンテナに役立ちます。
すべてゼロに設定することはできません。

--service-watchdogs=

すべてのサービスウォッチドッグタイムアウトと緊急動作をグローバルに有効 / 無効にします。
この設定は、ブート時にカーネルコマンドラインで systemd.service_watchdogs オプションを介して指定することもできます。
以下を参照してください。
デフォルトは enable です。

-h, --help

短いヘルプテキストを表示して終了します。

--version

短いバージョン文字列を出力して終了します。

概要

systemd は、 11 種類の「ユニット」と呼ばれるさまざまなエンティティ間の依存関係システムを提供します。
ユニットは、システムの起動と管理に関連するさまざまなオブジェクトをカプセル化します。
ユニットの大部分はユニット構成ファイルで構成され、その構文と基本的なオプションセットは systemd.unit(5) で説明されていますが、一部は他の構成から自動的にシステムの状態から、または実行時にプログラムで作成されます。
ユニットは、 active (ユニットタイプに応じて、 started, bound, plugged in などを意味します。以下を参照)、または inactive (stopped, unbound, unplugged などを意味します)、およびアクティブ化または非アクティブ化のプロセス、つまり 2 つの状態の間(これらの状態は activating 、 deactivationg と呼ばれます)。
特別な failed 状態も利用できます。
これは inactive と非常に似ており、サービスが何らかの方法で失敗したときに終了します(プロセスが終了時にエラーコードを返すか、クラッシュした、操作がタイムアウトした、または再起動が多すぎる場合)。
この状態になると、後で参照できるように原因がログに記録されます。
さまざまなユニットタイプにいくつかの追加のサブステートがあり、ここで説明する 5 つの一般化されたユニットステートに分類されることに注意してください。

次のユニットタイプを使用できます。

1. デーモンとデーモンを構成するプロセスを開始および制御するサービスユニット。詳細については、 systemd.service(5) を参照してください。

2. システムのローカル IPC またはネットワークソケットをカプセル化するソケットユニット。ソケットベースのアクティブ化に役立ちます。ソケットユニットの詳細については、 systemd.socket(5) を参照してください。ソケットベースのアクティブ化および他の形式のアクティブ化の詳細については、 daemon(7) を参照してください。

3. ターゲットユニットは、ユニットをグループ化したり、起動時に既知の同期ポイントを提供したりするのに役立ちます。 systemd.target(5) を参照してください。

4. デバイスユニットは systemd のカーネルデバイスを公開し、デバイスベースのアクティベーションを実装するために使用できます。詳細については、 systemd.device(5) を参照してください。

5. マウントユニットは、ファイルシステムのマウントポイントを制御します。詳細については、 systemd.mount(5) を参照してください。

6. 自動マウントユニットは、ファイルシステムのオンデマンドマウントと並列化された起動のための自動マウント機能を提供します。
   systemd.automount(5) を参照してください。

7. タイマーユニットは、タイマーに基づいて他のユニットのアクティブ化をトリガーするのに役立ちます。詳細は systemd.timer(5) にあります。

8. スワップユニットはマウントユニットと非常によく似ており、オペレーティングシステムのメモリスワップパーティションまたはファイルをカプセル化します。それらは systemd.swap(5) で説明されています。

9. パスユニットは、ファイルシステムオブジェクトが変更または変更されたときに他のサービスをアクティブにするために使用できます。
   systemd.path(5) を参照してください。

10. スライスユニットは、システムプロセス(サービスユニットやスコープユニットなど)を管理するユニットを、リソース管理のために階層ツリーでグループ化するために使用できます。 systemd.slice(5) を参照してください。

11. スコープユニットはサービスユニットに似ていますが、外部プロセスを開始する代わりに管理します。 systemd.scope(5) を参照してください。
    ユニットは、構成ファイルとして名前が付けられています。一部のユニットには特別なセマンティクスがあります。詳細なリストは systemd.special(7) にあります。

systemd は、正と負の要件の依存関係(つまり Requires= と Conflicts= )や順序の依存関係（ After= と Before= ）など、さまざまな種類の依存関係を認識しています。

注意: 順序と要件の依存関係は直交しています。
2 つのユニット間に要件の依存関係のみが存在し(例: foo.service には bar.service が必要)、順序の依存関係はなく(例: foo.service の後に bar.service )、両方の開始が要求された場合、それらは並行して開始されます。
要件と順序の依存関係の両方が 2 つのユニット間に配置されるのは一般的なパターンです。
また、依存関係の大部分は systemd によって暗黙的に作成および管理されることに注意してください。
ほとんどの場合、追加の依存関係を手動で宣言する必要はありませんが、これを行うことは可能です。

アプリケーションプログラムと(依存関係を介した)ユニットは、ユニットの状態変更を要求できます。
systemd では、これらのリクエストは job としてカプセル化され、ジョブキューに保持されます。
ジョブは成功する場合と失敗する場合があります。
ジョブの実行は、スケジュールされたユニットの依存関係に基づいて実行されます。

起動時に systemd は、起動時サービスおよびその他の起動時ユニットを依存関係を介して呼び出すことによって起動するジョブであるターゲットユニット default.target を起動します。
通常、ユニット名は、 graphical.target(UI へのフル機能のブートの場合)または multi-user.target(組み込み環境またはサーバー環境で使用するための限定されたコンソールのみのブートの場合)、または同様のエイリアス(シンボリックリンク)です; graphic.target のサブセット)。
ただし、それを他のターゲットユニットのエイリアスとして構成するかどうかは、管理者の裁量に任されています。
これらのターゲットユニットの詳細については、systemd.special(7) を参照してください。

systemd は、メモリに読み込まれた最小単位のユニットのみを保持します。
具体的には、メモリに読み込まれたままになっているユニットは、次の条件の少なくとも 1 つに該当するユニットのみです。

1. アクティブ、アクティブ化、非アクティブ化、または障害が発生した状態(つまり、 inactive を除くすべてのユニット状態)

2. キューに入れられたジョブがある。

3. メモリに読み込まれるのは、何らかの少なくとも 1 つの他のユニットの依存関係である。

4. まだ割り当てられた何らかの形のリソースを持っている(たとえば、非アクティブであるが、終了要求を無視したプロセスがまだ残っているサービスユニット)

5. D-Bus 呼び出しによってプログラムでメモリに固定されている。

systemd は、ユニットがまだロードされていない場合、操作がユニットに要求されるとすぐに、ユニットをディスクから自動的かつ暗黙的にロードします。
したがって、多くの点で、ユニットがロードされているかどうかはクライアントにはわかりません。
systemctl list-units --all を使用して、現在ロードされているすべてのユニットを一覧表示します。
上記のいずれの条件にも当てはまらないユニットは、直ちにアンロードされます。
ユニットがメモリからアンロードされると、そのアカウンティングデータもフラッシュされることに注意してください。
ただし、ユニットがシャットダウンするたびに消費されたリソースを宣言するジャーナルログレコードが生成されるため、このデータは通常失われません。

systemd の生成されたプロセスは、プライベートな systemd 階層でそれらが属するユニットにちなんで名付けられた個々の Linux 制御グループに配置されます。
(コントロールグループの詳細については、 cgroups.txt または cgroups を参照してください)。
systemd はこれを使用して、プロセスを効果的に追跡します。
制御グループ情報はカーネル内に保持され、ファイルシステム階層( /sys/fs/cgroup/systemd/ の下)、または systemd-cgls(1) や ps(1)。
(ps xawf -eo pid,user,cgroup,args は、すべてのプロセスとそれらが属する systemd ユニットを一覧表示するのに特に役立ちます。)

systemd は SysV init システムと高い互換性があります。
SysVinit スクリプトがサポートされており、代替の(制限されていますが)構成ファイル形式として読み取られます。
SysV /dev/initctl インターフェースが提供され、さまざまな SysV クライアントツールの互換実装が利用可能です。
それに加えて、 /etc/fstab や utmp データベースなど、さまざまな Unix 機能がサポートされています。

systemd には最小限のトランザクションシステムがあります。
ユニットが起動またはシャットダウンするように要求された場合、ユニットとそのすべての依存関係が一時トランザクションに追加されます。
次に、トランザクションに一貫性があるかどうかを確認します(つまり、すべてのユニットの順序に循環がないかどうか)。
ユニットの順序に循環が認められる場合、 systemd は修正を試み、ループを削除できる可能性のある重要でないジョブをトランザクションから削除します。
また、 systemd は、実行中のサービスを停止するトランザクション内の重要でないジョブを抑制しようとします。
最後に、トランザクションのジョブがすでにキューに入れられているジョブと矛盾しているかどうかが確認され、オプションでトランザクションが中止されます。
すべてがうまくいき、トランザクションが一貫していて影響が最小限に抑えられている場合、未解決のすべてのジョブとマージされ、実行キューに追加されます。
これは事実上、要求された操作を実行する前に、 systemd がそれが妥当であることを確認し、可能であれば修正し、実際に機能しない場合にのみ失敗することを意味します。

トランザクションは実行時のユニットの状態とは無関係に生成されることに注意してください。
したがって、たとえば、すでに開始されているユニットで開始ジョブが要求された場合、トランザクションは生成され、非アクティブな依存関係が起動します(定義された関係ごとに他のジョブの伝播も発生します)。
これは、キューされたジョブがターゲットユニットの状態と比較して実行状態にあり、両方が満たされると成功と完了のマークが付けられるためです。ただし、このジョブは、定義された関係により他の依存関係も取り込むため、この例では、非アクティブなユニットのいずれかのジョブもキューに入れられます。

systemd には、ブートプロセスの一部として実行する必要があるさまざまなタスクのネイティブ実装が含まれています。
たとえば、ホスト名を設定したり、ループバックネットワークデバイスを構成したりします。
また、 /sys や /proc などのさまざまな API ファイルシステムをセットアップしてマウントします。

systemd の背後にある概念と思想の詳細については、 Original Design Document を参照してください。

systemd が提供する一部のインターフェイスは Interface Stability Promise でカバーされていることに注意してください。

ユニットは、ブート時およびシステムマネージャーのリロード時に動的に生成される場合があります。
たとえば、カーネルコマンドラインで渡された他の構成ファイルまたはパラメーターに基づいています。
詳細については、 systemd.generator(7) を参照してください。

コンテナーまたは initrd 環境で systemd を呼び出すシステムは、それぞれ Container Interface または initrd Interface の仕様を実装する必要があります。

ディレクトリ

システムユニットディレクトリ

systemd システムマネージャは、さまざまなディレクトリからユニット構成を読み取ります。
ユニットファイルをインストールするパッケージは pkg-config systemd --variable=systemdsystemunitdir によって返されるディレクトリにそれらを配置します。
チェックされる他のディレクトリは /usr/local/lib/systemd/system および /lib/systemd/system です。
ユーザー設定が常に優先されます。
pkg-config systemd --variable=systemdsystemconfdir は、システム構成ディレクトリのパスを返します。
パッケージは systemctl(1) ツールの enable および disable コマンドでのみ、これらのディレクトリの内容を変更する必要があります。
ディレクトリの完全なリストは systemd.unit(5) にあります。

ユーザーユニットディレクトリ

ユーザーユニットディレクトリにも同様のルールが適用されます。ただし、ここでは、 XDG Base Directory specification に従ってユニットを検索しています。
アプリケーションは pkg-config systemd --variable=systemduserunitdir によって返されるディレクトリにユニットファイルを配置する必要があります。
グローバル設定は pkg-config systemd --variable=systemduserconfdir によって報告されたディレクトリで行われます。
systemctl(1) ツールの enable コマンドと disable コマンドは、ユニットのグローバル(つまり、すべてのユーザー)とプライベート(1 人のユーザー)の有効化 / 無効化の両方を処理できます。
ディレクトリの完全なリストは systemd.unit(5) にあります。

SysV init スクリプトディレクトリ

SysV init スクリプトディレクトリの場所は、ディストリビューションによって異なります。
要求されたサービスのネイティブユニットファイルが見つからない場合、 systemd は同じ名前の .service 接尾辞が削除された SysV init スクリプトを探します。

SysV ランレベルリンクファームディレクトリ

SysV ランレベルリンクファームディレクトリの場所は、ディストリビューションによって異なります。
systemd は、サービスを有効にするかどうかを判断するときにリンクファームを考慮します。
ネイティブユニット構成ファイルを持つサービスユニットは、 SysV ランレベルリンクファームでアクティブ化して開始することはできません。

シグナル

SIGTERM

この信号を受信すると、 systemd システムマネージャーはその状態をシリアル化し、それ自体を再実行して、保存された状態を再度逆シリアル化します。
これは主に systemctl daemon-reexec と同等です。

systemd ユーザーマネージャーは、このシグナルを受信すると、exit.target ユニットを開始します。
これはほとんど systemctl --user start exit.target --job-mode=replace-irreversible と同等です。

SIGINT

この信号を受信すると、 systemd システムマネージャーは ctrl-alt-del.target ユニットを起動します。
これは、 systemctl start ctrl-alt-del.target --job-mode=replace-irreversible とほぼ同等です。
この信号が 2 秒間に 7 回以上受信された場合、即時リブートがトリガーされます。
コンソールで Ctrl + Alt + Del を押すと、この信号がトリガーされることに注意してください。
したがって、再起動がハングしている場合は、 Ctrl + Alt + Del を 2 秒以内に 7 回以上押すと、すぐに再起動する比較的安全な方法になります。

systemd ユーザーマネージャーは、このシグナルを SIGTERM と同じ方法で処理します。

SIGWINCH

このシグナルを受信すると、 systemd システムマネージャーは kbrequest.target ユニットを開始します。
これはほとんど systemctl start kbrequest.target と同等です。

このシグナルは systemd ユーザーマネージャーによって無視されます。

SIGPWR

このシグナルを受信すると、 systemd マネージャーは sigpwr.target ユニットを起動します。
これはほとんど systemctl start sigpwr.target と同等です。

SIGUSR1

この信号を受信すると、 systemd マネージャーは D-Bus バスへの再接続を試みます。

SIGUSR2

このシグナルを受信すると、 systemd マネージャーはその完全な状態を人間が読める形式で記録します。
ログに記録されるデータは、 systemd-analyze dump によって出力されるものと同じです。

SIGHUP

完全なデーモン構成を再ロードします。
これはほぼ systemctl daemon-reload と同等です。

SIGRTMIN+0

デフォルトモードに入り、 default.target ユニットを開始します。
これはほとんど systemctl isolate default.target と同等です。

SIGRTMIN+1

レスキューモードに入り、 rescue.target ユニットを開始します。
これは、 systemctl isolate rescue.target とほぼ同等です。

SIGRTMIN+2

緊急モードに入り、 emergency.service ユニットを開始します。
これは、ほとんどの場合、 systemctl isolate immediate.service と同等です。

SIGRTMIN+3

マシンを停止し、 halt.target ユニットを開始します。
これはほとんど systemctl start halt.target --job-mode=replace-irreversible と同等です。

SIGRTMIN+4

マシンの電源を切り、 poweroff.target ユニットを起動します。
これはほとんど systemctl start poweroff.target --job-mode=replace-irreversible と同等です。

SIGRTMIN+5

マシンを再起動し、 reboot.target ユニットを起動します。
これはほとんど systemctl start reboot.target --job-mode=replace-irreversible と同等です。

SIGRTMIN+6

kexec を介してマシンを再起動し、 kexec.target ユニットを起動します。
これはほとんど systemctl start kexec.target --job-mode=replace-irreversible と同等です。

SIGRTMIN+13

すぐにマシンを停止します。

SIGRTMIN+14

すぐにマシンの電源を切ります。

SIGRTMIN+15

すぐにマシンを再起動します。

SIGRTMIN+16

すぐに kexec でマシンを再起動します。

SIGRTMIN+20

カーネルコマンドラインの systemd.show_status=1 で制御されるように、コンソールでのステータスメッセージの表示を有効にします。

SIGRTMIN+21

カーネルコマンドラインの systemd.show_status=0 で制御されるように、コンソールでのステータスメッセージの表示を無効にします。

SIGRTMIN+22

カーネルコマンドラインの systemd.log_level=debug と同等の方法で、サービスマネージャーのログレベルを「デバッグ」に設定します。

SIGRTMIN+23

ログレベルを設定された値に復元します。
構成された値は、優先順位に従って、カーネルコマンドラインで systemd.log-level= で指定された値、または構成ファイルで LogLevel= で指定された値、または組み込みの info のデフォルトから導出されます。

SIGRTMIN+24

すぐにマネージャを終了します(--user インスタンスでのみ使用可能)。

SIGRTMIN+26

ログターゲットを設定された値に復元します。
構成された値は、優先順位に従って、カーネルコマンドラインで systemd.log-target で指定された値、または構成ファイルで LogTarget= で指定された値、または組み込みの default から取得されます。

SIGRTMIN+27, SIGRTMIN+28

カーネルコマンドラインの systemd.log_target=console (または SIGRTMIN+28 の systemd.log_target=kmsg )と同等の方法で、ログターゲットを SIGRTMIN+27 の console (または SIGRTMIN+28 の kmsg )に設定します。

環境

$SYSTEMD_LOG_LEVEL

systemd は、この環境変数からログレベルを読み取ります。
これは --log-level で上書きできます。

$SYSTEMD_LOG_TARGET

systemd は、この環境変数からログターゲットを読み取ります。
これは --log-target で上書きできます。

$SYSTEMD_LOG_COLOR

systemd が重要なログメッセージを強調表示するかどうかを制御します。
これは --log-color で上書きできます。

$SYSTEMD_LOG_LOCATION

systemd がログのメッセージとともにコードの位置を出力するかどうかを制御します。
これは --log-location で上書きできます。

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS

systemd ユーザーマネージャーは XDG Base Directory specification に従ってこれらの変数を使用して、その構成を見つけます。

$SYSTEMD_UNIT_PATH

systemd がユニットファイルを探す場所を制御します。

$SYSTEMD_SYSVINIT_PATH

systemd が SysV init スクリプトを探す場所を制御します。

$SYSTEMD_SYSVRCND_PATH

systemd が SysV init スクリプトランレベルリンクファームを探す場所を制御します。

$SYSTEMD_COLORS

値はブール値でなければなりません。
カラー化された出力を生成するかどうかを制御します。
これを指定して、 systemd が $TERM とコンソールの接続先に基づいて行う決定を上書きできます。

$SYSTEMD_URLIFY

値はブール値でなければなりません。
これをサポートするターミナルエミュレータの出力にクリック可能なリンクを生成するかどうかを制御します。
これを指定して、 systemd が $TERM およびその他の条件に基づいて行う決定を上書きできます。

$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES

ソケットベースのアクティベーション中に監視対象プロセス用に systemd によって設定されます。詳細については、 sd_listen_fds(3) を参照してください。

$NOTIFY_SOCKET

ステータスと起動完了通知の監視対象プロセスに対して systemd によって設定されます。
詳細については、 sd_notify(3) を参照してください。

systemd とそのさまざまなコンポーネントによって理解されるその他の環境変数については、 Known Environment Variables を参照してください。

カーネルコマンドライン

システムインスタンスとして実行すると、 systemd はいくつかのカーネルコマンドライン引数を解析します。

systemd.unit=, rd.systemd.unit=

ユニットを上書きして起動時にアクティブにします。
デフォルトは default.target です。
これは、一時的に別のブートユニット、たとえば rescue.target や emergency.service でブートするために使用できます。
これらのユニットの詳細については、 systemd.special(7) を参照してください。
rd. で始まるオプションは、メインシステムでのみ接頭辞が付いていない RAM ディスクに対して、初期 RAM ディスク (initrd) でのみ有効です。

systemd.dump_core

ブール引数を取るか、引数なしで指定した場合はオプションを有効にします。
有効にすると、 systemd マネージャー (PID 1) はクラッシュしたときにコアをダンプします。
それ以外の場合、コアダンプは作成されません。
デフォルトは有効です。

systemd.crash_chvt

正の整数またはブール引数を取ります。
引数なしで指定することもでき、正のブール値と同じ効果があります。
正の整数(1 から 63 の範囲)が指定されている場合、システムマネージャー(PID 1)は、クラッシュしたときに指定された仮想端末(VT)をアクティブにします。
デフォルトは無効です。
つまり、そのような切り替えは行われません。
有効に設定すると、カーネルメッセージが書き込まれる VT が選択されます。

systemd.crash_shell

ブール引数を取るか、引数なしで指定した場合はオプションを有効にします。
有効にすると、システムマネージャー(PID 1)は、クラッシュしたときに 10 秒の遅延後にシェルを生成します。
それ以外の場合、シェルは生成されません。
シェルはパスワード認証によって保護されていないため、セキュリティ上の理由から、デフォルトでは無効になっています。

systemd.crash_reboot

ブール引数を取るか、引数なしで指定した場合はオプションを有効にします。
有効にすると、システムマネージャー(PID 1)は、マシンがクラッシュしたときに、 10 秒後に自動的にマシンを再起動します。
そうしないと、システムが無期限にハングします。
再起動ループを回避するために、デフォルトでは無効になっています。
systemd.crash_shell と組み合わせると、シェルの終了後にシステムが再起動されます。

systemd.confirm_spawn

ブール引数、または確認メッセージが送信される仮想コンソールへのパスを取得します。
引数なしで指定することもでき、正のブール値と同じ効果があります。
有効になっている場合、システムマネージャ(PID 1)は、 /dev/console を使用してプロセス起動時に確認を求めます。
パスまたはコンソール名( ttyS0 など)が指定されている場合は、このパスで指定されている、または指定した名前で記述されている仮想コンソールが代わりに使用されます。
デフォルトでは無効になっています。

systemd.service_watchdogs=

ブール引数を取ります。
無効にすると、すべてのサービスランタイムウォッチドッグ( WatchdogSec= )と緊急アクション( OnFailure= や StartLimitAction= など)がシステムマネージャー(PID 1)によって無視されます。
systemd.service(5) を参照してください。
デフォルトでは有効になっています。
つまり、ウォッチドッグと障害アクションは正常に処理されます。
ハードウェアウォッチドッグは、このオプションの影響を受けません。

systemd.show_status

ブール引数または定数 auto を取ります。
引数なしで指定することもでき、正のブール値と同じ効果があります。
有効になっている場合、 systemd マネージャー(PID 1)は、起動時にコンソールに簡潔なサービスステータスの更新を表示します。
auto は、ユニットに障害が発生するか、起動に大幅な遅延が発生するまで false のように動作します。
カーネルコマンドラインオプションとして quiet が渡されない限り、デフォルトで有効になります。
この場合、デフォルトで auto になります。
指定した場合、システムマネージャー構成ファイルオプション ShowStatus= が上書きされます。
systemd-system.conf(5) を参照してください。
ただし、プロセスコマンドラインオプション --show-status は、このカーネルコマンドラインオプションと構成ファイルオプションの両方よりも優先されます。

systemd.log_target=, systemd.log_level=, systemd.log_location=, systemd.log_color

上記の $SYSTEMD_LOG_TARGET , $SYSTEMD_LOG_LEVEL , $SYSTEMD_LOG_LOCATION , $SYSTEMD_LOG_COLOR 環境変数と同じ効果で、ログ出力を制御します。
systemd.log_color は引数なしで指定でき、正のブール値と同じ効果があります。

systemd.default_standard_output=, systemd.default_standard_error=

上記の --default-standard-output, --default-standard-error コマンドライン引数とそれぞれ同じ効果で、サービスのデフォルトの標準出力とエラー出力を制御します。

systemd.setenv=

VARIABLE=VALUE の形式の文字列引数を取ります。
フォークされた子プロセスに追加するデフォルトの環境変数を設定するために使用できます。
複数の変数を設定するために複数回使用できます。

systemd.machine_id=

machine-id を設定するために使用される 32 文字の 16 進数値を取ります。
すべてのブートで同じ machine-id が必要なネットワークブートを主な対象としています。

systemd.unified_cgroup_hierarchy

引数なしで、または true 引数とともに指定すると、 統合された cgroup 階層 の使用が可能になります(別名 cgroups-v2)。
false 引数を指定した場合、ハイブリッドまたは完全な レガシー cgroup 階層 にフォー​​ルバックします。
このオプションが指定されていない場合、デフォルトの動作はコンパイル時に決定されます( -Ddefault-hierarchy=meson オプション)。
カーネルが統合 cgroup 階層をサポートしていない場合、このオプションが指定されていても、レガシー階層が使用されます。

systemd.legacy_systemd_cgroup_controller

完全な統合 cgroup 階層が使用されていない場合に有効になります(前のオプションを参照)。
引数なしで、または true 引数とともに指定すると hybrid cgroup 階層(systemd に使用される cgroups-v2 ツリー、および他のコントローラーには 従来の cgroup 階層 、別名 cgroups-v1)の使用を無効にします。
完全な legacy モードを強制します。
false 引数を指定すると、 hybrid 階層の使用が有効になります。
このオプションが指定されていない場合、デフォルトの動作はコンパイル時に決定されます( -Ddefault-hierarchy=meson オプション)。
カーネルが統合 cgroup 階層をサポートしていない場合、このオプションが指定されていても、レガシー階層が使用されます。

quiet

systemd.show_status=no と同様に、起動時にステータス出力をオフにします。
このオプションはカーネル自体にも読み込まれ、カーネルログ出力が無効になることに注意してください。
したがって、このオプションを渡すと、システムマネージャとカーネルの両方からの通常の出力がオフになります。

debug

デバッグ出力をオンにします。
これは、 systemd.log_level=debug と同等です。
このオプションはカーネル自体にも読み込まれ、カーネルのデバッグ出力を有効にすることに注意してください。
したがって、このオプションを渡すと、システムマネージャーとカーネルの両方からのデバッグ出力がオンになります。

emergency, rd.emergency, -b

緊急モードで起動します。
これはそれぞれ systemd.unit=emergency.target または rd.systemd.unit=emergency.target と同等であり、互換性の理由と入力の簡素化のために提供されています。

rescue, rd.rescue, single, s, S, 1

レスキューモードで起動します。
これは、それぞれ systemd.unit=rescue.target または rd.systemd.unit=rescue.target と同等であり、互換性の理由と入力の簡素化のために提供されています。

2, 3, 4, 5

指定されたレガシー SysV ランレベルで起動します。
これらは、それぞれ systemd.unit=runlevel2.target , systemd.unit=runlevel3.target , systemd.unit=runlevel4.target および systemd.unit=runlevel5.target と同等であり、互換性の理由と入力の簡素化のために提供されています。

locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=, locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=

使用するシステムロケールを設定します。これにより、 /etc/locale.conf の設定が上書きされます。
詳細については、 locale.conf(5) および locale(7) を参照してください。
コア OS のコンポーネントが理解できる他のカーネルコマンドラインパラメータについては、 kernel-command-line(7) を参照してください。

ソケットと FIFO

/run/systemd/notify

デーモンステータス通知ソケット。
これは AF_UNIX データグラムソケットであり、 sd_notify(3) によって実装されるデーモン通知ロジックを実装するために使用されます。

/run/systemd/private

systemctl(1) と systemd プロセス間の通信チャネルとして内部的に使用されます。
これは AF_UNIX ストリームソケットです。
このインターフェースは systemd 専用であり、外部プロジェクトでは使用しないでください。

/dev/initctl

systemd-initctl.service ユニットで実装されている、 SysV クライアントインターフェースの限定的な互換性サポート。
これは、ファイルシステム内の名前付きパイプです。
このインターフェースは廃止されているため、新しいアプリケーションでは使用しないでください。

SEE ALSO

• The systemd Homepage
• systemd-system.conf(5)
• locale.conf(5)
• systemctl(1)
• journalctl(1)
• systemd-notify(1)
• daemon(7)
• sd-daemon(3)
• systemd.unit(5)
• systemd.special(5)
• pkg-config(1)
• kernel-command-line(7)
• bootup(7)
• systemd.directives(7)

NOTES

1. cgroups.txt

2. Original Design Document

3. Interface Stability Promise

4. Container Interface

5. initrd Interface

6. XDG Base Directory specification

7. Known Environment Variables

8. Linux コンテナー内で実行する場合、これらの引数は、上記のオプションセクションに列記されているコマンドラインオプションの横にある systemd 自体にコマンドライン引数として渡される場合があります。
   Linux コンテナーの外部で実行する場合、これらの引数は代わりに /proc/cmdline から解析されます。

9. unified cgroup hierarchy

10. legacy cgroup hierarchy

11. systemd Homepage