LIBOF

コマンドラインのマニュアル

Man » systemd のオンラインマニュアル - systemd man ページの詳細なオンラインドキュメント

🌍 ☰ 
systemd、init - systemd システムおよびサービスマネージャー

概要

/usr/lib/systemd/systemd [オプション...]

init [オプション...]

説明

systemd は、Linux オペレーティングシステムのシステムおよびサービスマネージャーです。起動時に最初のプロセスとして実行されると、ユーザー空間サービスを起動および維持する init システムとして機能します。ログインしているユーザーに対しては、個別のインスタンスが起動され、それぞれのサービスが開始されます。

systemd は通常、ユーザーによって直接呼び出されることはなく、/sbin/init シンボリックリンクとしてインストールされ、起動時に開始されます。ユーザーマネージャーインスタンスは、[email protected](5) サービスを通じて自動的に開始されます。

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

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

systemd は、起動時にシステムクロックが正しく設定されていないと判断した場合、システムクロックをリセットします。

「システムクロックの時代」セクションを参照してください。

systemd によって提供されるインターフェイスの一部は、[1]インターフェイスの移植性と安定性に関する約束によってカバーされていることに注意してください。

systemd の D-Bus API は、org.freedesktop.systemd1(5) および org.freedesktop.LogControl1(5) で説明されています。

コンテナーまたは initrd 環境で systemd を呼び出すシステムは、それぞれ [2] コンテナーインターフェイスおよび [3] initrd インターフェイスの仕様を実装する必要があります。

ユニット

systemd は、11 種類の「ユニット」と呼ばれるさまざまなエンティティ間の依存関係システムを提供します。ユニットは、システム起動とメンテナンスに関連するさまざまなオブジェクトをカプセル化します。ほとんどのユニットは、unit 構成ファイルで構成され、その構文と基本的なオプションは systemd.unit(5) で説明されています。ただし、一部のユニットは、他の構成ファイル、システム状態、または実行時のプログラムによって動的に作成されます。ユニットは、次の表に説明されているいくつかの状態をとることができます。さまざまなユニットタイプには、ここに一般化されたユニット状態にマップされる追加のサブ状態があることに注意してください。

表 1. ユニットの ACTIVE 状態

┌──────────────┬─────────────────────────────────────┐
│ 状態          │ 説明                                  │
├──────────────┼─────────────────────────────────────┤
│ active       │ 開始済み、バインド済み、プラグイン済み、...   │
│              │ ユニットの種類によって異なります。           │
├──────────────┼─────────────────────────────────────┤
│ inactive     │ 停止済み、バインド解除済み、プラグ解除済み、...   │
│              │ ユニットの種類によって異なります。           │
├──────────────┼─────────────────────────────────────┤
│ failed       │ inactive と同様ですが、ユニットは何らかの方法で失敗しました。│
│              │ （プロセスがエラーコードを返して終了した、クラッシュした、操作がタイムアウトした、または│
│              │ 過剰な回数の再起動が発生した）。                   │
├──────────────┼─────────────────────────────────────┤
│ activating   │ inactive から active に変更中。           │
├──────────────┼─────────────────────────────────────┤
│ deactivating │ active から inactive に変更中。           │
├──────────────┼─────────────────────────────────────┤
│ maintenance  │ ユニットは inactive であり、メンテナンス操作が進行中です。│
├──────────────┼─────────────────────────────────────┤
│ reloading    │ ユニットは active であり、その構成を再読み込み中です。│
├──────────────┼─────────────────────────────────────┤
│ refreshing   │ ユニットは active であり、新しいマウントがその名前空間でアクティブ化されています。│
└──────────────┴─────────────────────────────────────┘

次のユニットタイプが利用可能です。

    サービスユニットは、デーモンとそのプロセスを起動および制御します。詳細については、systemd.service(5) を参照してください。

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

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

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

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

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

    タイマーユニットは、タイマーに基づいて他のユニットのアクティベーションをトリガーするために役立ちます。詳細は、systemd.timer(5) を参照してください。

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

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

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

    スコープユニットは、サービスユニットと似ていますが、外部プロセスを開始するのではなく、それらを管理します。詳細は、systemd.scope(5) を参照してください。

ユニットは、構成ファイルの名前で命名されます。一部のユニットには、特別な意味があります。詳細なリストは、systemd.special(7) で確認できます。

    systemd は、肯定的な要件依存関係（つまり、Requires=およびConflicts=）と、順序依存関係（つまり、After=およびBefore=）を含む、さまざまな種類の依存関係を認識します。注意：順序依存関係と要件依存関係は直交しています。2つのユニット間に要件依存関係（例：foo.service requires bar.service）のみが存在し、順序依存関係（例：foo.service after bar.service）が存在せず、両方を起動するように要求した場合、それらは並行して起動されます。一般的なパターンは、2つのユニット間に要件依存関係と順序依存関係の両方を配置することです。また、ほとんどの依存関係は、systemdによって暗黙的に作成および維持されます。ほとんどの場合、追加の依存関係を手動で宣言する必要はありませんが、可能です。

アプリケーションプログラムとユニット（依存関係を通じて）は、ユニットの状態変更を要求できます。systemd では、これらの要求は「ジョブ」としてカプセル化され、ジョブキューに保持されます。ジョブは成功または失敗する可能性があり、その実行は、スケジュールされたユニットの順序依存関係に基づいて順序付けられます。

起動時に、systemd はターゲットユニット default.target をアクティブ化します。このユニットの役割は、依存関係を通じて、起動時に必要なサービスやその他の起動ユニットをアクティブ化することです。通常、ユニット名は、グラフィカルな UI で完全に機能する起動の場合は graphical.target、または組み込みまたはサーバー環境で使用されるコンソールのみの起動の場合は multi-user.target のいずれかへのエイリアス（シンボリックリンク）です。ただし、管理者がこれを他のターゲットユニットへのエイリアスとして構成することができます。これらのターゲットユニットの詳細については、systemd.special(7) を参照してください。

初回起動時、systemdは、事前設定されたポリシーに従ってユニットを有効または無効にします。systemd.preset(5)およびmachine-id(5)の「初回起動時の意味」を参照してください。

systemdは、メモリにロードされた最小限のユニットセットのみを保持します。具体的には、以下の条件のいずれかを満たすユニットのみがメモリにロードされた状態を維持します。

  • ユニットがアクティブ、アクティブ化中、非アクティブ化中、または失敗状態にある（つまり、「非アクティブ」以外のすべてのユニット状態）。

  • ユニットに対してジョブがキューに入れられている。

  • ユニットが、メモリにロードされている少なくとも1つの他のユニットの依存関係である。

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

  • ユニットがプログラム的にD-Bus呼び出しによってメモリにピン留めされている。

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

systemdが生成するプロセスは、プライベートなsystemd階層内の、それらが属するユニットにちなんで名付けられた個別のLinuxコントロールグループに配置されます。（コントロールグループの詳細については、Control Groups v2[4]、または略して「cgroups」を参照してください。）systemdはこれを使用して、プロセスを効果的に追跡します。コントロールグループの情報はカーネル内に保持され、ファイルシステム階層（/sys/fs/cgroup/の下）またはsystemd-cgls(1)やps(1)（ps xawf -eo pid,user,cgroup,argsは、すべてのプロセスとその属するsystemdユニットをリストするのに特に役立ちます）などのツールを通じてアクセスできます。

systemdは、/etc/fstabやutmpデータベースなどのさまざまな確立されたUnix機能と互換性があります。

systemdには、最小限のトランザクションシステムがあります。ユニットの起動またはシャットダウンが要求されると、それとすべての依存関係が一時的なトランザクションに追加されます。次に、systemdは、トランザクションが一貫しているかどうか（つまり、すべてのユニットの順序がサイクルを含まないかどうか）を確認します。そうでない場合、systemdは修正を試み、ループを取り除くために、トランザクションから不要なジョブを削除します。また、systemdは、実行中のサービスを停止する可能性のあるトランザクション内の不要なジョブを抑制しようとします。最後に、トランザクションのジョブがすでにキューに入れられているジョブと矛盾しないかどうかが確認され、必要に応じてトランザクションが中止されます。すべてがうまくいき、トランザクションが一貫しており、その影響が最小限に抑えられている場合、トランザクションはすでに保留中のすべてのジョブにマージされ、実行キューに追加されます。効果的に言えば、systemdは、要求された操作を実行する前に、それが理にかなっていることを確認し、可能な場合は修正し、本当に実行できない場合にのみ失敗します。

トランザクションは、実行時のユニットの状態とは独立して生成されるため、たとえば、すでに起動済みのユニットで起動ジョブが要求された場合でも、トランザクションが生成され、非アクティブな依存関係がすべてウェイクアップされ（定義された関係に従って他のジョブが伝播される）。これは、エンキューされたジョブが実行時にターゲットユニットの状態と比較され、両方が満たされた場合に成功としてマークされ、完了するためである。ただし、このジョブは定義された関係のために他の依存関係も引き込み、したがって、上記の例では、それらの非アクティブなユニットの起動ジョブもエンキューされる。

ユニットは、ブート時やシステムマネージャーのリロード時に、他の構成ファイルやカーネルコマンドラインに渡されたパラメーターに基づいて動的に生成されることがある。詳細は、systemd.generator(7) を参照。

ディレクトリ

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

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

シグナル

サービスは、さまざまな UNIX プロセスシグナルをリッスンし、それらを使用してさまざまなアクションを非同期に要求できる。シグナル処理は、ブート時に非常に早い段階で、他のプロセスが開始される前に有効になる。ただし、このメカニズムを介してこれらの操作を要求しようとする監視コンテナマネージャーなどは、この機能が最も初期の初期化フェーズでは利用できないことを考慮する必要がある。sd_notify() 通知メッセージで X_SYSTEMD_SIGNALS_LEVEL=2 フィールドを送信すると、シグナルハンドラーが有効になったことが通知される。これを使用して、これらのシグナルの送信を適切にスケジュールできる。

SIGTERM

このシグナルを受信すると、systemd システムマネージャーは自身の状態をシリアライズし、自身を再実行し、保存された状態を再度デシリアライズします。これは、systemctl daemon-reexec とほぼ同等です。

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

SIGINT

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

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 emergency.service とほぼ同等です。

SIGRTMIN+3

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

SIGRTMIN+4

マシンをシャットダウンし、poweroff.target ユニットを開始します。これは、systemctl start poweroff.target --job-mode=replace-irreversibly とほぼ同等です。

SIGRTMIN+5

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

SIGRTMIN+6

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

SIGRTMIN+7

ユーザー空間を再起動し、soft-reboot.target ユニットを開始します。これは、systemctl start soft-reboot.target --job-mode=replace-irreversibly とほぼ同等です。

バージョン 254 で追加されました。

SIGRTMIN+13

マシンを即座に停止します。

SIGRTMIN+14

マシンを即座に電源オフします。

SIGRTMIN+15

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

SIGRTMIN+16

^ exec を使用してマシンを即座に再起動します。

SIGRTMIN+17

ユーザー空間を即座に再起動します。

バージョン 254 で追加されました。

SIGRTMIN+20

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

競合状態を防ぐために、SetShowStatus() を SIGRTMIN+20 の代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに代わりに

systemdが理解する変数の一部：

$SYSTEMD_LOG_LEVEL
出力されるメッセージの最大ログレベル（より高いログレベルのメッセージ、つまり重要度の低いメッセージは抑制されます）。コンマ区切りの値のリストを受け取ります。値は、(重要度の低い順に) emerg、alert、crit、err、warning、notice、info、debug のいずれか、または 0〜7 の範囲の整数になります。詳細については、syslog(3) を参照してください。各値は、console、syslog、kmsg、または journal のいずれかで始まるオプションの接頭辞とコロンを付けて、特定のログターゲットの最大ログレベルを設定できます (例: SYSTEMD_LOG_LEVEL=debug,console:info は、グローバルな最大ログレベルが優先されることを除いて、デバッグレベルでログを記録し、コンソールにログを記録する場合は情報レベルでログを記録することを指定します)。

これは、--log-level= でオーバーライドできます。

$SYSTEMD_LOG_COLOR
ブール値。trueの場合、tty に書き込まれるメッセージは、優先度に応じて色付けされます。

これは、--log-color= でオーバーライドできます。

$SYSTEMD_LOG_TIME
ブール値。trueの場合、コンソールログメッセージにはタイムスタンプが先頭に追加されます。

これは、--log-time= でオーバーライドできます。

バージョン 246 で追加されました。

$SYSTEMD_LOG_LOCATION
ブール値。trueの場合、メッセージは、メッセージが生成されたソースコード内のファイル名と行番号で先頭に追加されます。

これは、--log-location= でオーバーライドできます。

$SYSTEMD_LOG_TID
ブール値。trueの場合、メッセージは、現在の数値スレッドID (TID) で先頭に追加されます。

バージョン 247 で追加されました。

$SYSTEMD_LOG_TARGET
ログメッセージの送信先。console (接続された tty にログを記録)、console-prefixed (接続された tty にログを記録しますが、ログレベルと「facility」をエンコードする接頭辞が付いています。syslog(3) を参照してください)、kmsg (カーネルの循環ログバッファーにログを記録)、journal (journal にログを記録)、journal-or-kmsg (journal が利用可能な場合は journal にログを記録し、そうでない場合は kmsg にログを記録)、auto (適切なログターゲットを自動的に決定します。デフォルト)、null (ログ出力を無効にします) のいずれかです。

これは、--log-target= でオーバーライドできます。

$SYSTEMD_LOG_RATELIMIT_KMSG
kmsg をレート制限するかどうか。ブール値を受け取ります。デフォルトは「true」です。無効にすると、systemd は kmsg に書き込まれるメッセージをレート制限しません。

バージョン 254 で追加されました。

$XDG_CONFIG_HOME、$XDG_CONFIG_DIRS、$XDG_DATA_HOME、$XDG_DATA_DIRS
systemd ユーザーマネージャーは、XDG Base Directory 仕様[5]に従って、これらの変数を構成の検索に使用します。

$SYSTEMD_UNIT_PATH、$SYSTEMD_GENERATOR_PATH、$SYSTEMD_ENVIRONMENT_GENERATOR_PATH
systemd がユニットファイルとジェネレーターを検索する場所を制御します。

これらの変数は、コロン (:) で区切られたパスのリストを含めることができます。設定されている場合、リストが空のコンポーネント ("...:") で終わると、このリストは通常のパスセットの先頭に追加されます。それ以外の場合、指定されたリストは通常のパスセットを置き換えます。

$SYSTEMD_PAGER、$PAGER
`--no-pager` が指定されていない場合に使うページャ。`$SYSTEMD_PAGER` が設定されていればそれを使い、そうでなければ `$PAGER` を使う。どちらも設定されていない場合、`[less]({filename}../../less)(1)` や `more(1)` など、既知のページャ実装を順番に試す。いずれのページャ実装も見つからない場合、ページャは起動されない。これらの環境変数を空文字列または "cat" に設定すると、`--no-pager` を指定するのと同じになる。

注：`$SYSTEMD_PAGERSECURE` が設定されていない場合、`$SYSTEMD_PAGER` と `$PAGER` はページャを無効にするため ("cat" または "") にのみ使用でき、それ以外の場合は無視される。

$SYSTEMD_LESS
`less` に渡すオプションを上書きする (デフォルトは "FRSXMK")。

ユーザーが変更したいオプションとして、以下の 2 つがある。

    K
このオプションは、Ctrl+C が押されたときにページャが直ちに終了するように指示する。`less` が Ctrl+C を自身で処理して、ページャコマンドプロンプトに戻るようにするには、このオプションを無効にする。

`$SYSTEMD_LESS` の値に "K" が含まれておらず、起動されるページャが `less` の場合、Ctrl+C は実行ファイルによって無視され、ページャによって処理する必要がある。

    X
このオプションは、ページャが端末に termcap 初期化および非初期化文字列を送信しないように指示する。デフォルトでは設定されており、ページャが終了した後でもコマンドの出力が端末に表示されるようにする。ただし、これにより、マウスによるページャ出力のスクロールなど、一部のページャ機能が動作しなくなる。

通常の `$LESS` 環境変数を設定しても、systemd ツールによる `less` の起動には影響がないことに注意。

詳細については、`[less]({filename}../../less)(1)` を参照。

$SYSTEMD_LESSCHARSET
`less` に渡す文字コードを上書きする (デフォルトは、起動元の端末が UTF-8 互換と判定された場合、"utf-8")。

通常の `$LESSCHARSET` 環境変数を設定しても、systemd ツールによる `less` の起動には影響がないことに注意。

$SYSTEMD_PAGERSECURE
`[less]({filename}../../less)(1)` などの一般的なページャは、ページング (出力のスクロール) に加えて、他のファイルのオープンや書き込み、任意のシェルコマンドの実行をサポートする。
コマンドが昇格された権限で起動される場合 (たとえば、`[sudo]({filename}../../sudo)(8)` または `pkexec(1)` の下)、ページャはセキュリティ境界となる。権限のないユーザーが昇格された権限を持つコマンドを実行する場合、厳密に制限された機能を持つプログラムのみをページャとして使用し、新しいファイルのオープンまたは作成、またはサブプロセスの起動など、意図しないインタラクティブな機能を許可しないように注意する必要がある。ページャがそれをサポートしている場合は (ほとんどのページャはそれに対応するように作成されていない)、「セキュアモード」を有効にすることができる。`--no-pager` または `PAGER=cat` を使用してページャを完全に無効にするか、明示的に「セキュアモード」を有効にすることを推奨する。

このオプションは、ブール型の引数を受け取ります。true に設定すると、ページャーの「セキュアモード」が有効になります。 「セキュアモード」では、ページャーを呼び出す際に LESSSECURE=1 が設定され、これにより、ページャーは新しいファイルを開いたり作成したり、新しいサブプロセスを開始したりするコマンドを無効にするように指示されます。 現在、less(1) だけが、この変数を理解し、「セキュアモード」を実装することが知られています。

false に設定すると、ページャーに対して制限は加えられません。SYSTEMD_PAGERSECURE=0 を設定するか、または環境変数から削除しないと、ユーザーが任意のコマンドを呼び出せるようになる可能性があります。

$SYSTEMD_PAGERSECURE が設定されていない場合、systemd ツールは、「セキュアモード」を有効にするべきかどうか、およびページャーがそれをサポートしているかどうかを自動的に判断しようとします。「セキュアモード」は、実効 UID がログインセッションの所有者と異なる場合 (geteuid(2) と sd_pid_get_owner_uid(3) を参照)、または [sudo]({filename}../../sudo)(8) などのツール (6) で $SUDO_UID が設定されている場合に有効になります。これらの場合、SYSTEMD_PAGERSECURE=1 が設定され、「セキュアモード」を実装していないページャーは一切使用されません。この自動検出は、最も一般的な権限昇格メカニズムを対象としており、利便性のためのものです。明示的に $SYSTEMD_PAGERSECURE を設定するか、ページャーを無効にすることを推奨します。

$SYSTEMD_PAGER または $PAGER 変数を尊重し、ページャーを無効にする以外に、何らかの目的で使用する場合は、$SYSTEMD_PAGERSECURE も設定する必要があります。

$SYSTEMD_COLORS

ブール型の引数を受け取ります。true に設定すると、systemd および関連ユーティリティは、出力に色を使用します。そうでない場合、出力はモノクロになります。さらに、変数は、次の特殊な値のいずれかを取ることができます。"16"、"256"。これにより、色の使用が、基本の 16 色または 256 階調の ANSI 色に制限されます。これは、$TERM とコンソールが接続されているものに基づいて、systemd が自動的に決定するものをオーバーライドするために指定できます。

$SYSTEMD_URLIFY

値はブール型である必要があります。ターミナルエミュレーターでサポートされている場合、出力にクリック可能なリンクを生成するかどうかを制御します。これは、$TERM およびその他の条件に基づいて systemd が行う決定をオーバーライドするために指定できます。

$LISTEN_PID、$LISTEN_PIDFDID、$LISTEN_FDS、$LISTEN_FDNAMES

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

$NOTIFY_SOCKET

サービスマネージャーは、ステータスと準備完了の通知のために、これらのサービスに対してこの変数を設定します。また、サービスマネージャーは、これを消費して、上位のコンテナマネージャーまたはサービスマネージャーに自身の進行状況を通知します。詳細については、sd_notify(3) および以下の関連セクションを参照してください。

systemd およびそのさまざまなコンポーネントによって理解されるその他の環境変数については、既知の環境変数[7]を参照してください。

カーネルコマンドライン

システムインスタンスとして実行される場合、systemd は以下にリストされているいくつかのオプションを解析します。これらは、カーネルコマンドライン引数として指定でき、これは systemd が実行されている環境によって異なります。Linux コンテナ内で実行されている場合、これらのオプションは、systemd に渡されるコマンドライン引数、および上記の「オプション」セクションにリストされているその他のコマンドラインオプションから解析されます。Linux コンテナの外で実行されている場合、これらの引数は /proc/cmdline から解析されます。

以下の変数は理解されています。

systemd.unit=, rd.systemd.unit=

起動時にアクティブにするユニットをオーバーライドします。デフォルトは default.target です。これは、たとえば rescue.target や emergency.service などの別のブートユニットに一時的にブートするために使用できます。 systemd.special(7) の詳細を参照してください。 "rd." というプレフィックスが付いたオプションは、initrd 内でのみ有効になり、プレフィックスが付いていないオプションは、メインシステムでのみ有効になります。

systemd.dump_core

ブール値の引数を受け取ります。引数なしで指定すると、オプションが有効になります。有効にすると、systemd マネージャー (PID 1) はクラッシュ時にコアダンプを作成します。無効にすると、コアダンプは作成されません。 デフォルトは有効です。

バージョン 233 で追加されました。

systemd.crash_chvt

正の整数、またはブール値の引数を受け取ります。引数なしで指定することもでき、正のブール値と同じ効果があります。正の整数 (1〜63 の範囲) が指定された場合、システムマネージャー (PID 1) は、クラッシュ時に指定された仮想ターミナルをアクティブにします。デフォルトは無効で、仮想ターミナルの切り替えは行われません。有効にすると、代わりにカーネルメッセージが書き込まれる仮想ターミナルが使用されます。

バージョン 233 で追加されました。

systemd.crash_shell

ブール値の引数を受け取ります。引数なしで指定すると、オプションが有効になります。有効にすると、システムマネージャー (PID 1) はクラッシュ時にシェルを起動します。無効にすると、シェルは起動されません。 セキュリティ上の理由から、デフォルトは無効です。シェルはパスワード認証で保護されていないためです。

バージョン 233 で追加されました。

systemd.crash_action=

"freeze"、"reboot"、または "poweroff" のいずれかの値を指定します。デフォルトは "freeze" です。 "freeze" に設定すると、システムマネージャー (PID 1) がクラッシュしたときに、システムは無期限にハングします。 "reboot" に設定すると、システムマネージャー (PID 1) は、クラッシュ時に 10 秒の遅延後にマシンを自動的に再起動します。 "poweroff" に設定すると、システムマネージャー (PID 1) は、クラッシュ時にマシンを直ちにシャットダウンします。 systemd.crash_shell と組み合わせると、構成されたクラッシュアクションは、シェルが終了した後に実行されます。

バージョン 256 で追加されました。

systemd.confirm_spawn

ブール値の引数を受け取ります。または、確認メッセージを表示する仮想コンソールのパスを指定することもできます。引数なしで指定することもでき、正のブール値と同じ効果があります。有効にすると、システムマネージャー (PID 1) は、/dev/console を使用してプロセスを起動するときに、確認を求めます。パスまたはコンソール名 (たとえば "ttyS0") が指定された場合、指定されたパスで指される仮想コンソールまたは指定された名前に対応する仮想コンソールが使用されます。 デフォルトは無効です。

バージョン 233 で追加されました。

systemd.service_watchdogs=

ブール値を引数として受け取ります。無効にすると、すべてのサービス実行時間ウォッチドッグ（WatchdogSec=）および緊急アクション（例：OnFailure=またはStartLimitAction=）がシステムマネージャー（PID 1）によって無視されます。systemd.service(5) を参照してください。デフォルトでは有効になっており、ウォッチドッグと失敗アクションは通常どおり処理されます。ハードウェアウォッチドッグは、このオプションの影響を受けません。

バージョン 237 で追加されました。

systemd.show_status

ブール値または、error および auto という定数を受け取ります。引数なしで指定することもでき、正のブール値と同じ効果があります。有効にすると、systemd マネージャー（PID 1）は、起動中にコンソールに簡潔なサービスステータスアップデートを表示します。error の場合、失敗に関するメッセージのみが表示され、それ以外の場合は起動は静かに進みます。auto は、起動にかなりの遅延が発生するまで、false として動作します。デフォルトでは有効になっています。ただし、quiet がカーネルコマンドラインオプションとして渡された場合、デフォルトは error になります。指定した場合、systemd-system.conf(5) のシステムマネージャー構成ファイルオプション ShowStatus= を上書きします。

バージョン 233 で追加されました。

systemd.status_unit_format=

name、description、または combined を値として受け取ります。name の場合、システムマネージャーはステータスメッセージでユニット名を使用します。combined の場合、システムマネージャーはステータスメッセージでユニット名と説明を使用します。指定した場合、systemd-system.conf(5) のシステムマネージャー構成ファイルオプション StatusUnitFormat= を上書きします。

バージョン 243 で追加されました。

systemd.log_color、systemd.log_level=、systemd.log_location、systemd.log_target=、systemd.log_time、systemd.log_tid、systemd.log_ratelimit_kmsg
上記の環境変数で説明されている $SYSTEMD_LOG_COLOR、$SYSTEMD_LOG_LEVEL、$SYSTEMD_LOG_LOCATION、$SYSTEMD_LOG_TARGET、$SYSTEMD_LOG_TIME、$SYSTEMD_LOG_TID、$SYSTEMD_LOG_RATELIMIT_KMSG と同じ効果で、ログ出力を制御します。systemd.log_color、systemd.log_location、systemd.log_time、systemd.log_tid、systemd.log_ratelimit_kmsg は、引数なしで指定することもでき、正のブール値と同じ効果があります。

systemd.default_standard_output=、systemd.default_standard_error=

サービスおよびソケットのデフォルトの標準出力と標準エラー出力を制御します。つまり、systemd.exec(5) の詳細を参照してください。StandardOutput= と StandardError= のデフォルトを制御します。inherit、null、tty、journal、journal+console、kmsg、kmsg+console のいずれかの値を引数として受け取ります。引数が省略された場合、systemd.default-standard-output= は journal に、systemd.default-standard-error= は inherit にデフォルト設定されます。

systemd.setenv=

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

systemd.machine_id=

32 文字の 16 進値を引数として受け取り、machine-id を設定するために使用します。主にネットワークブートに使用され、すべてのブートで同じ machine-id を使用します。

バージョン 229 で追加。

systemd.set_credential=, systemd.set_credential_binary=

システム認証情報を設定します。これは、ImportCredential= または LoadCredential= 設定を使用して、システムサービスに伝播できます。詳細は、systemd.exec(5) を参照してください。クレデンシャル名と値のペアを、コロンで区切って指定します。systemd.set_credential= パラメータは、リテラルテキスト形式でクレデンシャル値を受け入れます。systemd.set_credential_binary= パラメータは、Base64 でエンコードされたバイナリデータを受け入れます。通常、カーネルコマンドラインは、/proc/cmdline 内で特権のないプログラムからアクセスできます。したがって、このメカニズムは、機密データ (秘密鍵ではなく、公開鍵/証明書など) を転送したり、テスト/デバッグ環境で使用したりするのには適していません。

詳細は、System and Service Credentials[8] のドキュメントを参照してください。

バージョン 251 で追加。

systemd.import_credentials=

ブール値を引数として受け取ります。false に設定すると、カーネルコマンドライン、DMI/SMBIOS OEM 文字列テーブル、qemu_fw_cfg サブシステム、または EFI カーネルスタブからの認証情報のインポートが無効になります。

バージョン 251 で追加。

quiet

ブート時のステータス出力をオフにします。これは、systemd.show_status=no とほぼ同じです。このオプションはカーネル自体によっても読み取られ、カーネルログ出力を無効にします。したがって、このオプションを渡すと、システムマネージャとカーネルの両方からの通常の出力が無効になります。

バージョン 186 で追加。

debug

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

バージョン 205 で追加。

emergency, rd.emergency, -b

緊急モードで起動します。これは、systemd.unit=emergency.target または rd.systemd.unit=emergency.target と同等であり、互換性のために提供され、入力しやすくなっています。

バージョン 186 で追加。

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

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

バージョン 186 で追加。

2 3, 4, 5

指定されたレガシー SysV ランレベルで起動します。2、3、および 4 は systemd.unit=multi-user.target と同等であり、5 は systemd.unit=graphical.target と同等であり、互換性のために提供され、入力しやすくなっています。

バージョン 186 で追加。

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) を参照してください。

バージョン 186 で追加。

コア OS のコンポーネントによって理解される他のカーネルコマンドラインパラメータについては、kernel-command-line(7) を参照してください。

システム認証情報

初期化中に、サービスマネージャーはさまざまなソースから認証情報をシステムの認証情報セットにインポートし、その後、サービスに伝播してジェネレーターで使用できるようにします。

サービスマネージャーが最初に初期化されると、SMBIOS Type 11 ベンダー文字列 io.systemd.credential:name=value、および io.systemd.credential.binary:name=value からシステム認証情報が読み込まれます。

同時に、QEMU の "fw_cfg" から認証情報がインポートされます。（一般に、SMBIOS メカニズムの方が高速で汎用性があるため、こちらが推奨されます。）

認証情報は、systemd.set-credential= パラメーターを使用して、カーネルコマンドライン経由で渡すことができます（上記を参照）。

認証情報は、UEFI 環境から systemd-stub(7) 経由で渡すことができます。

サービスマネージャーが initrd → ホストの移行中に呼び出された場合、/run/credentials/@initrd/ 内のすべてのファイルがシステム認証情報としてインポートされます。

systemd-creds(1) を以下のように呼び出して、システムに渡された認証情報のリストを確認します。

# systemd-creds --system list

詳細については、System and Service Credentials[8] のドキュメントを参照してください。

PID 1 として実行されているサービスマネージャーは、次のシステム認証情報を消費します。

vmm.notify_socket

AF_VSOCK または AF_UNIX アドレスを含み、サービスマネージャーが起動を完了したときに READY=1 の通知メッセージを送信する場所を指定します。sd_notify(3) および次のセクションを参照してください。ハイパーバイザーが AF_VSOCK 上の SOCK_DGRAM をサポートしていない場合、代わりに SOCK_SEQPACKET が試行されます。AF_VSOCK の認証情報ペイロードは、"vsock:CID:PORT" という形式の文字列である必要があります。"vsock-stream"、"vsock-dgram"、および "vsock-seqpacket" を使用して、対応するソケットタイプの使用を強制することもできます。

この機能は、マシンマネージャーまたはホスト上の他のプロセスが、仮想マシンが起動を完了したときに VSOCK 経由で通知を受信する場合に役立ちます。

バージョン 254 で追加されました。

system.machine_id

/etc/machine-id を初期化するために、128 ビットの 16 進 ID を渡します (ファイルがまだ設定されていない場合)。詳細は machine-id(5) を参照してください。

バージョン 254 で追加されました。

systemd のさまざまなコンポーネントが消費するシステム認証情報のリストについては、systemd.systemcredentials(7) を参照してください。

準備完了プロトコル

サービスマネージャーは、マネージャーとそのサービスの間（つまり、スタックを下る方向）、およびマネージャーと潜在的な上位のスーパーバイザーの間（後者はマシンまたはコンテナーマネージャー、またはパーユーザーサービスマネージャーの場合のシステムサービスマネージャーインスタンスである可能性があります）で、準備完了通知プロトコルを実装します。基本的なプロトコル（およびそれに対する推奨される API）は、sd_notify(3) に記述されています。

サービスマネージャー（PID 1 を含む）が自身のスーパーバイザーに準備完了を報告するために使用する通知ソケットは、通常の $NOTIFY_SOCKET 環境変数（上記を参照）で設定されます。これは、コンテナーマネージャーとパーユーザーインスタンスのサービスマネージャーでのみ直接設定できるため、追加の構成メカニズムが用意されており、特に VM 環境での使用を目的としています。vmm.notify_socket システム認証情報（上記を参照）を、適切なソケット（通常は AF_VSOCK）に、SMBIOS Type 11 ベンダー文字列経由で設定できます。詳細については、上記を参照してください。

サービスマネージャーから上位のスーパーバイザーに送信される通知プロトコルは、スーパーバイザーがシステムの特定のプロパティを学習し、ブートの進行状況を追跡できるようにする、いくつかの拡張フィールドをサポートしています。具体的には、次のフィールドが送信されます。

X_SYSTEMD_HOSTNAME=... メッセージは、システムの初期ホスト名が決定されたときに送信されます。ただし、後続の実行時にはホスト名がプログラムによって変更される可能性があり、（現在）その場合にさらに通知が送信されることはありません。

バージョン256で追加されました。

X_SYSTEMD_MACHINE_ID=... メッセージは、システムの機械IDが決定されたときに送信されます。詳細は、machine-id(5)を参照してください。

バージョン256で追加されました。

X_SYSTEMD_SIGNALS_LEVEL=... メッセージは、サービスマネージャーが上記で説明したさまざまなUNIXプロセスシグナルハンドラーをインストールしたときに送信されます。このフィールドの値は、10進数形式の符号なし整数であり、サービスマネージャーのサポートするUNIXプロセスシグナル機能のレベルを示します。現在、次の1つの機能レベルのみが定義されています。

X\_SYSTEMD\_SIGNALS\_LEVEL=2 は、上記で説明したさまざまなUNIXプロセスシグナルをカバーします。これは、従来のSysV initシステムでサポートされているシグナルのスーパーセットです。

このメッセージが送信される前にPID 1に送信されたシグナルは、正しく処理されない場合があります。これらのメッセージのコンシューマーは、サポートレベルを示す符号なし整数として値を解析する必要があります。現時点では、上記のレベル2のみが定義されていますが、後でより高い整数で追加のレベルが定義され、現在の動作のスーパーセットが実装される可能性があります。

バージョン256で追加されました。

X\_SYSTEMD\_UNIT\_ACTIVE=... と X\_SYSTEMD\_UNIT\_INACTIVE=... メッセージは、各ターゲットユニットがアクティブになったとき、または非アクティブになったときに送信されます。これは、ブートの進行状況と機能を追跡するのに役立ちます。たとえば、ssh-access.targetユニットが開始されたと報告された場合、通常はSSHアクセスが可能になります。詳細は、systemd.special(7)を参照してください。

バージョン256で追加されました。

X_SYSTEMD_SHUTDOWN=... メッセージは、システムがシャットダウンされる直前に送信されます。値は、"reboot"、"halt"、"poweroff"、"kexec" のいずれかの文字列であり、実行されるシャットダウンの種類を示します。

バージョン256で追加されました。

X_SYSTEMD_REBOOT_PARAMETER=... メッセージも、システムがシャットダウンされる直前に送信されます。その値は、systemctl --reboot-argument=... で設定された再起動引数です。

バージョン256で追加されました。

これらの拡張フィールドは、通常の "READY=1" および "RELOADING=1" 通知に加えて送信されます。

オプション

systemd は、非常にまれに直接呼び出されるだけで、ブート時に早期に開始され、ユーザーが操作できる時点ではすでに実行されています。通常、[systemctl]({filename}../../systemctl)(1) などのツールを使用して、マネージャーにコマンドが与えられます。systemd は通常、直接呼び出されないため、以下にリストされているオプションは、主にデバッグおよび特殊な目的に役立ちます。

イントロスペクションとデバッグオプション

これらのオプションはテストとイントロスペクションに使用され、systemd はいつでもそれらを使用して起動できます。

`--dump-configuration-items`

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

`--dump-bus-properties`

公開されているバスプロパティをダンプします。これにより、D-Bus で公開されているプロパティの簡潔だが完全なリストが出力されます。

バージョン 239 で追加されました。

`--test`

初期起動トランザクション（つまり、起動時にキューに入れられるジョブのリスト）を決定し、それをダンプして終了します。実際のジョブは実行されません。このオプションはデバッグに役立ちます。通常、通常のサービスマネージャーの起動中には、ハードウェア、ソケット、バス、またはその他の種類の起動によって追加のジョブが追加されるため、この操作で表示されないユニットが起動されることがあります。--system を使用して、システムサービスマネージャーの初期トランザクションを要求します（これがデフォルトの動作です）。--user と組み合わせて、ユーザーごとのサービスマネージャーの初期トランザクションを要求します。

`--system`, `--user`

^ -test と組み合わせて使用すると、システムインスタンスまたはユーザーごとのインスタンスの初期トランザクションを計算するかどうかを選択します。--test を使用せずに起動した場合、これらのオプションには効果がありません。通常の（つまり、--test ではない）起動では、サービスマネージャーは、実行中の PID が 1 かどうかをチェックすることで、システムモードまたはユーザーごとのモードで動作するかどうかを自動的に検出し、--system モードでサービスマネージャーを実行しているシステムを起動および維持することはサポートされていません。PID が 1 ではない場合があることに注意してください。

`-h`, `--help`

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

`--version`

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

カーネルコマンドラインの設定を複製するオプション

これらのオプションは、「カーネルコマンドライン」ですでにリストされているオプションに直接対応します。どちらの形式でも、システムマネージャーに対して同等に使用できますが、このコンテキストでは上記でリストされている形式を使用することをお勧めします。これらは適切に名前空間が設定されているためです。オプションがカーネルコマンドラインと通常のコマンドライン引数の両方で指定されている場合、後者が優先されます。

systemd がユーザーマネージャーとして使用されている場合、カーネルコマンドラインは無視され、以下に示すオプションのみが理解されます。ただし、systemd は通常、すべてのユーザー間で共有される [email protected](5) サービスを通じてこのモードで起動されます。設定ファイルを使用して設定を修正する方が便利な場合があります（systemd-user.conf(5) を参照）。環境ブロックの設定については、上記の「環境」セクションを参照してください。

--unit=

起動時にアクティブにするデフォルトのユニットを設定します。指定しない場合、デフォルトでは default.target が使用されます。systemd.unit= を参照してください。

--dump-core

クラッシュ時にコアダンプを有効にします。このオプションは、ユーザーインスタンスとして実行している場合には効果がありません。systemd.dump_core= と同じです。

--crash-vt=VT

クラッシュ時に特定の仮想コンソール (VT) に切り替えます。このオプションは、ユーザーインスタンスとして実行している場合には効果がありません。systemd.crash_chvt= と同じですが、スペルが異なります。

バージョン 227 で追加されました。

--crash-shell

クラッシュ時にシェルを実行します。このオプションは、ユーザーインスタンスとして実行している場合には効果がありません。systemd.crash_shell= を参照してください。

--crash-action=

システムマネージャー (PID 1) がクラッシュした場合に実行する処理を指定します。このオプションは、systemd がユーザーインスタンスとして実行されている場合には効果がありません。systemd.crash_action= を参照してください。

バージョン 256 で追加されました。

--confirm-spawn

プロセスを生成する際に確認を求めます。このオプションは、ユーザーインスタンスとして実行している場合には効果がありません。systemd.confirm_spawn を参照してください。

--show-status

起動時とシャットダウン中に、簡潔なユニットステータス情報をコンソールに表示します。systemd.show_status を参照してください。

バージョン 244 で追加されました。

--log-color

重要なログメッセージを強調表示します。systemd.log_color を参照してください。

バージョン 244 で追加されました。

--log-level=

ログレベルを設定します。systemd.log_level を参照してください。

--log-location

ログメッセージにコードの場所を含めます。systemd.log_location を参照してください。

バージョン 244 で追加されました。

--log-target=

ログのターゲットを設定します。systemd.log_target を参照してください。

--log-time=

コンソールメッセージの前にタイムスタンプを付加します。systemd.log_time を参照してください。

バージョン 246 で追加されました。

--machine-id=

ハードドライブに設定されている machine-id を上書きします。systemd.machine_id= を参照してください。

バージョン 229 で追加されました。

--service-watchdogs

すべてのサービスのウォッチドッグタイムアウトと緊急アクションをグローバルに有効または無効にします。systemd.service_watchdogs を参照してください。

バージョン 237 で追加されました。

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

すべてのサービスおよびソケットのデフォルトの出力またはエラー出力を設定します。systemd.default_standard_output= および systemd.default_standard_error= を参照してください。

システムクロックのエポック

systemd が起動または再起動されると、システムクロックを「エポック」に設定することがあります。このメカニズムは、バッテリー駆動のローカル RTC が利用できない場合、または正しく機能しない場合に、システムクロックが再起動間で合理的に初期化され、ほぼ単調になるようにするために使用されます。

エポックは、システムクロック時間が正しく設定されていると想定される最も古い日付です。初期化時に、ローカルクロックがエポックよりも古い値に設定されている場合、ローカルクロックはエポックにまで進められます。特別なケースとして、ローカルクロックが十分に未来の値 (デフォルトでは 15 年) である場合、ハードウェアクロックが壊れていると想定され、システムクロックはエポックに巻き戻されます。

エポックは、次の値のうち最大の値に設定されます。systemd のビルド時、/usr/lib/clock-epoch の修正時 ("mtime")、および /var/lib/systemd/timesync/clock の修正時。

ファイル

/run/systemd/notify

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

/run/systemd/private

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

/usr/lib/clock-epoch

このファイルの修正時刻 ("mtime") は、時間エポックとして使用されます。詳細は前述のセクションを参照してください。

バージョン 247 で追加されました。

/var/lib/systemd/timesync/clock

このファイルの修正時刻 ("mtime") は、systemd-timesyncd.service(8) によって更新されます。存在する場合、ファイルの修正時刻はエポックとして使用されます。詳細は前述のセクションを参照してください。

バージョン 257 で追加されました。

履歴

systemd 252

カーネルコマンドライン引数 systemd.unified_cgroup_hierarchy と systemd.legacy_systemd_cgroup_controller が非推奨になりました。統合 cgroup 階層に切り替えてください。

関連項目

systemd ホームページ[9]、systemd-system.conf(5)、locale.conf(5)、systemctl(1)、journalctl(1)、systemd-notify(1)、daemon(7)、sd-daemon(3)、org.freedesktop.systemd1(5)、systemd.unit(5)、systemd.special(7)、pkg-config(1)、kernel-command-line(7)、bootup(7)、systemd.directives(7)、org.freedesktop.systemd1(5)

systemd の概念とアイデアの詳細については、Original Design Document[10] を参照してください。

注意

    インターフェースの移植性と安定性の約束
https://systemd.io/PORTABILITY_AND_STABILITY/

    コンテナインターフェース
https://systemd.io/CONTAINER_INTERFACE

initrd インターフェース
https://systemd.io/INITRD_INTERFACE/

    Control Groups v2
https://docs.kernel.org/admin-guide/cgroup-v2.html

XDG ベースディレクトリ仕様
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

    他のツールは、$SUDO\_UID を適切に設定およびチェックすることを推奨します。これは共通のインターフェースとして扱われます。

    既知の環境変数
https://systemd.io/ENVIRONMENT

    システムおよびサービス認証情報
https://systemd.io/CREDENTIALS

systemd ホームページ
https://systemd.io/

    Original Design Document
https://0pointer.de/blog/projects/systemd.html