/usr/sbin/init

systemd システム、サービスマネージャー

SYNOPSIS

      /lib/systemd/systemd [OPTIONS...]

      init [OPTIONS...] {COMMAND}

DESCRIPTION

systemd は Linux OS 用のシステムおよびサービスマネージャである。起動時に最初のプロセスとして実行されると (PID 1として)、ユーザー空間のサービスを起動し維持するinitシステムとして動作する。ログインしたユーザがサービスを開始するためには、別のインスタンスが起動される。

systemd は通常、ユーザーによって直接起動されないが、/sbin/init シンボリックとしてインストールされ、初期起動時に開始される。ユーザマネージャ インスタンスは user@.service(5) サービスを通して自動的に起動される。

SysVとの互換性のために、バイナリがinitとして呼び出され、マシンの最初のプロセスでない場合（PIDが1でない）、それはtelinitを実行し、すべてのコマンドライン引数を変更されずに通過させる。つまり、通常のログインセッションから呼び出された場合、init と telinit はほとんど同等である。詳しくは telinitを参照すること。

システムインスタンスとして実行された場合、systemd は設定ファイル system.conf と system.conf.d ディレクトリのファイルを解釈する。ユーザーインスタンスとして実行された場合、systemd は設定ファイル user.conf と user.conf.d ディレクトリのファイルを解釈する。詳しくは systemd-system.conf を参照。

CONCEPTS

systemd は 11種類の "ユニット" と呼ばれる様々なエンティティ間の依存関係システムを提供する。ユニットは、システムの起動やメンテナンスに関連する様々なオブジェクトをカプセル化する。ユニットの大半はユニット設定ファイルで設定される。その構文とオプションの基本セットは systemd.unit(5) で説明されているが、いくつかのユニットは他の設定から自動的に、システムの状態から動的に、または実行時にプログラムによって作成される。ユニットは "active" (起動、結合、接続、...の意、ユニットの種類による、下記参照) か "inactive" (停止、非結合、非接続、...の意)、また起動や非活性化の途中、つまりその間の状態 (これらの状態を "activating", "deactivating" という) になることがある。これは「非アクティブ」に非常に似ており、サービスが何らかの形で失敗した場合（プロセスが終了時にエラーコードを返す、クラッシュする、操作がタイムアウトする、再起動回数が多いなど）に入力される。この状態になると、その原因が記録され、後で参照できるようになる。様々なユニットタイプは、ここで説明した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) にある。

正負の要件依存関係 (Requires= と Conflicts=) と順序依存関係 (After= と Before=) を含む。 注：順序依存性と要件依存性は直交している。2つのユニット間に要件依存関係のみが存在し（例：foo.service requires bar.service）、順序依存関係がない場合（例：foo.service after bar.service）、両方の開始が要求されると、それらは並行して開始されることになる。要求依存性と順序依存性の両方が2つのユニットの間に置かれるのは、よくあるパターンである。 また、依存関係の大部分は systemd によって暗黙のうちに作成・維持されていることに注意すること。 ほとんどの場合、追加の依存関係を手動で宣言する必要はないはずですが、宣言することは可能である。

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

ブート時に systemd はターゲットユニット default.target を起動する。このユニットは、オンブートサービスや他のオンブートユニットを依存関係から引き出して起動する役割を担っている。通常、このユニット名は graphical.target (UI の全機能ブート用) か multi-user.target (組み込みやサーバー環境での限定コンソールオンリーブート用; graphical.target のサブセット) のエイリアス (symlink) になっているだけである。 しかし、他のターゲットユニットへのエイリアスとして設定することは管理者の裁量に任されている。これらのターゲットユニットについての詳細は systemd.special(7) を参照すること。systemd はメモリにロードされた最小限のユニットセットだけを保持する。具体的には、以下の条件のうち少なくとも1つが真であるユニットのみがメモリにロードされた状態で保持される:

1. 活性状態、活性化状態、非活性化状態、故障状態である（すなわち、「非活性」以外のユニット状態である）
2. ジョブがキューに入っている
3. メモリにロードされた少なくとも1つの他のユニットの依存関係である
4. 何らかのリソースがまだ割り当てられている（例：非アクティブだが、終了要求を無視したプロセスがまだ残っているサービスユニット）
5. D-Busコールによりプログラム的にメモリに固定されている

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

systemd が生成するプロセスは、プライベートな systemd 階層で所属するユニットの名前が付けられた個々の Linux control group に配置される。(コントロールグループについての詳しい情報は cgroups.txt を見ること、略して "cgroups" と言いう) systemd はこれを利用して効果的にプロセスを追跡している。制御グループの情報はカーネルで管理されており、ファイルシステム階層 (/sys/fs/cgroup/systemd/ の下) や systemd-cgls や ps (ps xawf -eo pid,user,cgroup,args は全てのプロセスとそれらが属する systemd ユニットの一覧を表示するのに特に役立つ) からアクセスすることができる。

systemd は SysV init システムとかなりの程度互換性があります。SysV init スクリプトはサポートされており、(制限はありますが) 代替の設定ファイルフォーマットとして単純に読み込める。SysV /dev/initctl インターフェースが提供され、様々な SysV クライアントツールの互換性のある実装が利用可能である。そのほか、/etc/fstabやutmpデータベースなど、定評あるUnixの各種機能がサポートされている。

systemd は最小限のトランザクションシステムを持っている。もしあるユニットがスタートアップやシャットダウンを要求されると、そのユニットと全ての依存関係を一時的なトランザクションに追加する。そして、そのトランザクションが一貫しているかどうか（つまり、全てのユニットの順序がサイクルフリーであるかどうか）を検証する。もしそうでなければ、systemd はそれを修正しようとし、ループを取り除くような必要のないジョブをトランザクションから削除する。また、systemd は、実行中のサービスを停止させるような、トランザクション内の非本質的なジョブを抑制しようとする。最後に、そのトランザクションのジョブがすでにキューに入っているジョブと矛盾しないかがチェックされ、オプションでトランザクションが中断される。すべてがうまくいき、トランザクションが一貫しており、その影響が最小限であれば、それはすでにあるすべての未処理のジョブにマージされ、実行キューに追加される。事実上これは、要求された処理を実行する前に、systemd はそれが意味をなすかどうかを検証し、可能であれば修正し、本当に動作しない場合にのみ失敗させるということを意味する。

トランザクションは、実行時のユニットの状態とは無関係に生成されることに注意すること。したがって、たとえば、開始ジョブがすでに開始されたユニット上で要求された場合、それはまだトランザクションを生成し、非アクティブな依存関係を起こす（そして定義された関係に従って、他のジョブの伝播を引き起こす）でしょう。これは、キューに入れられたジョブが実行時にターゲットユニットの状態と比較され、両方が満足したときに成功・完了とマークされるからである。しかし、このジョブは、定義された関係によって他の依存関係も引き込むので、この例では、それらの非アクティブなユニットのいずれかの開始ジョブもキューに入れられることになる。

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

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

systemd が提供するインターフェースの一部（全てではない）は Interface Portability and Stability Promise によってカバーされていることに注意すること。

ユニットはブート時やシステムマネージャーのリロード時に、例えば他の設定ファイルやカーネルコマンドラインで渡されたパラメータを元に動的に生成されることがあります。詳しくは systemd.generator(7) を見ること。

systemd の D-Bus API は org.freedesktop.systemd1(5) と org.freedesktop.LogControl1(5) で説明されている。

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

DIRECTORIES

System unit directories

systemd システムマネージャは、様々なディレクトリからユニットの設定を読み込む。ユニットファイルをインストールしたいパッケージは、pkg-config systemd --variable=systemdsystemunitdir が返すディレクトリにユニットファイルを置かなければならない。他のディレクトリは /usr/local/lib/systemd/system と /lib/systemd/system でチェックされる。pkg-config systemd --variable=systemdsystemconfdir は、システム設定ディレクトリのパ スを返す。パッケージは、systemctl ツールの enable と disable コマンドを使用してのみ、これらのディレクトリの内容を変更する必要がある。ディレクトリの完全なリストは systemd.unit(5) で提供されている。

User unit directories

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

SysV init scripts directory

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

SysV runlevel link farm directory

SysVランレベルリンクファームのディレクトリの位置はディストリビューションによって異なります。systemdはサービスを有効にするかどうかを判断する際にリンクファームを考慮する。ネイティブなユニット設定ファイルを持つサービスユニットは、SysV runlevelリンクファームで有効化しても起動できないことに注意すること。

SIGNALS

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 モードに入り、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+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 に相当する方法で、サービスマネージャのログレベルを "debug" に設定する。

SIGRTMIN+23

ログレベルを設定された値に戻す。設定された値は、優先順位の高い順に、カーネルコマンドラインの systemd.log-level= で指定された値、設定ファイルの LogLevel= で指定された値、または内蔵のデフォルトである "info" から取得される。

SIGRTMIN+24

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

SIGRTMIN+26

ログターゲットを設定された値に戻す。設定された値は、優先順位の高い順に、カーネルコマンドラインの systemd.log-target= で指定された値、設定ファイルの LogTarget= で指定された値、またはビルトインのデフォルト値から導かれたものである。

SIGRTMIN+27, SIGRTMIN+28

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

ENVIRONMENT

$SYSTEMD_LOG_COLOR

systemd が重要なログメッセージをハイライトするかどうかを制御する。これは --log-color= で上書きすることができる。

$SYSTEMD_LOG_LEVEL

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

$SYSTEMD_LOG_LOCATION

systemd がログメッセージと一緒にコードの場所を表示するかどうかを制御する。これは --log-location= で上書きすることができる。

$SYSTEMD_LOG_TARGET

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

$SYSTEMD_LOG_TIME

systemd がログメッセージの先頭に現在時刻をつけるかどうかを制御する。これは --log-time= で上書きすることができる。

$SYSTEMD_LOG_TID

systemd がログメッセージの前に現在のスレッド ID (TID) を置くかどうかを制御する。

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS

systemd のユーザーマネージャーは、XDG Base Directory 仕様に従って、これらの変数を使用して設定を検索している。

$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH

systemd がユニットファイルやジェネレータを探す場所を制御する。

これらの変数にはコロン (":") で区切られたパスのリストを入れることができる。設定されたとき、リストが空のコンポーネント ("...:") で終わっていれば、このリストが通常のパスのセットの前に追加される。そうでない場合は、指定されたリストが通常のパスの集合を置き換える。

$SYSTEMD_SYSVINIT_PATH

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

$SYSTEMD_SYSVRCND_PATH

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

$SYSTEMD_PAGER

--no-pagerが与えられない場合に使用するページャーである。$SYSTEMD_PAGER も $PAGER も設定されていない場合、 less と more を含む、よく知られたページャの実装を順番に試し、 ひとつ見つかるまでに待つ。ページャーの実装が見つからなかった場合、ページャーは起動されない。この環境変数に空の文字列または "cat" という値を設定することは、 --no-pager を渡すことと等しい。

$SYSTEMD_LESS

less に渡されるオプションを上書きする (デフォルトは "FRSXMK").

ユーザーは特に2つのオプションを変更したいと思うかもしれない:

K

このオプションは、Ctrl+C が押された時に直ちにページャーを終了するように指示する。ページャのコマンドプロンプトに戻るために、 less が Ctrl+C 自体を処理できるようにするには、このオプションをアンセットする。

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

X

このオプションは、ターミナルに termcap 初期化および非初期化文字列を送信しないようにページャに指示する。デフォルトでは、ページャーが終了した後でも、コマンド出力がターミナルに表示されたままになるように設定されている。しかし、これはページャの機能のいくつかを動作させるのを妨げる。

詳細は、lessを参照すること。

$SYSTEMD_LESSCHARSET

less に渡される文字セットを上書きする (デフォルトは "utf-8" で、起動した端末が UTF-8 互換であると判断された場合)。

$SYSTEMD_PAGERSECURE

booleanの引数を取る。trueの場合、ページャーの "セキュア "モードが有効になり、falseの場合は無効になる。$SYSTEMD_PAGERSECURE が全く設定されていない場合、有効な UID がログインセッションの所有者と同じでない場合、セキュアモードが有効になる、 geteuid(2) と sd_pid_get_owner_uid(3) を参照すること。セキュアモードでは、ページャーを起動する際に LESSSECURE=1 が設定され、ページャーは新しいファイルを開いたり作成したり、 新しいサブプロセスを開始するコマンドを無効にしなければならない。$SYSTEMD_PAGERSECURE が全く設定されていない場合、 セキュアモードを実装していないことが知られているページャーは使われない。(現在では less だけがセキュアモードを実装している)。

注意: sudo や pkexec など、昇格した特権でコマンドを呼び出す場合、意図しない対話機能が有効にならないように注意する必要がある。ページャの「セキュア」モードは、上記のように自動的に有効化されることがある。$SYSTEMD_PAGERSECURE=0 に設定するか、継承された環境から削除しないと、 ユーザーが任意のコマンドを呼び出すことができるようになる。$SYSTEMD_PAGERまたは$PAGER変数を使用する場合、以下の点に注意すること。$SYSTEMD_PAGERSECUREも設定する必要がある。代わりに --no-pager を使ってページャーを完全に無効にするのが合理的かもしれない。

$SYSTEMD_COLORS

値はブール値でなければならない。色つきの出力を生成するかどうかを制御する。これを指定すると、systemd が $TERM とコンソールの接続先に基づいて行う決定を上書きすることができる。

$SYSTEMD_URLIFY

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

$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES

ソケットベースの起動時に監視対象プロセスのために systemd によって設定される。詳しくは sd_listen_fds(3) を参照すること。

$NOTIFY_SOCKET

監視対象プロセスのために systemd によって設定され、ステータスとスタートアップ完了の通知を行う。詳しくは sd_notify(3) を参照。

systemd とその様々なコンポーネントが理解するその他の環境変数については、Known Environment Variables を参照すること。

KERNEL COMMAND LINE

システムインスタンスとして実行されたとき、systemd は以下にリストされた多くのオプションをパースする。これらはカーネルコマンドラインの引数として指定するか、"SystemdOptions" EFI 変数 (EFI システム上) を通して指定することが可能である。カーネルコマンドラインがより高い優先度を持つ。以下の変数が理解される。

systemd.unit=, rd.systemd.unit=

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

systemd.dump_core

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

systemd.crash_chvt

正の整数またはboolean型の引数を取る。引数なしで指定することもでき、その場合は正の boolean と同じ効果がある。正の整数（1-63 の範囲）が指定された場合、システムマネージャ（PID 1）がクラッシュしたときに指定された仮想端末をアクティブにする。デフォルトは disabled で、このような切り替えは行われないことを意味する。enabled に設定すると、カーネルメッセージが書き込まれる仮想ターミナルが代わりに使用される。

systemd.crash_shell

boolean 引数を取るか、引数なしで指定された場合、オプションを有効にする。有効な場合、システムマネージャ (PID 1) がクラッシュしたとき、10秒間の遅延の後、シェルを起動する。そうでない場合は、シェルは生成されない。デフォルトは disabled で、これはセキュリティ上の理由からで、シェルはパスワード認証で保護されないからである。

systemd.crash_reboot

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

systemd.confirm_spawn

boolean 引数、または確認メッセージを出力する仮想コンソールへのパスを指定します。引数なしで指定することもでき、その場合は正の boolean と同じ効果がある。有効にすると、システムマネージャ (PID 1) は /dev/console を使ってプロセスを生成する際に確認を求める。パスまたはコンソール名 (たとえば "ttyS0") が指定された場合、このパスまたは give name で指定された仮想コンソールが代わりに使用される。デフォルトは無効である。

systemd.service_watchdogs=

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

systemd.show_status

boolean引数、または定数errorとautoを取る。引数なしで指定することもでき、その場合は正の boolean と同じ効果がある。有効にすると、システムマネージャー (PID 1) は起動中にコンソールに簡潔なサービスステータスの更新を表示する。error を指定すると、失敗に関するメッセージのみが表示され、それ以外は静かにブートされる。デフォルトは有効で、カーネルコマンドラインオプションとして quiet が渡されない限りは、デフォルトはerrorになりなる。指定された場合、システムマネージャコンフィギュレーションファイルのオプション ShowStatus= を上書きします (systemd-system.conf を参照すること)。

systemd.status_unit_format=

値として name または description のいずれかを取る。name の場合、システムマネージャはステータスメッセージにユニット名を使用する。指定された場合、システムマネージャの設定ファイルのオプション StatusUnitFormat= を上書きする (systemd-system.conf を参照すること)。

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

$SYSTEMD_LOG_COLOR、$SYSTEMD_LOG_LEVEL、$SYSTEMD_LOG_LOCATION、$SYSTEMD_LOG_TARGET、$SYSTEMD_LOG_TIME、および $SYSTEMD_LOG_TID 環境変数は、ログ出力を制御し、上記の変数と同じ効果を発揮する。 systemd.log_color, systemd.log_location, systemd.log_time, systemd.log_tid= は引数なしで指定でき、正のbool値と同じ効果がある。

systemd.default_standard_output=, systemd.default_standard_error=

サービスやソケットのデフォルトの標準出力とエラー出力を制御する。つまり、StandardOutput= と StandardError= のデフォルトを制御する (詳しくは systemd.exec(5) を参照)。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=

マシンIDの設定に使用される32文字の16進数値を取る。主にネットワークブート用で、ブート毎に同じマシンIDが必要な場合を想定している。

systemd.unified_cgroup_hierarchy

引数なしまたは真の引数で指定すると、unified cgroup hierarchy (別名 cgroups-v2) を使用できるようになる。false 引数を指定すると、ハイブリッドまたは完全なlegacy cgroup hierarchyにフォールバックする。

このオプションが指定されない場合、デフォルトの動作はコンパイル時に決定される (-Default-hierarchy= meson オプション)。カーネルがunified cgroup hierachyをサポートしていない場合、このオプションが指定されていてもlegacy hierarchyが使用される。

systemd.legacy_systemd_cgroup_controller

完全なunified cgroup hierarchyが使用されない場合、有効になる (前のオプションを参照)。引数なしまたは true を指定すると、''hybrid'' cgroup hierarchy (systemd で使用する cgroups-v2 ツリーと他のコントローラで使用するlegacy cgroup hierarchy (cgroups-v1)) を使用できなくなり、完全に''legacy'' modeが強制的に使用されるようになります。false 引数を指定すると、''hybrid'' hierarchyを使用できるようになる。

このオプションが指定されない場合、デフォルトの動作はコンパイル時に決定される (-Default-hierarchy= meson オプション)。カーネルが unified cgroup hierarchy をサポートしていない場合、このオプションが指定されていてもレガシー階層が使用される。

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 と locale(7) を参照すること。

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

OPTIONS

systemd が直接起動されることは非常に稀である。なぜなら、systemd は早期に起動され、ユーザーが操作する頃には既に起動しているからである。通常、systemctl のようなツールがマネージャにコマンドを与えるために使われる。systemd は通常直接起動されないので、以下のオプションは主にデバッグや特別な目的のために役に立つ。

Introspection and debugging options

これらのオプションはテストとイントロスペクションのために使われ、systemd はいつでもこれらを使って起動することができる：

--dump-configuration-items

理解されたユニット設定項目をダンプする。これは、ユニット定義ファイルで理解される構成項目の簡潔だが完全なリストを出力する。

--dump-bus-properties

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

--test

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

--system, --user

test と一緒に使用すると、初期トランザクションをシステム・インスタンスとユーザー単位のインスタンスのどちらで計算するかを選択する。これらのオプションは、--test なしで起動した場合には何の効果もない。通常の (つまり --test 以外) 起動時には、サービス・マネージャは実行する PID が 1 であるかどうかをチェックすることにより、システム・モードとユーザー単位のモードのどちらで動作するかを自動的に検出するからである。サービスマネージャが --system モードで動作しているが、PID が 1 以外である場合のシステムの起動とメンテナンスはサポートされないことに注意すること。

-h, --help

短いヘルプテキストを表示し、終了する

--version

短いバージョン文字列を表示し、終了する

Options that duplicate kernel command line settings

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

systemd がユーザーマネージャとして使われる場合、カーネルコマンドラインは無視され、以下に説明するオプションのみが理解される。とはいえ、systemd は通常このモードで user@.service(5) サービスを通して起動され、これは全てのユーザで共有される。設定を変更するために設定ファイルを使ったり ([/etc/systemd|systemd-user.conf](5) 参照)、 Environment セクションで上に挙げた環境変数の1つを指定するドロップイン (systemd.exec(5) の Environment= と EnvironmentFile= の議論参照) を使うとより便利かもしれない。

--unit=

起動時に起動するデフォルトのユニットを設定する。指定しない場合、デフォルトは default.target です。上記の systemd.unit= を参照すること。

--dump-core

クラッシュ時のコアダンプを有効にする。このスイッチはユーザインスタンスとして動作しているときは効果がない。上記の systemd.dump_core= と同じである。

--crash-vt=VT

クラッシュ時に特定の仮想コンソール (VT) に切り替える。このスイッチはユーザーインスタンスとして動作しているときは効果がない。上の systemd.crash_chvt= と同じである (ただしスペルは違う!)。

--crash-shell

クラッシュ時にシェルを実行する。このスイッチはユーザインスタンスとして動作しているときは効果がない。上記の systemd.crash_shell= を参照すること。

--crash-reboot

クラッシュ時に自動的にシステムを再起動する。このスイッチはユーザーインスタンスとして動作しているときは効果がない。上記の systemd.crash_reboot を参照すること。

--confirm-spawn

プロセスを生成する際に確認を求める。このスイッチはユーザーインスタンスとして実行された場合は効果がない。上記の systemd.confirm_spawn をすること。

--show-status

起動時やシャットダウン時に、コンソールに簡潔なユニットステータス情報を表示する。上記の systemd.show_status を参照すること。

--log-color

重要なログメッセージを強調表示する。上記の systemd.log_color を参照すること。

--log-level=

ログレベルを設定する。上記の systemd.log_levelを参照すること。

--log-location

ログメッセージにコードの場所を含める。上記の systemd.log_location を参照すること。

--log-target=

ログターゲットを設定する。上記の systemd.log_target を参照すること。

--log-time=

メッセージのプレフィックスはタイムスタンプにする。上記の systemd.log_time を参照すること。

--machine-id=

ハードディスクに設定されている machine-id を上書きする。上記の systemd.machine_id= を参照すること。

--service-watchdogs

全てのサービスウォッチドッグのタイムアウトと緊急アクションをグローバルに有効／無効にする。上記の systemd.service_watchdogs を参照すること。

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

全てのサービスとソケットに対して、それぞれデフォルトの出力とエラーの出力を設定する。上記の systemd.default_standard_output= と systemd.default_standard_error= を参照すること。

SOCKETS AND FIFOS

/run/systemd/notify

デーモン状態通知ソケット。これは AF_UNIX のデータグラムソケットで、 sd_notify(3) で実装されているデーモン通知ロジックを実装するために使用される。

/run/systemd/private

systemctl と systemd プロセスの間の通信チャネルとして内部的に使われる。これは AF_UNIX ストリームソケットである。このインターフェースは systemd のプライベートなものであり、外部のプロジェクトで使用するべきではない。

/dev/initctl

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

SEE ALSO

systemd Homepage, systemd-system.conf, locale.conf, systemctl, journalctl, systemd-notify, 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)

External link

• Wikipedia