「Systemd」の版間の差分
細 |
|||
(4人の利用者による、間の42版が非表示) | |||
2行目: | 2行目: | ||
[[Category:デーモンとシステムサービス]] |
[[Category:デーモンとシステムサービス]] |
||
[[Category:ブートプロセス]] |
[[Category:ブートプロセス]] |
||
+ | [[Category:Init]] |
||
[[ar:Systemd]] |
[[ar:Systemd]] |
||
[[de:Systemd]] |
[[de:Systemd]] |
||
+ | [[fa:Systemd]] |
||
[[el:Systemd]] |
[[el:Systemd]] |
||
[[en:Systemd]] |
[[en:Systemd]] |
||
11行目: | 13行目: | ||
[[pt:Systemd]] |
[[pt:Systemd]] |
||
[[ru:Systemd]] |
[[ru:Systemd]] |
||
− | [[zh- |
+ | [[zh-hans:Systemd]] |
− | [[zh- |
+ | [[zh-hant:Systemd]] |
{{Related articles start}} |
{{Related articles start}} |
||
{{Related|systemd/ユーザー}} |
{{Related|systemd/ユーザー}} |
||
{{Related|systemd/タイマー}} |
{{Related|systemd/タイマー}} |
||
+ | {{Related|systemd/ジャーナル}} |
||
{{Related|systemd FAQ}} |
{{Related|systemd FAQ}} |
||
{{Related|init}} |
{{Related|init}} |
||
25行目: | 28行目: | ||
{{Related articles end}} |
{{Related articles end}} |
||
− | [ |
+ | [https://freedesktop.org/wiki/Software/systemd プロジェクトウェブページ] より: |
− | :'''systemd''' は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。'''systemd''' はサービスの起動を積極的に並行化します。また、ソケットや [[D-Bus]] のアクティベーションを使用してサービスを起動し、必要なデーモンの開始を行うことができ、Linux の [[cgroups]] によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動) マウントポイントの管理、煩雑な依存関係に基づいたサービスのコントロールを処理します。 |
+ | :'''systemd''' は Linux 環境の基本構成スイートであり、SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。'''systemd''' はサービスの起動を積極的に並行化します。また、ソケットや [[D-Bus]] のアクティベーションを使用してサービスを起動し、必要なデーモンの開始を行うことができ、Linux の [[cgroups]] によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動) マウントポイントの管理、煩雑な依存関係に基づいたサービスのコントロールを処理します。''systemd'' は sysvinit の代替として SysV や LSB init スクリプトをサポートしています。init としての機能以外にも、ログデーモンやホストネーム・時刻・ロケールなどシステムの基本設定を制御するユーティリティ、ログイン中のユーザーから実行中のコンテナや仮想マシン、システムアカウントまで管理する機能、ネットワーク設定や時刻同期あるいは名前解決などを管理するシンプルなデーモンも含まれています。 |
{{Note|1=systemd が Arch に採用された理由については、[https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 フォーラムへのこの投稿]をご覧ください。}} |
{{Note|1=systemd が Arch に採用された理由については、[https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 フォーラムへのこの投稿]をご覧ください。}} |
||
33行目: | 36行目: | ||
== systemctl の基本的な使い方 == |
== systemctl の基本的な使い方 == |
||
− | ''systemd'' を管理したり内部情報を見るために使うメインのコマンドが {{ic|systemctl}} です。システムの状態を確かめたりシステムやサービスを管理するために使うのは使い方の一部です。詳しくは {{ |
+ | ''systemd'' を管理したり内部情報を見るために使うメインのコマンドが {{ic|systemctl}} です。システムの状態を確かめたりシステムやサービスを管理するために使うのは使い方の一部です。詳しくは {{man|1|systemctl}} を見て下さい。 |
{{Tip| |
{{Tip| |
||
*{{ic|systemctl}} コマンドに {{ic|-H <user>@<host>}} を渡すと、リモートの systemd と対話できます。[[Secure Shell|SSH]] を利用してリモートの systemd インスタンスに繋ぐのに使われます。 |
*{{ic|systemctl}} コマンドに {{ic|-H <user>@<host>}} を渡すと、リモートの systemd と対話できます。[[Secure Shell|SSH]] を利用してリモートの systemd インスタンスに繋ぐのに使われます。 |
||
− | *{{ic|systemctl}} の公式グラフィカルフロントエンドとして {{ic|systemadm}} が存在します。[[公式リポジトリ]]からインストールできる {{Pkg|systemd-ui}} に入っています。 |
+ | *{{ic|systemctl}} の公式グラフィカルフロントエンドとして {{ic|systemadm}} が存在します。[[公式リポジトリ]]からインストールできる {{Pkg|systemd-ui}} に入っています。 |
+ | * [[Plasma]] を使っている場合 {{AUR|systemd-kcm}} をインストールすることで ''systemctl'' のグラフィカルフロントエンドを使えます。モジュールをインストールすると ''System administration'' の下に設定が追加されます。}} |
||
=== システムの状態を分析する === |
=== システムの状態を分析する === |
||
+ | |||
+ | システムの状態を表示: |
||
+ | |||
+ | $ systemctl status |
||
実行中のユニットを一覧する: |
実行中のユニットを一覧する: |
||
63行目: | 71行目: | ||
{{ic|systemctl}} を使うとき、一般的には拡張子 (suffix) を含むユニットファイルの完全な名前を指定する必要があります。例えば、{{ic|sshd.socket}} のように。しかし、以下のような場合には省略形が存在します: |
{{ic|systemctl}} を使うとき、一般的には拡張子 (suffix) を含むユニットファイルの完全な名前を指定する必要があります。例えば、{{ic|sshd.socket}} のように。しかし、以下のような場合には省略形が存在します: |
||
− | * 拡張子が指定されない場合、systemctlは {{ic|.service}} とみなします。例えば {{ic|netctl}} と {{ic|netctl.service}} は同じように扱われます。 |
+ | * 拡張子が指定されない場合、systemctl は {{ic|.service}} とみなします。例えば {{ic|netctl}} と {{ic|netctl.service}} は同じように扱われます。 |
* マウントポイントは自動的に対応する {{ic|.mount}} ユニットとして扱われます。例えば、{{ic|/home}} を指定することは {{ic|home.mount}} の指定と同じです。 |
* マウントポイントは自動的に対応する {{ic|.mount}} ユニットとして扱われます。例えば、{{ic|/home}} を指定することは {{ic|home.mount}} の指定と同じです。 |
||
* マウントポイントと同じく、デバイスも自動的に対応する {{ic|.device}} ユニットとして扱われます。従って、{{ic|/dev/sda2}} の指定は {{ic|dev-sda2.device}} と同じです。 |
* マウントポイントと同じく、デバイスも自動的に対応する {{ic|.device}} ユニットとして扱われます。従って、{{ic|/dev/sda2}} の指定は {{ic|dev-sda2.device}} と同じです。 |
||
− | 詳細は {{ |
+ | 詳細は {{man|5|systemd.unit}} を見てください。 |
{{Note|ユニットによっては名前に {{ic|@}} 記号が含まれていることがあります (例: {{ic|name@''string''.service}}): これは、そのサービスが''テンプレート''ユニットの [http://0pointer.de/blog/projects/instances.html インスタンス] であることを意味しており、テンプレートユニットのファイル名には {{ic|''string''}} の部分が含まれていません (例: {{ic|name@.service}})。{{ic|''string''}} は ''instance identifier'' と呼ばれ、''systemctl'' コマンドでテンプレートユニットを実行するときに指定する引数と似ています: ユニットファイルの中の {{ic|%i}} が置き換えられます。 |
{{Note|ユニットによっては名前に {{ic|@}} 記号が含まれていることがあります (例: {{ic|name@''string''.service}}): これは、そのサービスが''テンプレート''ユニットの [http://0pointer.de/blog/projects/instances.html インスタンス] であることを意味しており、テンプレートユニットのファイル名には {{ic|''string''}} の部分が含まれていません (例: {{ic|name@.service}})。{{ic|''string''}} は ''instance identifier'' と呼ばれ、''systemctl'' コマンドでテンプレートユニットを実行するときに指定する引数と似ています: ユニットファイルの中の {{ic|%i}} が置き換えられます。 |
||
74行目: | 82行目: | ||
{{Tip| |
{{Tip| |
||
− | * 以下のコマンドのほとんどは複数のユニットを指定することが可能です、詳しくは {{ |
+ | * 以下のコマンドのほとんどは複数のユニットを指定することが可能です、詳しくは {{man|1|systemctl}} を参照。 |
* パッケージには様々な目的のユニットが入っています。パッケージをインストールしたら、{{ic|pacman -Qql ''package'' <nowiki>|</nowiki> grep -Fe .service -e .socket}} でサービスを確認することができます。 |
* パッケージには様々な目的のユニットが入っています。パッケージをインストールしたら、{{ic|pacman -Qql ''package'' <nowiki>|</nowiki> grep -Fe .service -e .socket}} でサービスを確認することができます。 |
||
}} |
}} |
||
105行目: | 113行目: | ||
# systemctl enable ''unit'' |
# systemctl enable ''unit'' |
||
+ | |||
+ | ユニットを有効化して今すぐ起動する: |
||
+ | |||
+ | # systemctl enable --now ''unit'' |
||
システム起動時に実行されないように無効化する: |
システム起動時に実行されないように無効化する: |
||
153行目: | 165行目: | ||
$ systemctl hybrid-sleep |
$ systemctl hybrid-sleep |
||
+ | == ユニットファイル == |
||
− | == ネイティブの設定 == |
||
+ | systemd の [https://www.freedesktop.org/software/systemd/man/systemd.unit.html ユニットファイル] の構文は XDG の Desktop Entry Specification である ''.desktop'' から影響を受けています。そして ''.desktop'' は Microsoft Windows の ''.ini'' ファイルからインスパイアされています。ユニットファイルは複数の場所に配置されます (配置場所のリストを確認するには {{ic|1=systemctl show --property=UnitPath}} を実行してください)。優先度が低い方から説明すると: |
||
− | {{Note|これらのファイルを作る必要があります。全てのファイルのパーティションは {{ic|644}} で所有者は {{ic|root:root}} である必要があります。}} |
||
− | |||
− | === ホストネーム === |
||
− | |||
− | ホストネームは {{ic|/etc/hostname}} で設定します。このファイルにシステムのドメインを含めてはいけません。ホストネームを設定するには: |
||
− | |||
− | # hostnamectl set-hostname '''myhostname''' |
||
− | |||
− | 詳しくは {{ic|man 5 hostname}} や {{ic|man 1 hostnamectl}} を見て下さい。 |
||
− | |||
− | ファイルの設定サンプル: |
||
− | {{hc|/etc/hostname| |
||
− | myhostname |
||
− | }} |
||
− | |||
− | === ロケール === |
||
− | |||
− | デフォルトのシステムロケールは {{ic|/etc/locale.conf}} で設定します。デフォルトロケールをセットするには: |
||
− | |||
− | # localectl set-locale LANG="ja_JP.UTF-8" |
||
− | |||
− | {{Note|デフォルトロケールを設定する前に、{{ic|/etc/locale.gen}} で利用するロケールをアンコメントして {{ic|locale-gen}} を root で実行してロケールを有効にしておく必要があります。{{ic|localectl}} でセットするロケールは {{ic|/etc/locale.gen}} で'''アンコメントされた'''ロケールでなければなりません。}} |
||
− | |||
− | 詳しくは {{ic|man 1 localectl}} や {{ic|man 5 locale.conf}} を見て下さい。 |
||
− | |||
− | * ロケールについての詳しい情報は[[ロケール]]のページにあります。 |
||
− | |||
− | ファイルの設定サンプル: |
||
− | {{hc|/etc/locale.conf|<nowiki> |
||
− | LANG=ja_JP.UTF-8 |
||
− | </nowiki>}} |
||
− | |||
− | === 仮想端末 === |
||
− | |||
− | 仮想端末 (キーボッドマップ、コンソールフォント、コンソールマップ) の設定は {{ic|/etc/vconsole.conf}} です: |
||
− | |||
− | {{hc|/etc/vconsole.conf|2= |
||
− | KEYMAP=jp106 |
||
− | FONT=lat9w-16 |
||
− | FONT_MAP=8859-1_to_uni}} |
||
− | |||
− | {{Note|{{pkg|systemd}}-194 現在、{{ic|1=KEYMAP=}} や {{ic|1=FONT=}} が空だったり設定されていない場合、ビルトインの ''kernel'' フォントと ''us'' キーマップが使われます。}} |
||
− | |||
− | キーボッドマップ(キーマップ)を設定する別の方法は: |
||
− | |||
− | # localectl set-keymap jp106 |
||
− | |||
− | <code>localectl</code> で X11 のキーマップを設定することもできます: |
||
− | |||
− | # localectl set-x11-keymap jp106 |
||
− | |||
− | 詳細は {{ic|man 1 localectl}} や {{ic|man 5 vconsole.conf}} を見て下さい。 |
||
− | |||
− | * 詳しい情報は[[フォント#コンソールフォント|コンソールフォント]]や[[コンソールでのキーボード設定|キーマップ]]を見て下さい。 |
||
− | |||
− | === タイムゾーン === |
||
− | |||
− | タイムゾーンは適切な {{ic|/etc/localtime}} シンボリックリンクを作ることで設定します。リンク先は {{ic|/usr/share/zoneinfo/}} 下のゾーン情報ファイルです。自動で行うには: |
||
− | |||
− | # timedatectl set-timezone Asia/Tokyo |
||
− | |||
− | 詳しくは {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}}, {{ic|man 7 archlinux}} を見て下さい。 |
||
− | |||
− | または、あなた自身でシンボリックリンクを作って下さい: |
||
− | <!-- DO NOT MAKE THIS AN ABSOLUTE SYMLINK, archlinux(7) clearly shows this should be a relative symlink --> |
||
− | # ln -sf ../usr/share/zoneinfo/Asia/Tokyo /etc/localtime |
||
− | |||
− | 古い設定ファイル {{ic|/etc/timezone}} がある場合、削除しても問題ありません。 |
||
− | |||
− | === ファイルシステムのマウント === |
||
− | |||
− | デフォルトのセットアップでは自動的に fsck が行われサービスが起動する前にファイルシステムがマウントされます。例えば、systemd は [[NFS]] や [[Samba]] のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って {{ic|/etc/fstab}} に明記しなくともローカル・リモードどちらのファイルシステムのマウントも問題ありません。 |
||
− | |||
− | 詳しくは {{ic|man 5 systemd.mount}} を見て下さい。 |
||
− | |||
− | ==== Automount ==== |
||
− | |||
− | * {{ic|/home}} パーティションが大きい場合は、{{ic|/home}} を fsck でチェックしている間に {{ic|/home}} を使わないサービスを起動できるようにしたほうがいいかもしれません。これを行うには {{ic|/etc/fstab}} の {{ic|/home}} パーティションのエントリに次のオプションを追加してください: |
||
− | |||
− | noauto,x-systemd.automount |
||
− | |||
− | {{ic|/home}} にアクセスがあるとまず fsck とマウントを行い、準備が整うまで {{ic|/home}} への全てのファイルアクセスをカーネルによって遮断します。 |
||
− | |||
− | Note: オプションの追加によって {{ic|/home}} ファイルシステムのタイプが {{ic|autofs}} になり、[[mlocate]] から(デフォルトで)無視されるようになります。システムによっては、{{ic|/home}} の automount のスピードアップは大して効果がない場合があります。 |
||
− | |||
− | * リモートファイルシステムのマウントにも同じことが当てはまります。アクセス時にのみマウントするようにしたい場合は、{{ic|noauto,x-systemd.automount}} パラメータを使って下さい。さらに、{{ic|1=x-systemd.device-timeout=#}} オプションを使うことでネットワークが切れた時のタイムアウト時間を設定できます。 |
||
− | |||
− | * ファイルシステムをキーファイルで暗号化しているときは、{{ic|/etc/crypttab}} の適切なエントリに {{ic|noauto}} パラメータを追加することもできます。Systemd は起動時に暗号化されたデバイスを開かなくなり、代わりに、デバイスが実際にアクセスされるまで待機して、それから指定したキーファイルで(マウントする前に)自動でデバイスを開くようになります。デバイスが有効になるまで systemd が待機することがなくなるので、暗号化した RAID デバイスなどを使っているときは起動時間が数秒節約できます。例: |
||
− | |||
− | {{hc|/etc/crypttab| |
||
− | data /dev/md0 /root/key noauto}} |
||
− | |||
− | == カスタム .service ファイルを書く == |
||
− | |||
− | systemd の [http://www.freedesktop.org/software/systemd/man/systemd.unit.html ユニットファイル] の構文は XDG の Desktop Entry Specification である ''.desktop'' から影響を受けています。そして ''.desktop'' は Microsoft Windows の ''.ini'' ファイルからインスパイアされています。ユニットファイルは2つの場所に配置されます。優先度が低い方から説明すると: |
||
* {{ic|/usr/lib/systemd/system/}}: インストールしたパッケージに含まれているユニット |
* {{ic|/usr/lib/systemd/system/}}: インストールしたパッケージに含まれているユニット |
||
* {{ic|/etc/systemd/system/}}: システムの管理者がインストールしたユニット |
* {{ic|/etc/systemd/system/}}: システムの管理者がインストールしたユニット |
||
+ | {{Note| |
||
− | {{Note|[[systemd/ユーザー|ユーザーモード]]で ''systemd'' を動作させたときにロードされるパスは完全に異なります。}} |
||
+ | *[[systemd/ユーザー|ユーザーモード]]で ''systemd'' を動作させたときにロードされるパスは完全に異なります。 |
||
+ | *systemd ユニットの名前に使うことができるのは ASCII 英数字とアンダーバー、ピリオドだけです。他の文字列は "\x2d" エスケープに置き換える必要があります。詳しくは {{man|5|systemd.unit}} や {{man|1|systemd-escape}} を見て下さい。 |
||
+ | }} |
||
=== 依存関係を解決する === |
=== 依存関係を解決する === |
||
260行目: | 181行目: | ||
systemd ではユニットファイルを適切に書くことで依存関係を解決します。一番典型的なケースは、ユニット {{ic|A}} が走る前に、ユニット {{ic|A}} がユニット {{ic|B}} を必要としている場合です。この場合、{{ic|A}} の {{ic|[Unit]}} セクションに {{ic|1=Requires=B}} と {{ic|1=After=B}} を加えます。依存が必然ではない場合、代わりに {{ic|1=Wants=B}} と {{ic|1=After=B}} を加えます。{{ic|1=Wants=}} と {{ic|1=Requires=}} は {{ic|1=After=}} を含まないことに注意してください、もし {{ic|1=After=}} を明記しなかったときは、2つのユニットは並行して実行されます。 |
systemd ではユニットファイルを適切に書くことで依存関係を解決します。一番典型的なケースは、ユニット {{ic|A}} が走る前に、ユニット {{ic|A}} がユニット {{ic|B}} を必要としている場合です。この場合、{{ic|A}} の {{ic|[Unit]}} セクションに {{ic|1=Requires=B}} と {{ic|1=After=B}} を加えます。依存が必然ではない場合、代わりに {{ic|1=Wants=B}} と {{ic|1=After=B}} を加えます。{{ic|1=Wants=}} と {{ic|1=Requires=}} は {{ic|1=After=}} を含まないことに注意してください、もし {{ic|1=After=}} を明記しなかったときは、2つのユニットは並行して実行されます。 |
||
− | 基本的に、依存関係はターゲットではなくサービスに |
+ | 基本的に、依存関係は[[#ターゲット|ターゲット]]ではなくサービスに記述します。例えば、{{ic|network.target}} はネットワークインターフェースを設定する全てのサービスによって使われるので、カスタムユニットを起動させる順番は {{ic|network.target}} が起動し終わってからにする必要があります。 |
=== タイプ === |
=== タイプ === |
||
− | カスタムサービスファイルを書くときにどのスタートアップタイプを使うべきか考える必要があります。タイプは {{ic|[Service]}} セクションの {{ic|1=Type=}} パラメータで設定します。より詳しい説明は {{ |
+ | カスタムサービスファイルを書くときにどのスタートアップタイプを使うべきか考える必要があります。タイプは {{ic|[Service]}} セクションの {{ic|1=Type=}} パラメータで設定します。より詳しい説明は {{man|5|systemd.service}} を見て下さい。 |
− | * {{ic|1=Type=simple}} (デフォルト): |
+ | * {{ic|1=Type=simple}} (デフォルト): systemd はプロセスを起動した時点でサービスが立ち上がったとみなします。プロセスをフォークすることはできません。ソケットアクティベーション以外で他のサービスが必要な場合に、このタイプを使ってはいけません。 |
− | * {{ic|1=Type=forking}}: プロセスがフォーク |
+ | * {{ic|1=Type=forking}}: 起動したプロセスが一旦フォークし、親プロセス側が終了したときに、 systemd はサービスが立ち上がったとみなします。このタイプでなくてもかまわないとき以外は、古典的なデーモンにはこのタイプを使って下さい。また {{ic|1=PIDFile=}} を指定することで systemd はメインプロセスの情報を追い続けます。 |
* {{ic|1=Type=oneshot}}: シングルジョブを行い終了するスクリプト用のタイプです。また {{ic|1=RemainAfterExit=yes}} を設定することで systemd はプロセスが終了した後もサービスがアクティブだとみなします。 |
* {{ic|1=Type=oneshot}}: シングルジョブを行い終了するスクリプト用のタイプです。また {{ic|1=RemainAfterExit=yes}} を設定することで systemd はプロセスが終了した後もサービスがアクティブだとみなします。 |
||
* {{ic|1=Type=notify}}: {{ic|1=Type=simple}} と同じですが、利用可能になったときにデーモンが systemd に信号を送るように条件がつけられます。この通知のリファレンス実装は {{ic|libsystemd-daemon.so}} によって提供されています。 |
* {{ic|1=Type=notify}}: {{ic|1=Type=simple}} と同じですが、利用可能になったときにデーモンが systemd に信号を送るように条件がつけられます。この通知のリファレンス実装は {{ic|libsystemd-daemon.so}} によって提供されています。 |
||
275行目: | 196行目: | ||
=== ユニットファイルの編集 === |
=== ユニットファイルの編集 === |
||
− | パッケージに入っているユニットファイルを編集する方法は2つあります: 新しいユニットファイルで完全に置き換えるか、ドロップイン |
+ | パッケージに入っているユニットファイルを編集する方法は2つあります: 新しいユニットファイルで[[#ユニットファイルを置換する|完全に置き換える]]か、[[#ドロップインファイル|ドロップインファイル]]を作成して既存のユニットファイルに上書きして適用させるかです。どちらの方法でも、変更を加えた後はユニットをリロードする必要があります。{{ic|systemctl edit}} でユニットを編集するか (自動でユニットがリロードされます) または次のコマンドで全てのユニットをリロードしてください: |
# systemctl daemon-reload |
# systemctl daemon-reload |
||
281行目: | 202行目: | ||
{{Tip| |
{{Tip| |
||
* {{ic|systemd-delta}} を使うことでどのファイルが上書きされ、どこが変更されたのか調べることができます。 |
* {{ic|systemd-delta}} を使うことでどのファイルが上書きされ、どこが変更されたのか調べることができます。 |
||
− | * ユニットファイルや関連するドロップイン |
+ | * ユニットファイルや関連するドロップインファイルの中身を見るには {{ic|systemctl cat ''unit''}} を使います。 |
− | * [[公式リポジトリ]]から {{ |
+ | * [[公式リポジトリ]]から {{AUR|vim-systemd}} をインストールすることで、[[Vim]] で ''systemd'' ユニットファイルのシンタックスハイライトが可能です。 |
}} |
}} |
||
299行目: | 220行目: | ||
{{Note|Pacman は元のユニットファイルが更新されても置き換えられたユニットファイルをアップデートしません。そのため、この方法ではシステムメンテナンスが多少厄介になります。この理由があるために、次のセクションで説明する方法の方が推奨されます。}} |
{{Note|Pacman は元のユニットファイルが更新されても置き換えられたユニットファイルをアップデートしません。そのため、この方法ではシステムメンテナンスが多少厄介になります。この理由があるために、次のセクションで説明する方法の方が推奨されます。}} |
||
− | ==== ドロップイン |
+ | ==== ドロップインファイル ==== |
− | ユニットファイル {{ic|/usr/lib/systemd/system/''unit''}} のドロップイン |
+ | ユニットファイル {{ic|/usr/lib/systemd/system/''unit''}} のドロップインファイルを作成するには、{{ic|/etc/systemd/system/''unit''.d/}} という名のディレクトリ (例: {{ic|/etc/systemd/system/httpd.service.d/}}) を作成してその中に {{ic|*.conf}} を配置します。このファイルを使ってオプションを上書きしたり追加してください。''systemd'' が {{ic|*.conf}} ファイルをパースして元のユニットファイルの一番上に設定を適用します。 |
− | ドロップイン |
+ | ドロップインファイルを作成する一番簡単な方法は次のコマンドを実行することです: |
# systemctl edit ''unit'' |
# systemctl edit ''unit'' |
||
テキストエディタで {{ic|/etc/systemd/system/''unit''.d/override.conf}} ファイルが開かれ (必要であればファイルが作成されます)、編集を終えた時に自動でユニットがリロードされます。 |
テキストエディタで {{ic|/etc/systemd/system/''unit''.d/override.conf}} ファイルが開かれ (必要であればファイルが作成されます)、編集を終えた時に自動でユニットがリロードされます。 |
||
+ | |||
+ | ==== 初期状態にリバート ==== |
||
+ | |||
+ | {{ic|systemctl edit}} を使って変更したユニットを元に戻したい場合、以下のコマンドを実行: |
||
+ | |||
+ | # systemctl revert ''unit'' |
||
==== サンプル ==== |
==== サンプル ==== |
||
325行目: | 252行目: | ||
ExecStart=''new command''}} |
ExecStart=''new command''}} |
||
− | {{Note|1={{ic|ExecStart}} は置き換える前に空白にする必要があるので注意してください ([https://bugzilla.redhat.com/show_bug.cgi?id=756787#c9])。}} |
+ | {{Note|1={{ic|ExecStart}} は置き換える前に空白にする必要があるので注意してください ([https://bugzilla.redhat.com/show_bug.cgi?id=756787#c9])。タイマーの {{ic|OnCalendar}} など複数回指定できるアイテムも同じです。}} |
サービスが自動的に再起動されるようにするには: |
サービスが自動的に再起動されるようにするには: |
||
348行目: | 275行目: | ||
標準の Fedora インストールではランレベルごとに特定の目的が設定されています; 0, 1, 3, 5, 6 のランレベルには特定の sytemd ''ターゲット''と一対一の対応関係が存在します。残念ながら、ユーザー定義のランレベル (2 や 4 など) で同じことをする良い方法はありません。もしあなたがそうしたいならば、既に存在しているランレベルをベースに新しい systemd ''ターゲット''を {{ic|/etc/systemd/system/<your target>}} として作り ({{ic|/usr/lib/systemd/system/graphical.target}} がサンプルになるかもしれません)、{{ic|/etc/systemd/system/<your target>.wants}} ディレクトリを作って、有効にしたいサービスに {{ic|/usr/lib/systemd/system/}} からシンボリックリンクを貼ることが示唆されています。 |
標準の Fedora インストールではランレベルごとに特定の目的が設定されています; 0, 1, 3, 5, 6 のランレベルには特定の sytemd ''ターゲット''と一対一の対応関係が存在します。残念ながら、ユーザー定義のランレベル (2 や 4 など) で同じことをする良い方法はありません。もしあなたがそうしたいならば、既に存在しているランレベルをベースに新しい systemd ''ターゲット''を {{ic|/etc/systemd/system/<your target>}} として作り ({{ic|/usr/lib/systemd/system/graphical.target}} がサンプルになるかもしれません)、{{ic|/etc/systemd/system/<your target>.wants}} ディレクトリを作って、有効にしたいサービスに {{ic|/usr/lib/systemd/system/}} からシンボリックリンクを貼ることが示唆されています。 |
||
− | === ターゲット表 === |
+ | === SysV ランレベルと systemd ターゲットの対応表 === |
{| class="wikitable" |
{| class="wikitable" |
||
389行目: | 316行目: | ||
# systemctl set-default multi-user.target |
# systemctl set-default multi-user.target |
||
− | |||
− | 以前に設定した ''default.target'' を上書きできるようにするには、force オプションを使って下さい: |
||
− | |||
− | # systemctl set-default -f multi-user.target |
||
− | |||
− | このコマンドの効果は {{ic|systemctl}} によって出力されます; 新しいデフォルトターゲットのシンボリックリンクは {{ic|/etc/systemd/system/default.target}} に作成されます。 |
||
== 一時ファイル == |
== 一時ファイル == |
||
410行目: | 331行目: | ||
w /proc/acpi/wakeup - - - - USBE}} |
w /proc/acpi/wakeup - - - - USBE}} |
||
− | 詳細は {{ |
+ | 詳細は {{man|8|systemd-tmpfiles}} や {{man|5|tmpfiles.d}} の man ページを参照してください。 |
{{Note|''systemd-tmpfiles-setup'' サービスは適切なモジュールがロードされる前に実行されることがあるので、{{ic|/sys}} にオプションを設定するのにこの方法は使えません。このため設定したいオプションのパラメータをモジュールが持っているか確認するには {{ic|modinfo ''module''}} を使い、オプションを設定は [[カーネルモジュール#設定|/etc/modprobe.d 下の設定ファイル]]を使って下さい。もしくはデバイスが現れたときにすぐ適切な属性を設定する [[Udev#udev ルールについて|udev ルール]]を書いて下さい。}} |
{{Note|''systemd-tmpfiles-setup'' サービスは適切なモジュールがロードされる前に実行されることがあるので、{{ic|/sys}} にオプションを設定するのにこの方法は使えません。このため設定したいオプションのパラメータをモジュールが持っているか確認するには {{ic|modinfo ''module''}} を使い、オプションを設定は [[カーネルモジュール#設定|/etc/modprobe.d 下の設定ファイル]]を使って下さい。もしくはデバイスが現れたときにすぐ適切な属性を設定する [[Udev#udev ルールについて|udev ルール]]を書いて下さい。}} |
||
418行目: | 339行目: | ||
タイマーは ".timer" で終わる名前を持つユニット設定ファイルで、時間に基づく実行を行うために、''systemd'' で制御・管理するタイマーの情報をエンコードしています。[[systemd/タイマー]] を参照してください。 |
タイマーは ".timer" で終わる名前を持つユニット設定ファイルで、時間に基づく実行を行うために、''systemd'' で制御・管理するタイマーの情報をエンコードしています。[[systemd/タイマー]] を参照してください。 |
||
− | {{Note|タイマーは cron の機能をほぼ全て置き換えることができます。詳しくは、[[systemd/タイマー#cron を置き換える]] を参照してください。}} |
+ | {{Note|タイマーは [[cron]] の機能をほぼ全て置き換えることができます。詳しくは、[[systemd/タイマー#cron を置き換える]] を参照してください。}} |
− | == |
+ | == マウント == |
− | systemd は、バージョン 38 から自前のログシステムである journal を搭載しています。従って、syslog デーモンを起動する必要はもはやありません。ログを読むには: |
||
+ | systemd は System V init を置き換えるため、{{ic|/etc/fstab}} に指定されたマウントも処理します。起動時、またはシステムマネージャの設定の再読込時に {{man|8|systemd-fstab-generator}} によって {{ic|/etc/fstab}} のエントリが systemd ユニットに変換されます。 |
||
− | # journalctl |
||
+ | [[fstab]] の通常機能だけでなく、{{ic|x-systemd.}} が前に付く特殊なマウントオプションを利用することが可能です。拡張機能を使用する具体的な例として [[Fstab#systemd による自動マウント]]には必要に応じて自動マウントする方法が書かれています。拡張機能のドキュメントは [https://www.freedesktop.org/software/systemd/man/systemd.mount.html#fstab] を参照してください。 |
||
− | デフォルトで ({{ic|/etc/systemd/journald.conf}} 内で {{ic|Storage=}} が {{ic|auto}} に設定されているとき)、journal は {{ic|/var/log/journal/}} へ書き込みを行います。Arch Linux では {{ic|/var/log/journal/}} ディレクトリは {{Pkg|systemd}} の一部であり、あなたや何らかのプログラムがディレクトリを削除した場合、systemd は自動で'''再作成しません'''が、systemd のアップデートがあるとディレクトリは作りなおされます。それまでログは代わりに {{ic|/run/systemd/journal}} に書き込まれます。ただし再起動時にこのログは消失してしまいます。 |
||
+ | == Journal == |
||
− | {{Tip|{{ic|/var/log/journal/}} が [[btrfs]] ファイルシステムに存在する場合、ディレクトリの Copy-on-Write を無効にするべきです。詳しくは [[Btrfs#コピーオンライト (CoW)]] を読んで下さい。}} |
||
+ | [[systemd/ジャーナル]]を見てください。 |
||
+ | == ヒントとテクニック == |
||
− | === フィルタリング === |
||
+ | === インストールされたユニットをデフォルトで有効にする === |
||
− | {{ic|journalctl}} を使って出力にフィルタをかけることができます。表示したりフィルタリングをするメッセージが大量にある場合、かなり時間がかかります。コマンドの出力は相当の時間がたってから表示されるかもしれません。 |
||
+ | Arch Linux の {{ic|/usr/lib/systemd/system-preset/99-default.preset}} には {{ic|disable *}} と記述されています。systemctl プリセットがデフォルトで全てのユニットを無効化するようになり、新しいパッケージがインストールされたときも、ユーザーが手動でユニットを有効化する必要があります。 |
||
− | {{Tip|journal はバイナリ形式で保存されますが、保存されるメッセージの中身に修正は加わりません。このため、''systemd'' をインストールしていない環境でリカバリなどをするために、''strings'' を使って回覧することが可能です。コマンドの例: {{ic|$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal <nowiki>| grep -i</nowiki> ''message''}}}} |
||
+ | 自動的に有効化させたい場合、{{ic|/etc/systemd/system-preset/99-default.preset}} から {{ic|/dev/null}} にシンボリックリンクを作成して設定ファイルを上書きしてください。systemctl プリセットの設定ディレクトリで指定しないかぎり、インストールされた全てのユニットが有効化されるようになります。詳しくは {{man|5|systemd.preset}} の man ページを参照。 |
||
− | 例: |
||
+ | {{Note|デフォルトで全てのユニットを有効化すると、パッケージに(互いに両立しない)複数のユニットが含まれている場合に問題が生じます。systemctl プリセットはディストリビューションやシステム管理者によって使われることを意図されて作られています。衝突するユニットが有効化されてしまう場合、{{ic|systemd.preset}} の man ページに書かれているように、プリセットの設定ファイルを使ってどちらか片方を明示的に無効化させる必要があります。}} |
||
− | * 起動時からの全てのメッセージを表示: {{bc|# journalctl -b}} 場合によっては最新のブートメッセージではなく、以前のブートのメッセージを読みたいことがあります (例えば復旧できないシステムクラッシュが起こった場合)。{{ic|-b}} フラグに任意のパラメータを付けることでメッセージをオフセットして読むことが可能です: {{ic|journalctl -b -0}} は最新のブートのメッセージを、{{ic|journalctl -b -1}} は一つ前のブートのメッセージを表示し {{ic|journalctl -b -2}} は二つ前、と続きます。詳しくは {{ic|man 1 journalctl}} を見て下さい、セマンティックスはより強力です。 |
||
− | * 特定の日付 (任意で時間も指定可能) からのメッセージを全て表示: {{bc|1=# journalctl --since="2012-10-30 18:17:16"}} |
||
− | * 20分前からのメッセージを全て表示: {{bc|1=# journalctl --since "20 min ago"}} |
||
− | * 新しいメッセージを表示: {{bc|# journalctl -f}} |
||
− | * 特定の実行ファイルによる全てのメッセージを表示: {{bc|# journalctl /usr/lib/systemd/systemd}} |
||
− | * 特定のプロセスによる全てのメッセージを表示: {{bc|1=# journalctl _PID=1}} |
||
− | * 特定のユニットによる全てのメッセージを表示: {{bc|# journalctl -u netcfg}} |
||
− | * カーネルのリングバッファを表示: {{bc|1=# journalctl -k}} |
||
− | * syslog の facility をフィルタリングすることで auth.log と同等の内容を表示: {{bc|1=# journalctl -f -l SYSLOG_FACILITY=10}} |
||
+ | === アプリケーション環境のサンドボックス化 === |
||
− | 詳しくは {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}} や Lennart の[http://0pointer.de/blog/projects/journalctl.html ブログ記事] を見て下さい。 |
||
+ | ユニットファイルをサンドボックスとして作成して堅牢な仮想環境にアプリケーションやプロセスを分離させることが可能です。systemd は[[wikipedia:Linux_namespaces|名前空間]]や[[ケイパビリティ]]のホワイトリスト・ブラックリスト、[[Cgroups]] を活用して [https://www.freedesktop.org/software/systemd/man/systemd.exec.html 実行環境を設定] しプロセスをコンテナ化します。 |
||
+ | 既存の systemd ユニットファイルを使ってアプリケーションをサンドボックス化するには {{Pkg|strace}}, [[wikipedia:ja:標準ストリーム#標準エラー出力 (stderr)|stderr]], [https://www.freedesktop.org/software/systemd/man/journalctl.html journalctl] などでエラーや出力を確認しながら試行錯誤が必要です。まずは上流のドキュメントを検索して先例がないか確認すると良いでしょう。 |
||
− | {{Tip|1= |
||
− | デフォルトで、''journalctl'' は画面からはみ出る行を切り詰めますが、場合によっては、折り返しが有効になっていたほうが読みやすいことがあります。{{ic|SYSTEMD_LESS}} [[環境変数]]によってこれを制御することができ、[[Core Utilities#less|less]] (デフォルトのページャ) に渡すオプションを指定します。デフォルトは {{ic|FRSXMK}} (詳しくは {{ic|man 1 less}} や {{ic|man 1 journalctl}} を参照) です。 |
||
+ | {{Ic|CapabilityBoundingSet}} では許可されるケイパビリティのホワイトリストを定義できますが、特定のケイパビリティをブラックリストに追加する用途で使うこともできます。例: {{ic|1=CapabilityBoundingSet=~ CAP_SYS_ADMIN}}。 |
||
− | {{ic|S}} オプションを省くことで、出力は折り返されるようになります。例えば、以下のように ''journalctl'' を起動してください: |
||
− | |||
− | $ SYSTEMD_LESS=FRXMK journalctl |
||
− | |||
− | この挙動をデフォルトに設定したいならば、{{ic|~/.bashrc}} や {{ic|~/.zshrc}} でこの変数を [[環境変数#ユーザーごと|export]] してください。 |
||
− | }} |
||
− | |||
− | === journal のサイズ制限 === |
||
− | |||
− | journal が永続的(不揮発性)の場合、デフォルトではファイルシステムの容量の 10% に制限されます。例えば、{{ic|/var/log/journal}} が 50GiB の root パーティションにのっている場合、5GiB がログデータの上限になります。{{ic|/etc/systemd/journald.conf}} の {{ic|SystemMaxUse}} を変更すれば、最大サイズを変更できます。例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します: |
||
− | |||
− | SystemMaxUse=50M |
||
− | |||
− | 詳細は {{ic|man journald.conf}} を参照してください。 |
||
− | |||
− | === journald と syslog の結合 === |
||
− | |||
− | 古典的な [[syslog-ng|syslog]] との互換性は、すべてのメッセージがソケット {{ic|/run/systemd/journal/syslog}} に転送されることで実現されます。syslog を使うには、{{ic|/dev/log/}} の代わりにこのソケットを指定します ([http://lwn.net/Articles/474968/ 公式アナウンス])。 |
||
− | |||
− | ''systemd'' 216 からオーバーヘッドを減らすために {{ic|journald.conf}} のソケットの転送はデフォルトで無効になっています ({{ic|1=ForwardToSyslog=no}})。[[rsyslog]] や [[syslog-ng]] (3.6 以降) は [http://lists.freedesktop.org/archives/systemd-devel/2014-August/022295.html#journald 自力で] journal からメッセージを取得するためです。 |
||
− | |||
− | 設定の詳細は [[Syslog-ng#概要]], [[Syslog-ng#syslog-ng と systemd journal]], [[rsyslog]] を見て下さい。 |
||
− | |||
− | === journald を /dev/tty12 に転送する === |
||
− | |||
− | [[#ユニットファイルの編集|ドロップインディレクトリ]] {{ic|/etc/systemd/journald.conf.d}} を作成して、ディレクトリの中に {{ic|fw-tty12.conf}} ファイルを作成してください: |
||
− | {{hc|1=/etc/systemd/journald.conf.d/fw-tty12.conf|2= |
||
− | [Journal] |
||
− | ForwardToConsole=yes |
||
− | TTYPath=/dev/tty12 |
||
− | MaxLevelConsole=info |
||
− | }} |
||
− | |||
− | 次を実行して journald を再起動してください: |
||
− | # systemctl restart systemd-journald |
||
− | |||
− | === 別のジャーナルを指定して表示 === |
||
− | ライブ環境から起動して本番環境を修復する場合など、トラブルが発生した他のシステムのログを確認する必要があるような場合、{{ic|/mnt}} などにディスクをマウントしてから、ジャーナルのパスを {{ic|-D}}/{{ic|--directory}} で指定することができます: |
||
− | |||
− | $ journalctl -D ''/mnt''/var/log/journal -xe |
||
− | |||
− | == SysVinit/initscripts からの移行 == |
||
− | |||
− | {{Note| |
||
− | * {{Pkg|systemd}} と {{Pkg|systemd-sysvcompat}} は [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 2012-10-13] 以降のインストールメディアではデフォルトでインストールされます。このセクションは未だに ''sysvinit'' や ''initscripts'' を使っている Arch Linux システムに向けて書かれています。 |
||
− | * Arch Linux を VPS で動かしている場合、[[Virtual Private Server]] を参照してください。 |
||
− | }} |
||
− | |||
− | === 移行前に考慮すべきこと === |
||
− | |||
− | * [http://freedesktop.org/wiki/Software/systemd/ 本家のホームページ] で、systemd についてざっと読んでください。 |
||
− | * systemd の ''journal'' システムは、''syslog'' を置き換えることができますが、この2つは共存できます。[[#Journal]] を見て下さい。 |
||
− | * systemd は ''cron''、''acpid''、''xinetd'' の機能の一部を代替できますが、あなたが望まない限り伝統的なデーモンを使うのを止める必要はありません。 |
||
− | * インタラクティブな initscript は sytemd では動きません。特に、起動時に ''netcfg-menu'' を使うことはできません ({{Bug|31377}})。 |
||
− | |||
− | === インストール === |
||
− | |||
− | # [[公式リポジトリ]]から {{pkg|systemd}} を[[pacman|インストール]]してください。 |
||
− | # [[カーネルパラメータ]]に次を加えます: {{ic|1=init=/usr/lib/systemd/systemd}} |
||
− | # 完了したら、必要なサービスを {{ic|systemctl enable <service_name>.service}} を使って有効にできます (大雑把に言うと {{ic|DAEMONS}} 行に[[デーモン一覧|サービス]]を追加するのと同じです)。 |
||
− | # システムを再起動し、{{ic|systemd}} がアクティブになっていることを次のコマンドで確認します: {{ic|cat /proc/1/comm}}。{{ic|systemd}} の文字が返ってくるはずです。 |
||
− | # systemd であなたのホストネームを設定します: {{ic|hostnamectl set-hostname myhostname}} または {{ic|/etc/hostname}}。 |
||
− | # ''initscripts'' と ''sysvinit'' をシステムから削除し {{pkg|systemd-sysvcompat}} をインストールしてください。 |
||
− | # もう必要なくなった {{ic|1=init=/usr/lib/systemd/systemd}} パラメータを削除してください。{{pkg|systemd-sysvcompat}} がデフォルトの init になります。 |
||
− | |||
− | === initscripts のエミュレーション === |
||
− | |||
− | 伝統的な Arch の設定ファイルは {{Pkg|initscripts}} パッケージによって使われています。systemd と {{Pkg|initscripts}} がインストールされていて、systemd によってシステムが動いている時、systemd は以下のことを行います: |
||
− | |||
− | # {{ic|/etc/rc.conf}} の {{ic|DAEMONS}} 行をパースし、ブート時にデーモンを起動します |
||
− | # ブート中に {{ic|/etc/rc.local}} を実行します |
||
− | # シャットダウン中に {{ic|/etc/rc.local.shutdown}} を実行します |
||
− | |||
− | Initscripts のエミュレーションはユーザーが systemd に移行するのを手助けする過渡期の手段として存在しています、そして'''最終的には取り除かれる予定です'''。ネイティブな systemd は設定の中心として {{ic|rc.conf}} を使いません、{{ic|/etc/rc.conf}} が使えなくなる前に[[#ネイティブの設定|ネイティブの systemd 設定ファイル]]を使うことを推奨します。 |
||
− | |||
− | {{Note|{{ic|/etc/rc.local}} を置換するには、起動時に実行したいもののカスタムサービスファイルを書くことを推奨します。[[#カスタム .service ファイルを書く|このセクション]]に方法を記述しています。}} |
||
− | |||
− | {{Note|{{ic|Ctrl+Alt+Del}} で再起動しないように {{ic|/etc/inittab}} で設定していた場合、root で {{ic|systemctl mask ctrl-alt-del.target}} を実行して systemd でも再設定する必要があります。}} |
||
− | |||
− | {{Warning|systemd (197-4 以降) と initscripts 両方をインストールしていて、{{ic|/etc/rc.local}} が存在する場合、(systemd 197-4 から getty@tty1.service が rc-local.service を待たなくなり、getty が起動できなくなるために) ブートプロセスが終了しません。{{ic|/etc/rc.local}} を削除するか名前を変えて下さい。}} |
||
− | |||
− | === DAEMONS 行からの移行 === |
||
− | |||
− | 純粋な systemd セットアップのためには、完全に {{ic|/etc/rc.conf}} ファイルを削除して {{ic|systemctl}} だけを使ってサービスを有効にしなくてはなりません。{{ic|/etc/rc.conf}} の {{ic|DAEMONS}} 行のそれぞれの {{ic|<service_name>}} に対して次を実行します: |
||
− | |||
− | # systemctl enable <service_name>.service |
||
− | |||
− | {{Tip|一般的に使われるデーモンの initscripts と systemd の比較表が[[デーモン一覧|ここ]]にあります。}} |
||
− | |||
− | {{ic|<service_name>.service}} が存在しない場合: |
||
− | |||
− | * ほとんどの場合、systemd は違う名前を使っています。例えば、{{ic|crond}} init デーモンは {{ic|cronie.service}} に、{{ic|alsa}} init デーモンは {{ic|alsa-store.service}} と {{ic|alsa-restore.service}} になっています。他にも {{ic|network}} デーモンは、他のサービスファイルに置き換わっています (詳しくは[[ネットワーク設定]]を見て下さい)。 |
||
− | * サービスファイルが systemd にない場合。その場合、起動中にサービスを作動させるのに {{ic|rc.conf}} を使いつづける必要があります。 |
||
− | |||
− | {{Tip|パッケージの中身を見て、どのサービス名でデーモン起動スクリプトが含まれているのか見ることができます。例: |
||
− | $ pacman -Ql cronie |
||
− | [...] |
||
− | cronie /etc/rc.d/crond #DAEMONS 行で使われるデーモン initscript ("純粋な" systemd では使われません) |
||
− | [...] |
||
− | cronie /usr/lib/systemd/system/cronie.service #対応する systemd のデーモンサービス |
||
− | [...] |
||
− | }} |
||
− | |||
− | * 最後に、サービスによっては、ユーザーの操作で有効にする必要がないものがあります。例えば、{{ic|dbus.service}} は {{ic|dbus-core}} がインストールされると自動で有効にされます。{{ic|alsa-store.service}} と {{ic|alsa-restore.service}} も systemd によって自動で有効にされます。利用できるサービスと状態をチェックするには {{ic|systemctl}} コマンドを使います: {{ic|systemctl status <service_name>}}。 |
||
− | |||
− | === 追加情報 === |
||
− | |||
− | * カーネルパラメータに {{ic|quiet}} を設定している場合、それを削除することで、起動中に何が起こっているかわかりやすくなります。 |
||
− | |||
− | * systemd を使っていてユーザーに[[ユーザーとグループ|グループ]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) を設定する必要はほとんどありません。グループは機能を破壊することさえあります。例えば、{{ic|audio}} グループは高速なユーザー切り替えやアプリケーションのソフトウェアミキシングを無効にします。全ての PAM ログインは logind セッションを提供します。オーディオ/ビデオデバイスに [[アクセス制御リスト|POSIX ACL]] を通して権限を与えたり、[[udev#Udisks|udisks]] を使ってリムーバルディスクのマウントなどの操作を行います。 |
||
− | |||
− | * ネットワークの設定方法は[[ネットワーク設定]]を見て下さい。 |
||
== トラブルシューティング == |
== トラブルシューティング == |
||
572行目: | 374行目: | ||
1. 起動に失敗している systemd サービスを探しましょう: |
1. 起動に失敗している systemd サービスを探しましょう: |
||
− | {{hc|1=$ systemctl --failed|2= |
+ | {{hc|1=$ systemctl --state=failed|2= |
− | systemd-modules-load.service |
+ | systemd-modules-load.service loaded '''failed failed''' Load Kernel Modules}} |
+ | |||
− | }} |
||
+ | もしくは ''systemd'' のライブログメッセージを確認します: |
||
+ | $ journalctl -fp err |
||
2. Ok, {{ic|systemd-modules-load}} サービスに問題が発生していることがわかりました。詳しく見てみましょう: |
2. Ok, {{ic|systemd-modules-load}} サービスに問題が発生していることがわかりました。詳しく見てみましょう: |
||
630行目: | 434行目: | ||
=== ブート問題の診断 === |
=== ブート問題の診断 === |
||
− | カーネルコマンドラインに次のパラメータをつけて起動してください: |
+ | カーネルコマンドラインに次のパラメータをつけて起動してください: {{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}。 |
− | {{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}} |
||
− | [ |
+ | 詳しくは[[ブートデバッグ]]や [https://freedesktop.org/wiki/Software/systemd/Debugging] を見て下さい。 |
=== 特定のサービスの問題を診断 === |
=== 特定のサービスの問題を診断 === |
||
652行目: | 455行目: | ||
=== シャットダウン/再起動にものすごく時間がかかる === |
=== シャットダウン/再起動にものすごく時間がかかる === |
||
− | シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。Systemd はサービスを kill する前に終了するのを待ちます。なにが原因か知るには [ |
+ | シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。Systemd はサービスを kill する前に終了するのを待ちます。なにが原因か知るには [https://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually この記事] を見て下さい。 |
=== 短いプロセスがログを出力しない === |
=== 短いプロセスがログを出力しない === |
||
691行目: | 494行目: | ||
{{ic|systemd-analyze}} を使用して、以前と比べて起動時間が明らかに伸びていると複数のユーザーが報告しています。{{ic|systemd-analyze blame}} を使って [[NetworkManager]] が起動するのに異常に長い時間かかるようになったという報告もあります。 |
{{ic|systemd-analyze}} を使用して、以前と比べて起動時間が明らかに伸びていると複数のユーザーが報告しています。{{ic|systemd-analyze blame}} を使って [[NetworkManager]] が起動するのに異常に長い時間かかるようになったという報告もあります。 |
||
− | 問題の原因として {{ic|/var/log/journal}} が巨大になりすぎている可能性があります。そのような場合、フォルダ内のファイルを全て削除して journal のファイルサイズを[[#journal のサイズ制限|ここ]]に書かれているように制限するよう設定すれば解決します(できればファイルを削除する前に、どこかに一時的にバックアップしてください)。 |
+ | 問題の原因として {{ic|/var/log/journal}} が巨大になりすぎている可能性があります。そのような場合、フォルダ内のファイルを全て削除して journal のファイルサイズを[[systemd/ジャーナル#journal のサイズ制限|ここ]]に書かれているように制限するよう設定すれば解決します(できればファイルを削除する前に、どこかに一時的にバックアップしてください)。 |
− | === systemd-tmpfiles-setup.service の |
+ | === 起動時に systemd-tmpfiles-setup.service の実行に失敗する === |
systemd 219 から、{{ic|/usr/lib/tmpfiles.d/systemd.conf}} は {{ic|/var/log/journal}} 下のディレクトリに対して ACL 属性を指定しており、それによって、ジャーナルが存在するファイルシステムで ACL のサポートを有効にしなくてはならなくなっています。 |
systemd 219 から、{{ic|/usr/lib/tmpfiles.d/systemd.conf}} は {{ic|/var/log/journal}} 下のディレクトリに対して ACL 属性を指定しており、それによって、ジャーナルが存在するファイルシステムで ACL のサポートを有効にしなくてはならなくなっています。 |
||
{{ic|/var/log/journal}} が存在するファイルシステムで ACL を有効化する方法は[[アクセス制御リスト#ACL の有効化]]を見て下さい。 |
{{ic|/var/log/journal}} が存在するファイルシステムで ACL を有効化する方法は[[アクセス制御リスト#ACL の有効化]]を見て下さい。 |
||
+ | |||
+ | === systemctl enable で /etc/systemd/system にシンボリックリンクが作成されない === |
||
+ | |||
+ | {{ic|/etc/systemd/system/''foo''.service}} がシンボリックリンクの場合、{{ic|systemctl enable ''foo''.service}} を実行しても以下のエラーで失敗します: |
||
+ | |||
+ | Failed to issue method call: No such file or directory |
||
+ | |||
+ | これは systemd の [https://bugzilla.redhat.com/show_bug.cgi?id=955379#c14 仕様] です。絶対パスで有効にすることで回避できます: |
||
+ | |||
+ | # systemctl enable ''/absolute/path/foo''.service |
||
+ | |||
+ | === 起動時に表示される systemd のバージョンがインストールしているパッケージのバージョンと違う === |
||
+ | |||
+ | [[Mkinitcpio#イメージ作成とアクティベーション|initramfs を再生成]]することでバージョンが一致するようになるはずです。 |
||
+ | |||
+ | {{Tip|1={{pkg|systemd}} がアップグレードされると自動的に initramfs が生成されるように pacman フックを設定することができます。[https://bbs.archlinux.org/viewtopic.php?id=215411 フォーラムスレッド] や [[Pacman#フック]]を見てください。}} |
||
+ | |||
+ | === リモートマシンで緊急モードを無効化 === |
||
+ | |||
+ | リモートマシン (例えば Azure や Google Cloud でホストしている仮想マシン) の緊急モードは無効化すると良いでしょう。緊急モードが起動すると、ネットワークからマシンに接続できなくなってしまうからです。無効化するには以下のコマンドを実行: |
||
+ | |||
+ | # systemctl mask emergency.service |
||
+ | # systemctl mask emergency.target |
||
== 参照 == |
== 参照 == |
||
− | *[ |
+ | *[https://www.freedesktop.org/wiki/Software/systemd 公式ウェブサイト] |
*[[Wikipedia:ja:systemd|Wikipedia の記事]] |
*[[Wikipedia:ja:systemd|Wikipedia の記事]] |
||
*[http://0pointer.de/public/systemd-man/ Manual Pages] |
*[http://0pointer.de/public/systemd-man/ Manual Pages] |
||
− | *[ |
+ | *[https://freedesktop.org/wiki/Software/systemd/Optimizations systemd Optimizations] |
− | *[ |
+ | *[https://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ] |
− | *[ |
+ | *[https://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips And Tricks] |
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)] |
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)] |
||
− | *[ |
+ | *[https://fedoraproject.org/wiki/Systemd Fedora プロジェクトによる systemd の説明] |
− | *[ |
+ | *[https://fedoraproject.org/wiki/How_to_debug_Systemd_problems systemd の問題をデバッグする方法] |
− | *[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html |
+ | *[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html] ''The H Open'' マガジンに記載された二部からなる紹介記事 |
− | *[http://0pointer.de/blog/projects/systemd.html Lennart |
+ | *[http://0pointer.de/blog/projects/systemd.html Lennart のブログ記事] |
− | *[http://0pointer.de/blog/projects/systemd-update.html |
+ | *[http://0pointer.de/blog/projects/systemd-update.html ステータスアップデート] |
− | *[http://0pointer.de/blog/projects/systemd-update-2.html |
+ | *[http://0pointer.de/blog/projects/systemd-update-2.html ステータスアップデート 2] |
− | *[http://0pointer.de/blog/projects/systemd-update-3.html |
+ | *[http://0pointer.de/blog/projects/systemd-update-3.html ステータスアップデート 3] |
− | *[http://0pointer.de/blog/projects/why.html |
+ | *[http://0pointer.de/blog/projects/why.html 近況] |
− | *[ |
+ | *[https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora の SysVinit と systemd のチートシート] |
*[[Emacs#Systemd ファイルのシンタックスハイライト|Emacs の Systemd ファイルのシンタックスハイライト]] |
*[[Emacs#Systemd ファイルのシンタックスハイライト|Emacs の Systemd ファイルのシンタックスハイライト]] |
||
+ | *[https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units digital ocean のチュートリアル] |
2019年2月22日 (金) 00:42時点における版
関連記事
プロジェクトウェブページ より:
- systemd は Linux 環境の基本構成スイートであり、SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、ソケットや D-Bus のアクティベーションを使用してサービスを起動し、必要なデーモンの開始を行うことができ、Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動) マウントポイントの管理、煩雑な依存関係に基づいたサービスのコントロールを処理します。systemd は sysvinit の代替として SysV や LSB init スクリプトをサポートしています。init としての機能以外にも、ログデーモンやホストネーム・時刻・ロケールなどシステムの基本設定を制御するユーティリティ、ログイン中のユーザーから実行中のコンテナや仮想マシン、システムアカウントまで管理する機能、ネットワーク設定や時刻同期あるいは名前解決などを管理するシンプルなデーモンも含まれています。
目次
- 1 systemctl の基本的な使い方
- 2 ユニットファイル
- 3 ターゲット
- 4 一時ファイル
- 5 タイマー
- 6 マウント
- 7 Journal
- 8 ヒントとテクニック
- 9 トラブルシューティング
- 9.1 systemd のエラーを調査する
- 9.2 ブート問題の診断
- 9.3 特定のサービスの問題を診断
- 9.4 シャットダウン/再起動にものすごく時間がかかる
- 9.5 短いプロセスがログを出力しない
- 9.6 クラッシュしたアプリケーションのダンプのジャーナルを無効にする
- 9.7 再起動やシャットダウン時のエラーメッセージ
- 9.8 少しづつ起動時間が長くなっている
- 9.9 起動時に systemd-tmpfiles-setup.service の実行に失敗する
- 9.10 systemctl enable で /etc/systemd/system にシンボリックリンクが作成されない
- 9.11 起動時に表示される systemd のバージョンがインストールしているパッケージのバージョンと違う
- 9.12 リモートマシンで緊急モードを無効化
- 10 参照
systemctl の基本的な使い方
systemd を管理したり内部情報を見るために使うメインのコマンドが systemctl
です。システムの状態を確かめたりシステムやサービスを管理するために使うのは使い方の一部です。詳しくは systemctl(1) を見て下さい。
システムの状態を分析する
システムの状態を表示:
$ systemctl status
実行中のユニットを一覧する:
$ systemctl
または:
$ systemctl list-units
失敗したユニットを一覧する:
$ systemctl --failed
実行可能なユニットファイルは /usr/lib/systemd/system/
や /etc/systemd/system/
にあります (後者が優先的に使われます)。インストールされたユニットを一覧するには:
$ systemctl list-unit-files
ユニットを使う
ユニットには、例えば、サービス (.service
) やマウントポイント (.mount
)、デバイス (.device
)、ソケット (.socket
) などがあります。
systemctl
を使うとき、一般的には拡張子 (suffix) を含むユニットファイルの完全な名前を指定する必要があります。例えば、sshd.socket
のように。しかし、以下のような場合には省略形が存在します:
- 拡張子が指定されない場合、systemctl は
.service
とみなします。例えばnetctl
とnetctl.service
は同じように扱われます。 - マウントポイントは自動的に対応する
.mount
ユニットとして扱われます。例えば、/home
を指定することはhome.mount
の指定と同じです。 - マウントポイントと同じく、デバイスも自動的に対応する
.device
ユニットとして扱われます。従って、/dev/sda2
の指定はdev-sda2.device
と同じです。
詳細は systemd.unit(5) を見てください。
いますぐユニットを実行:
# systemctl start unit
いますぐユニットを停止:
# systemctl stop unit
ユニットを再始動:
# systemctl restart unit
ユニットに設定を再読み込みするように通知:
# systemctl reload unit
ユニットの状態を表示(動いているかどうかなど):
$ systemctl status unit
有効化(起動時に自動で実行するよう設定)されているかどうか表示:
$ systemctl is-enabled unit
起動時に実行されるように有効化する:
# systemctl enable unit
ユニットを有効化して今すぐ起動する:
# systemctl enable --now unit
システム起動時に実行されないように無効化する:
# systemctl disable unit
ユニットをマスクすることで起動しないようにできます:
# systemctl mask unit
ユニットのマスクを解除:
# systemctl unmask unit
ユニットに関連する(ユニットファイルによってサポートされている)マニュアルページを参照する:
$ systemctl help unit
systemd をリロードし、新しい、もしくは変化のあったユニットをスキャンする:
# systemctl daemon-reload
電源管理
電源管理には polkit
が必要です。
ローカルの systemd-logind
のユーザーセッション中で、他のセッションがアクティブでなければ、ルート権限なしで以下のコマンドが使えます。そうでなければ (他のユーザが tty でログインしている場合など)、systemd は自動的に root のパスワードを要求するでしょう。
再起動:
$ systemctl reboot
シャットダウンしてパワーオフ:
$ systemctl poweroff
サスペンド(待機):
$ systemctl suspend
ハイバネート(休止):
$ systemctl hibernate
ハイブリッドスリープ (もしくは suspend-to-both):
$ systemctl hybrid-sleep
ユニットファイル
systemd の ユニットファイル の構文は XDG の Desktop Entry Specification である .desktop から影響を受けています。そして .desktop は Microsoft Windows の .ini ファイルからインスパイアされています。ユニットファイルは複数の場所に配置されます (配置場所のリストを確認するには systemctl show --property=UnitPath
を実行してください)。優先度が低い方から説明すると:
/usr/lib/systemd/system/
: インストールしたパッケージに含まれているユニット/etc/systemd/system/
: システムの管理者がインストールしたユニット
依存関係を解決する
systemd ではユニットファイルを適切に書くことで依存関係を解決します。一番典型的なケースは、ユニット A
が走る前に、ユニット A
がユニット B
を必要としている場合です。この場合、A
の [Unit]
セクションに Requires=B
と After=B
を加えます。依存が必然ではない場合、代わりに Wants=B
と After=B
を加えます。Wants=
と Requires=
は After=
を含まないことに注意してください、もし After=
を明記しなかったときは、2つのユニットは並行して実行されます。
基本的に、依存関係はターゲットではなくサービスに記述します。例えば、network.target
はネットワークインターフェースを設定する全てのサービスによって使われるので、カスタムユニットを起動させる順番は network.target
が起動し終わってからにする必要があります。
タイプ
カスタムサービスファイルを書くときにどのスタートアップタイプを使うべきか考える必要があります。タイプは [Service]
セクションの Type=
パラメータで設定します。より詳しい説明は systemd.service(5) を見て下さい。
Type=simple
(デフォルト): systemd はプロセスを起動した時点でサービスが立ち上がったとみなします。プロセスをフォークすることはできません。ソケットアクティベーション以外で他のサービスが必要な場合に、このタイプを使ってはいけません。Type=forking
: 起動したプロセスが一旦フォークし、親プロセス側が終了したときに、 systemd はサービスが立ち上がったとみなします。このタイプでなくてもかまわないとき以外は、古典的なデーモンにはこのタイプを使って下さい。またPIDFile=
を指定することで systemd はメインプロセスの情報を追い続けます。Type=oneshot
: シングルジョブを行い終了するスクリプト用のタイプです。またRemainAfterExit=yes
を設定することで systemd はプロセスが終了した後もサービスがアクティブだとみなします。Type=notify
:Type=simple
と同じですが、利用可能になったときにデーモンが systemd に信号を送るように条件がつけられます。この通知のリファレンス実装はlibsystemd-daemon.so
によって提供されています。Type=dbus
: 指定のBusName
が DBus のシステムバスに乗ったときに使うことができるサービス。Type=idle
: idle の挙動はType=simple
と非常に似ています。ただし、サービスバイナリの実行は全てのジョブが処理されるまで待たされます。これを使えば、コンソールに状態を出力するシェルサービスで、出力が混じってしまうのを避けることができます。
ユニットファイルの編集
パッケージに入っているユニットファイルを編集する方法は2つあります: 新しいユニットファイルで完全に置き換えるか、ドロップインファイルを作成して既存のユニットファイルに上書きして適用させるかです。どちらの方法でも、変更を加えた後はユニットをリロードする必要があります。systemctl edit
でユニットを編集するか (自動でユニットがリロードされます) または次のコマンドで全てのユニットをリロードしてください:
# systemctl daemon-reload
ユニットファイルを置換する
ユニットファイル /usr/lib/systemd/system/unit
を置き換えたいときは、/etc/systemd/system/unit
ファイルを作成してユニットを再有効することでシンボリックリンクをアップデートします:
# systemctl reenable unit
もしくは、次を実行:
# systemctl edit --full unit
このコマンドはテキストエディタで /etc/systemd/system/unit
を開いて (ファイルが存在しない場合はインストールされているユニットがコピーされます)、編集を終えた時に自動的にユニットをリロードします。
ドロップインファイル
ユニットファイル /usr/lib/systemd/system/unit
のドロップインファイルを作成するには、/etc/systemd/system/unit.d/
という名のディレクトリ (例: /etc/systemd/system/httpd.service.d/
) を作成してその中に *.conf
を配置します。このファイルを使ってオプションを上書きしたり追加してください。systemd が *.conf
ファイルをパースして元のユニットファイルの一番上に設定を適用します。
ドロップインファイルを作成する一番簡単な方法は次のコマンドを実行することです:
# systemctl edit unit
テキストエディタで /etc/systemd/system/unit.d/override.conf
ファイルが開かれ (必要であればファイルが作成されます)、編集を終えた時に自動でユニットがリロードされます。
初期状態にリバート
systemctl edit
を使って変更したユニットを元に戻したい場合、以下のコマンドを実行:
# systemctl revert unit
サンプル
例えば、ユニットに依存するデーモンを追加したい場合、以下のファイルを作成することができます:
/etc/systemd/system/<unit>.d/customdependency.conf
[Unit] Requires=<new dependency> After=<new dependency>
oneshot
タイプでないユニットの ExecStart
ディレクティブを置き換えるには、以下のファイルを作成します:
/etc/systemd/system/unit.d/customexec.conf
[Service] ExecStart= ExecStart=new command
サービスが自動的に再起動されるようにするには:
/etc/systemd/system/unit.d/restart.conf
[Service] Restart=always RestartSec=30
ターゲット
Systemd ではランレベルに似たものとしてターゲットを使っています。ただしその挙動には少し違いがあります。それぞれのターゲットはナンバリングされる代わりに名前がつけられ、ある特定の目的のために作られ、複数のターゲットを同時に有効にできるようになっています。ターゲットによっては、他のターゲットのサービスを全て引継ぎ、そこにサービスを追加するよう実装されています。一般的な SystemVinit ランレベルに擬態する systemd ターゲットもあり、親しみのある telinit RUNLEVEL
コマンドを使って使用するターゲットを切り替えることが可能です。
現在のターゲットを獲得
systemd では runlevel
の代わりに次のコマンドが使われます:
$ systemctl list-units --type=target
カスタムターゲットを作る
標準の Fedora インストールではランレベルごとに特定の目的が設定されています; 0, 1, 3, 5, 6 のランレベルには特定の sytemd ターゲットと一対一の対応関係が存在します。残念ながら、ユーザー定義のランレベル (2 や 4 など) で同じことをする良い方法はありません。もしあなたがそうしたいならば、既に存在しているランレベルをベースに新しい systemd ターゲットを /etc/systemd/system/<your target>
として作り (/usr/lib/systemd/system/graphical.target
がサンプルになるかもしれません)、/etc/systemd/system/<your target>.wants
ディレクトリを作って、有効にしたいサービスに /usr/lib/systemd/system/
からシンボリックリンクを貼ることが示唆されています。
SysV ランレベルと systemd ターゲットの対応表
SysV ランレベル | systemd ターゲット | 説明 |
---|---|---|
0 | runlevel0.target, poweroff.target | システムを停止。 |
1, s, single | runlevel1.target, rescue.target | シングルユーザーモード。 |
2, 4 | runlevel2.target, runlevel4.target, multi-user.target | ユーザー定義・サイト指定ランレベル。デフォルトでは、3 と同一。 |
3 | runlevel3.target, multi-user.target | マルチユーザー、非グラフィカル。一般的にマルチコンソールやネットワークを介してログインするのに使われます。 |
5 | runlevel5.target, graphical.target | マルチユーザー、グラフィカル。通常、ランレベル 3 の全てのサービスにグラフィカルログインを付加。 |
6 | runlevel6.target, reboot.target | 再起動 |
emergency | emergency.target | 緊急シェル |
現在のターゲットを変更する
systemd ではターゲットは"ターゲットユニット"を通して扱うことができます。ターゲットを変えるには次のようにします:
# systemctl isolate graphical.target
これは現在のターゲットを変えるだけで、次の起動時には影響がありません。SysVinit での、telinit 3
や telinit 5
のようなコマンドと同じです。
起動時のデフォルトターゲットを変更する
標準のターゲットは default.target
で、デフォルトで (昔のランレベル 5 に大体対応している) graphical.target
にエイリアスされています。起動時のデフォルトターゲットを変更するには、以下のカーネルパラメータのどれかをブートローダに加えてください:
systemd.unit=multi-user.target
(昔のランレベル 3 とほぼ同じ)。systemd.unit=rescue.target
(昔のランレベル 1 とほぼ同じ)。
また、ブートローダには修正を加えずに default.target
を変えることもできます。systemctl
を使います:
# systemctl set-default multi-user.target
一時ファイル
Systemd-tmpfiles は /usr/lib/tmpfiles.d/
と /etc/tmpfiles.d/
下にある設定ファイルを読み、通常 /run
や /tmp
などのディレクトリに存在している一時ファイル・ディレクトリの作成、内容の消去、削除などを行います。それぞれの設定ファイル名は /etc/tmpfiles.d/<program>.conf
です。/usr/lib/tmpfiles.d/
に同名の設定ファイルがある場合上書きされます。
tmpfiles は一時ファイルを必要とするデーモンのサービスファイルに同梱されます。例えば Samba デーモンは /run/samba
を一時ディレクトリとして使用するため、正しいパーミッションに設定されていることを期待します。これを表す tmpfile は以下のようになります:
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
tmpfiles は起動時にファイルに値を書き込むのにも使われることがあります。例えば、/etc/rc.local
を使って USB デバイスからの wakeup を無効化する echo USBE > /proc/acpi/wakeup
は、tmpfile では以下のように書けます:
/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE
詳細は systemd-tmpfiles(8) や tmpfiles.d(5) の man ページを参照してください。
タイマー
タイマーは ".timer" で終わる名前を持つユニット設定ファイルで、時間に基づく実行を行うために、systemd で制御・管理するタイマーの情報をエンコードしています。systemd/タイマー を参照してください。
マウント
systemd は System V init を置き換えるため、/etc/fstab
に指定されたマウントも処理します。起動時、またはシステムマネージャの設定の再読込時に systemd-fstab-generator(8) によって /etc/fstab
のエントリが systemd ユニットに変換されます。
fstab の通常機能だけでなく、x-systemd.
が前に付く特殊なマウントオプションを利用することが可能です。拡張機能を使用する具体的な例として Fstab#systemd による自動マウントには必要に応じて自動マウントする方法が書かれています。拡張機能のドキュメントは [2] を参照してください。
Journal
systemd/ジャーナルを見てください。
ヒントとテクニック
インストールされたユニットをデフォルトで有効にする
Arch Linux の /usr/lib/systemd/system-preset/99-default.preset
には disable *
と記述されています。systemctl プリセットがデフォルトで全てのユニットを無効化するようになり、新しいパッケージがインストールされたときも、ユーザーが手動でユニットを有効化する必要があります。
自動的に有効化させたい場合、/etc/systemd/system-preset/99-default.preset
から /dev/null
にシンボリックリンクを作成して設定ファイルを上書きしてください。systemctl プリセットの設定ディレクトリで指定しないかぎり、インストールされた全てのユニットが有効化されるようになります。詳しくは systemd.preset(5) の man ページを参照。
アプリケーション環境のサンドボックス化
ユニットファイルをサンドボックスとして作成して堅牢な仮想環境にアプリケーションやプロセスを分離させることが可能です。systemd は名前空間やケイパビリティのホワイトリスト・ブラックリスト、Cgroups を活用して 実行環境を設定 しプロセスをコンテナ化します。
既存の systemd ユニットファイルを使ってアプリケーションをサンドボックス化するには strace, stderr, journalctl などでエラーや出力を確認しながら試行錯誤が必要です。まずは上流のドキュメントを検索して先例がないか確認すると良いでしょう。
CapabilityBoundingSet
では許可されるケイパビリティのホワイトリストを定義できますが、特定のケイパビリティをブラックリストに追加する用途で使うこともできます。例: CapabilityBoundingSet=~ CAP_SYS_ADMIN
。
トラブルシューティング
systemd のエラーを調査する
例えば、systemd-modules-load
サービスのエラーを調べるとします:
1. 起動に失敗している systemd サービスを探しましょう:
$ systemctl --state=failed
systemd-modules-load.service loaded failed failed Load Kernel Modules
もしくは systemd のライブログメッセージを確認します:
$ journalctl -fp err
2. Ok, systemd-modules-load
サービスに問題が発生していることがわかりました。詳しく見てみましょう:
$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago Docs: man:systemd-modules-load.service(8). man:modules-load.d(5) Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
Process ID
が載っていない場合は、systemctl restart systemd-modules-load
で失敗したサービスを再実行してください。
3. エラーを細かく調べるためのプロセス ID (PID) を入手しました。Process ID
を使って (ここでは: 15630) 以下のコマンドを実行してください:
$ journalctl _PID=15630
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. -- Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp' Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'
4. カーネルモジュールに間違った設定がなされているようです。よって /etc/modules-load.d/
下の設定を見てみましょう:
$ ls -Al /etc/modules-load.d/
... -rw-r--r-- 1 root root 79 1. Dez 2012 blacklist.conf -rw-r--r-- 1 root root 1 2. Mär 14:30 encrypt.conf -rw-r--r-- 1 root root 3 5. Dez 2012 printing.conf -rw-r--r-- 1 root root 6 14. Jul 11:01 realtek.conf -rw-r--r-- 1 root root 65 2. Jun 23:01 virtualbox.conf ...
5. エラーメッセージ Failed to find module 'blacklist usblp'
はおそらく blacklist.conf
内に間違った設定があることを示しています。手順 3 で見つけたオプションの前に # を挿入して無効化してみましょう:
/etc/modules-load.d/blacklist.conf
# blacklist usblp # install usblp /bin/false
6. では、systemd-modules-load
を起動してみることにします:
$ systemctl start systemd-modules-load
成功した場合、何も表示されないはずです。何かエラーが表示される場合は、手順 3 に戻って下さい。そして新しい PID を使って残った問題を解決してください。
全て問題ないならば、サービスが正しく起動したか次のコマンドで確認することができます:
$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.
この種の問題は上のように解決できます。より詳しい調査をする場合は次のブート問題の診断を見て下さい。
ブート問題の診断
カーネルコマンドラインに次のパラメータをつけて起動してください: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
。
特定のサービスの問題を診断
ある systemd サービスが上手く動作せず、どうなっているのか詳しい情報が欲しい場合、環境変数 SYSTEMD_LOG_LEVEL
を debug
に設定してください。以下は systemd-networkd デーモンをデバッグモードで動かす例です:
# systemctl stop systemd-networkd # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
もしくは同じようにサービスファイルを修正してください:
/lib/systemd/system/systemd-networkd.service
[Service] ... Environment=SYSTEMD_LOG_LEVEL=debug ....
シャットダウン/再起動にものすごく時間がかかる
シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。Systemd はサービスを kill する前に終了するのを待ちます。なにが原因か知るには この記事 を見て下さい。
短いプロセスがログを出力しない
journalctl -u foounit.service
が短いプロセスについてなにも表示しない場合、かわりに PID を見て下さい。例えば、systemd-modules-load.service
が失敗したとき、systemctl status systemd-modules-load
によってそれが PID 123 として動いているとわかったら、その PID の journal の出力を見ることができます、journalctl -b _PID=123
。journal の _SYSTEMD_UNIT
や _COMM
などのメタデータは非同期に収集され /proc
ディレクトリにプロセスが存在している時だけ表示されます。これを修正するには、SCM_CREDENTIALS
のように、ソケット接続を使ってデータを流すようカーネルを変更する必要があります。
クラッシュしたアプリケーションのダンプのジャーナルを無効にする
/etc/systemd/coredump.conf
ファイルを編集して次の行を追加してください:
Storage=none
そして設定をリロードしてください:
# systemctl daemon-reload
再起動やシャットダウン時のエラーメッセージ
cgroup : option or name mismatch, new: 0x0 "", old: 0x4 "systemd"
この警告は kernel/cgroup.c
のカーネルコードから来ています:
/* Don't allow flags or name to change at remount */ if (((opts.flags ^ root->flags) & CGRP_ROOT_OPTION_MASK) || (opts.name && strcmp(opts.name, root->name))) { pr_err("option or name mismatch, new: 0x%x \"%s\", old: 0x%x \"%s\"\n", opts.flags & CGRP_ROOT_OPTION_MASK, opts.name ?: "", root->flags & CGRP_ROOT_OPTION_MASK, root->name); ret = -EINVAL; goto out_unlock; }
つまり、何かが cgroups を別の名前で再マウントしようとしてカーネルがそれに抵抗しているというわけです。ローカルの設定ファイルのエラーではなく、エラーメッセージ以外には何も症状が現れません。これが systemd のバグなのか、Arch の systemd パッケージに問題があるのかは判っていません [4]。2014年11月現在、Arch の systemd パッケージにバグレポートは送られていないようです。
watchdog watchdog0: watchdog did not stop!
このスレッドを見て下さい。
少しづつ起動時間が長くなっている
systemd-analyze
を使用して、以前と比べて起動時間が明らかに伸びていると複数のユーザーが報告しています。systemd-analyze blame
を使って NetworkManager が起動するのに異常に長い時間かかるようになったという報告もあります。
問題の原因として /var/log/journal
が巨大になりすぎている可能性があります。そのような場合、フォルダ内のファイルを全て削除して journal のファイルサイズをここに書かれているように制限するよう設定すれば解決します(できればファイルを削除する前に、どこかに一時的にバックアップしてください)。
起動時に systemd-tmpfiles-setup.service の実行に失敗する
systemd 219 から、/usr/lib/tmpfiles.d/systemd.conf
は /var/log/journal
下のディレクトリに対して ACL 属性を指定しており、それによって、ジャーナルが存在するファイルシステムで ACL のサポートを有効にしなくてはならなくなっています。
/var/log/journal
が存在するファイルシステムで ACL を有効化する方法はアクセス制御リスト#ACL の有効化を見て下さい。
systemctl enable で /etc/systemd/system にシンボリックリンクが作成されない
/etc/systemd/system/foo.service
がシンボリックリンクの場合、systemctl enable foo.service
を実行しても以下のエラーで失敗します:
Failed to issue method call: No such file or directory
これは systemd の 仕様 です。絶対パスで有効にすることで回避できます:
# systemctl enable /absolute/path/foo.service
起動時に表示される systemd のバージョンがインストールしているパッケージのバージョンと違う
initramfs を再生成することでバージョンが一致するようになるはずです。
リモートマシンで緊急モードを無効化
リモートマシン (例えば Azure や Google Cloud でホストしている仮想マシン) の緊急モードは無効化すると良いでしょう。緊急モードが起動すると、ネットワークからマシンに接続できなくなってしまうからです。無効化するには以下のコマンドを実行:
# systemctl mask emergency.service # systemctl mask emergency.target
参照
- 公式ウェブサイト
- Wikipedia の記事
- Manual Pages
- systemd Optimizations
- FAQ
- Tips And Tricks
- systemd for Administrators (PDF)
- Fedora プロジェクトによる systemd の説明
- systemd の問題をデバッグする方法
- [5] [6] The H Open マガジンに記載された二部からなる紹介記事
- Lennart のブログ記事
- ステータスアップデート
- ステータスアップデート 2
- ステータスアップデート 3
- 近況
- Fedora の SysVinit と systemd のチートシート
- Emacs の Systemd ファイルのシンタックスハイライト
- digital ocean のチュートリアル