systemd (日本語) - ArchWiki

# systemd (日本語)

関連記事

- systemd/ユーザー
- systemd/サービス
- systemd/タイマー
- systemd FAQ
- init
- init 比較表
- デーモン一覧
- udev
- ブートパフォーマンスの向上
- ユーザーにシャットダウンを許可する

プロジェクトウェブページ より:

  systemd は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、ソケットや D-Bus のアクティベーションを使用してサービスを起動し、必要なデーモンの開始を行うことができ、Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動) マウントポイントの管理、煩雑な依存関係に基づいたサービスのコントロールを処理します。

Note: systemd が Arch に採用された理由については、フォーラムへのこの投稿をご覧ください。

## systemctl の基本的な使い方

systemd を管理したり内部情報を見るために使うメインのコマンドが `systemctl` です。システムの状態を確かめたりシステムやサービスを管理するために使うのは使い方の一部です。詳しくは `man 1 systemctl` を見て下さい。

Tip: `systemctl` コマンドに `-H <user>@<host>` を渡すと、リモートの systemd と対話できます。SSH を利用してリモートの systemd インスタンスに繋ぐのに使われます。
Note: `systemctl` の公式グラフィカルフロントエンドとして `systemadm` が存在します。公式リポジトリからインストールできる systemd-ui に入っています。また、開発版は AUR の systemd-ui-git パッケージでインストールできます。

### システムの状態を分析する

実行中のユニットを一覧する:

    $ 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` とみなします。例えば `netcfg` と `netcfg.service` は同じように扱われます。
- マウントポイントは自動的に対応する `.mount` ユニットとして扱われます。例えば、`/home` を指定することは `home.mount` の指定と同じです。
- マウントポイントと同じく、デバイスも自動的に対応する `.device` ユニットとして扱われます。従って、`/dev/sda2` の指定は `dev-sda2.device` と同じです。

詳細は `man systemd.unit` を見てください。

Note: ユニットによっては名前に `@` 記号が含まれていることがあります (例: `name@string.service`): これは、そのサービスがテンプレートユニットの インスタンス であることを意味しており、テンプレートユニットのファイル名には `string` の部分が含まれていません (例: `name@.service`)。`string` は instance identifier と呼ばれ、systemctl コマンドでテンプレートユニットを実行するときに指定する引数と似ています: ユニットファイルの中の `%i` が置き換えられます。 正確に言うと、`name@.suffix` テンプレートユニットのインスタンスを作成する前に、systemd は `name@string.suffix` というファイル名のユニットが存在しないか確認します。ただし名前の"衝突"が発生するのは極めて稀で、`@` 記号を含むユニットファイルは大抵テンプレートです。そういう決まりです。また、テンプレートユニットが instance identifier を付けられずに呼ばれたときは、`%i` が置き換えられないため実行失敗になります。
Tip: 以下のコマンドのほとんどは複数のユニットを指定することが可能です、くわしくは `man systemctl` を参照。

いますぐユニットを実行:

    # systemctl start <unit>

いますぐユニットを停止:

    # systemctl stop <unit>

ユニットを再始動:

    # systemctl restart <unit>

ユニットに設定を再読み込みするように通知:

    # systemctl reload <unit>

ユニットの状態を表示(動いているかどうかなど):

    $ systemctl status <unit>

有効化（起動時に自動で実行するよう設定）されているかどうか表示:

    $ systemctl is-enabled <unit>

起動時に実行されるように有効化する:

    # systemctl enable <unit>

システム起動時に実行されないように無効化する:

    # systemctl disable <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

## ネイティブの設定

Note: これらのファイルを作る必要があります。全てのファイルのパーティションは `644` で所有者は `root:root` である必要があります。

### ホストネーム

ホストネームは `/etc/hostname` で設定します。このファイルにシステムのドメインを含めてはいけません。ホストネームを設定するには:

    # hostnamectl set-hostname myhostname

詳しくは `man 5 hostname` や `man 1 hostnamectl` を見て下さい。

ファイルの設定サンプル:

    /etc/hostname

    myhostname

### ロケール

デフォルトのシステムロケールは `/etc/locale.conf` で設定します。デフォルトロケールをセットするには:

    # localectl set-locale LANG="ja_JP.UTF-8"

Note: デフォルトロケールを設定する前に、`/etc/locale.gen` で利用するロケールをアンコメントして `locale-gen` を root で実行してロケールを有効にしておく必要があります。`localectl` でセットするロケールは `/etc/locale.gen` でアンコメントされたロケールでなければなりません。

詳しくは `man 1 localectl` や `man 5 locale.conf` を見て下さい。

- ロケールについての詳しい情報はロケールのページにあります。

ファイルの設定サンプル:

    /etc/locale.conf

    LANG=ja_JP.UTF-8

### 仮想端末

仮想端末 (キーボッドマップ、コンソールフォント、コンソールマップ) の設定は `/etc/vconsole.conf` です:

    /etc/vconsole.conf

    KEYMAP=jp106
    FONT=lat9w-16
    FONT_MAP=8859-1_to_uni

Note: systemd-194 現在、`KEYMAP=` や `FONT=` が空だったり設定されていない場合、ビルトインの kernel フォントと us キーマップが使われます。

キーボッドマップ(キーマップ)を設定する別の方法は:

    # localectl set-keymap jp106

`localectl` で X11 のキーマップを設定することもできます:

    # localectl set-x11-keymap jp106

詳細は `man 1 localectl` や `man 5 vconsole.conf` を見て下さい。

- 詳しい情報はコンソールフォントやキーマップを見て下さい。

### タイムゾーン

タイムゾーンは適切な `/etc/localtime` シンボリックリンクを作ることで設定します。リンク先は `/usr/share/zoneinfo/` 下のゾーン情報ファイルです。自動で行うには:

    # timedatectl set-timezone Asia/Tokyo

詳しくは `man 1 timedatectl`, `man 5 localtime`, `man 7 archlinux` を見て下さい。

または、あなた自身でシンボリックリンクを作って下さい:

    # ln -sf ../usr/share/zoneinfo/Asia/Tokyo /etc/localtime

古い設定ファイル `/etc/timezone` がある場合、削除しても問題ありません。

### ファイルシステムのマウント

デフォルトのセットアップでは自動的に fsck が行われサービスが起動する前にファイルシステムがマウントされます。例えば、systemd は NFS や Samba のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って `/etc/fstab` に明記しなくともローカル・リモードどちらのファイルシステムのマウントも問題ありません。

詳しくは `man 5 systemd.mount` を見て下さい。

#### Automount

- `/home` パーティションが大きい場合は、`/home` を fsck でチェックしている間に `/home` を使わないサービスを起動できるようにしたほうがいいかもしれません。これを行うには `/etc/fstab` の `/home` パーティションのエントリに次のオプションを追加してください:

    noauto,x-systemd.automount

`/home` にアクセスがあるとまず fsck とマウントを行い、準備が整うまで `/home` への全てのファイルアクセスをカーネルによって遮断します。

Note: オプションの追加によって `/home` ファイルシステムのタイプが `autofs` になり、mlocate から（デフォルトで）無視されるようになります。システムによっては、`/home` の automount のスピードアップは大して効果がない場合があります。

- リモートファイルシステムのマウントにも同じことが当てはまります。アクセス時にのみマウントするようにしたい場合は、`noauto,x-systemd.automount` パラメータを使って下さい。さらに、`x-systemd.device-timeout=#` オプションを使うことでネットワークが切れた時のタイムアウト時間を設定できます。

- ファイルシステムをキーファイルで暗号化しているときは、`/etc/crypttab` の適切なエントリに `noauto` パラメータを追加することもできます。Systemd は起動時に暗号化されたデバイスを開かなくなり、代わりに、デバイスが実際にアクセスされるまで待機して、それから指定したキーファイルで（マウントする前に）自動でデバイスを開くようになります。デバイスが有効になるまで systemd が待機することがなくなるので、暗号化した RAID デバイスなどを使っているときは起動時間が数秒節約できます。例:

    /etc/crypttab

    data /dev/md0 /root/key noauto

## カスタム .service ファイルを書く

systemd の ユニットファイル の構文は XDG の Desktop Entry Specification である .desktop から影響を受けています。そして .desktop は Microsoft Windows の .ini ファイルからインスパイアされています。ユニットファイルは2つの場所に配置されます。優先度が低い方から説明すると:

- `/usr/lib/systemd/system/`: インストールしたパッケージに含まれているユニット
- `/etc/systemd/system/`: システムの管理者がインストールしたユニット

Note: ユーザーモードで systemd を動作させたときにロードされるパスは完全に異なります。

もっと多くのサンプルが Systemd/Services にあります。

### 依存関係を解決する

systemd ではユニットファイルを適切に書くことで依存関係を解決します。一番典型的なケースは、ユニット `A` が走る前に、ユニット `A` がユニット `B` を必要としている場合です。この場合、`A` の`[Unit]` セクションに `Requires=B` と `After=B` を加えます。依存が必然ではない場合、代わりに `Wants=B` と `After=B` を加えます。`Wants=` と `Requires=` は `After=` を含まないことに注意してください、もし `After=` を明記しなかったときは、２つのユニットは並行して実行されます。

基本的に、依存関係はターゲットではなくサービスに配置します。例えば、`network.target` はネットワークインターフェースを設定する全てのサービスによって使われるので、`network.target` が起動し終わってからあなたのカスタムユニットを起動させる順番にします。

### タイプ

カスタムサービスファイルを書くときにどのスタートアップタイプを使うべきか考える必要があります。タイプは `[Service]` セクションの `Type=` パラメータで設定します。より詳しい説明は `man systemd.service` を見て下さい。

- `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` と非常に似ています。ただし、サービスバイナリの実行は全てのジョブが処理されるまで待たされます。これを使えば、コンソールに状態を出力するシェルサービスで、出力が混じってしまうのを避けることができます。

### ユニットファイルの編集

パッケージによって提供されたユニットファイルを編集するときは、`/etc/systemd/system/<unit>.d/` という名のディレクトリ (例: `/etc/systemd/system/httpd.service.d/`) を作成してそのなかに `*.conf` を置くことでオプションを上書きしたり追加したりすることが可能です。Systemd が `*.conf` ファイルをパースして元のユニットファイルの一番上に設定を適用します。例えば、ユニットに追加の依存を入れたい時は、以下のファイルを作成します:

    /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

Note: `ExecStart` は置き換える前に空白にする必要があるので注意してください ([1])。

サービスを自動的に再起動するには:

    /etc/systemd/system/unit.d/restart.conf

    [Service]
    Restart=always
    RestartSec=30

そして変更を適用するために次を実行してください:

    # systemctl daemon-reload
    # systemctl restart <unit>

または、古いユニットファイルを `/usr/lib/systemd/system/` から `/etc/systemd/system/` にコピーして変更を加えることもできます。`/etc/systemd/system/` 内のユニットファイルは `/usr/lib/systemd/system/` 内の同じユニットを上書きします。パッケージのアップグレードによって `/usr/lib/` の元のユニットが変更されたとき、変更が `/etc/` 内のあなたのカスタムユニットファイルには自動では適用されないことに注意してください。さらに、変更するたびに手動で `systemctl reenable <unit>` によってユニットを reenable する必要があります。したがって前述の `*.conf` を使う方法のほうが推奨されます。

Tip: `systemd-delta` を使うことでどのファイルが上書きされ、どこが変更されたのか調べることができます。

時々、提供されているユニットファイルがアップデートされることがあるので、systemd-delta を使ってシステム管理を行なって下さい。

### Vim でのユニットのシンタックスハイライト

公式リポジトリから vim-systemd をインストールすることで、Vim でのユニットファイルのシンタックスハイライトが可能です。

## ターゲット

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 ターゲット | 説明
--- | --- | ---
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` にエイリアスされています。起動時のデフォルトターゲットを変更するには、以下のカーネルパラメータのどれかをブートローダに加えてください:

Tip: `.target` 拡張子は省くことができます。

- `systemd.unit=multi-user.target` (昔のランレベル 3 とほぼ同じ)。
- `systemd.unit=rescue.target` (昔のランレベル 1 とほぼ同じ)。

また、ブートローダには修正を加えずに `default.target` を変えることもできます。`systemctl` を使います:

    # systemctl set-default multi-user.target

以前に設定した default.target を上書きできるようにするには、force オプションを使って下さい:

    # systemctl set-default -f multi-user.target

このコマンドの効果は `systemctl` によって出力されます; 新しいデフォルトターゲットのシンボリックリンクは `/etc/systemd/system/default.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 ページを参照してください。

Note: systemd-tmpfiles-setup サービスは適切なモジュールがロードされる前に実行されることがあるので、`/sys` にオプションを設定するのにこの方法は使えません。このため設定したいオプションのパラメータをモジュールが持っているか確認するには `modinfo module` を使い、オプションを設定は /etc/modprobe.d 下の設定ファイルを使って下さい。もしくはデバイスが現れたときにすぐ適切な属性を設定する udev ルールを書いて下さい。

## タイマー

タイマーは ".timer" で終わる名前を持つユニット設定ファイルで、時間に基づく実行を行うために、systemd で制御・管理するタイマーの情報をエンコードしています。systemd/タイマー を参照してください。

Note: タイマーは cron の機能をほぼ全て置き換えることができます。詳しくは、systemd/タイマー#cron を置き換える を参照してください。

## Journal

systemd は、バージョン 38 から自前のログシステムである journal を搭載しています。従って、syslog デーモンを起動する必要はもはやありません。ログを読むには:

    # journalctl

デフォルトで (`/etc/systemd/journald.conf` 内で `Storage=` が `auto` に設定されているとき)、journal は `/var/log/journal/` へ書き込みを行います。Arch Linux では `/var/log/journal/` ディレクトリは systemd の一部であり、あなたや何らかのプログラムがディレクトリを削除した場合、systemd は自動で再作成しませんが、systemd のアップデートがあるとディレクトリは作りなおされます。それまでログは代わりに `/run/systemd/journal` に書き込まれます。ただし再起動時にこのログは消失してしまいます。

Tip: `/var/log/journal/` が btrfs ファイルシステムに存在する場合、ディレクトリの Copy-on-Write を無効にするべきです。詳しくはBtrfs#コピーオンライト (CoW) を読んで下さい。

### フィルタリング

`journalctl` を使って出力にフィルタをかけることができます。表示したりフィルタリングをするメッセージが大量にある場合、かなり時間がかかります。コマンドの出力は相当の時間がたってから表示されるかもしれません。

Tip: journal はバイナリ形式で保存されますが、保存されるメッセージの中身に修正は加わりません。このため、systemd をインストールしていない環境でリカバリなどをするために、strings を使って回覧することが可能です。コマンドの例: `$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i message`

例:

- 起動時からの全てのメッセージを表示:

      # journalctl -b

  場合によっては最新のブートメッセージではなく、以前のブートのメッセージを読みたいことがあります (例えば復旧できないシステムクラッシュが起こった場合)。`-b` フラグに任意のパラメータを付けることでメッセージをオフセットして読むことが可能です: `journalctl -b -0` は最新のブートのメッセージを、`journalctl -b -1` は一つ前のブートのメッセージを表示し `journalctl -b -2` は二つ前、と続きます。詳しくは `man 1 journalctl` を見て下さい、セマンティックスはより強力です。
- 特定の日付 (任意で時間も指定可能) からのメッセージを全て表示:

      # journalctl --since="2012-10-30 18:17:16"

- 20分前からのメッセージを全て表示:

      # journalctl --since "20 min ago"

- 新しいメッセージを表示:

      # journalctl -f

- 特定の実行ファイルによる全てのメッセージを表示:

      # journalctl /usr/lib/systemd/systemd

- 特定のプロセスによる全てのメッセージを表示:

      # journalctl _PID=1

- 特定のユニットによる全てのメッセージを表示:

      # journalctl -u netcfg

- カーネルのリングバッファを表示:

      # journalctl -k

- syslog の facility をフィルタリングすることで auth.log と同等の内容を表示:

      # journalctl -f -l SYSLOG_FACILITY=10

詳しくは `man 1 journalctl`, `man 7 systemd.journal-fields` や Lennart のブログ記事 を見て下さい。

Tip: デフォルトで、journalctl は画面からはみ出る行を切り詰めますが、場合によっては、折り返しが有効になっていたほうが読みやすいことがあります。`SYSTEMD_LESS` 環境変数 によってこれを制御することができ、less (デフォルトのページャ) に渡すオプションを指定します。デフォルトは `FRSXMK` (詳しくは `man 1 less` や `man 1 journalctl` を参照) です。

`S` オプションを省くことで、出力は折り返されるようになります。例えば、以下のように journalctl を起動してください:

    $ SYSTEMD_LESS=FRXMK journalctl

この挙動をデフォルトに設定したいならば、`~/.bashrc` や `~/.zshrc` でこの変数を export してください。

### journal のサイズ制限

journal が永続的（不揮発性）の場合、デフォルトではファイルシステムの容量の 10% に制限されます。例えば、`/var/log/journal` が 50GiB の root パーティションにのっている場合、5GiB がログデータの上限になります。`/etc/systemd/journald.conf` の `SystemMaxUse` を変更すれば、最大サイズを変更できます。例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します:

    SystemMaxUse=50M

詳細は `man journald.conf` を参照してください。

### journald と syslog の結合

古典的な syslog との互換性は、すべてのメッセージがソケット `/run/systemd/journal/syslog` に転送されることで実現されます。syslog を使うには、`/dev/log/` の代わりにこのソケットを指定します (公式アナウンス)。syslog-ng は必要な設定ファイルを自動的に提供します。

systemd 216 から `journald.conf` のソケットの転送はデフォルトで `no` になっています。このため、journald で syslog-ng を使用するには `/etc/systemd/journald.conf` に `ForwardToSyslog=yes` オプションを設定する必要があります。詳しくは Syslog-ng#概要 を参照。

rsyslog を使用する場合、オプションを変更する必要はありません。rsyslog は自力で journal からメッセージを引っ張ってくるからです。

### journald を /dev/tty12 に転送する

`/etc/systemd/journald.conf` で以下を有効にしてください:

    ForwardToConsole=yes
    TTYPath=/dev/tty12
    MaxLevelConsole=info

次を実行して journald を再起動してください:

    # systemctl restart systemd-journald

## SysVinit/initscripts からの移行

Note:

- systemd と systemd-sysvcompat は 2012-10-13 以降のインストールメディアではデフォルトでインストールされます。このセクションは未だに sysvinit や initscripts を使っている Arch Linux システムに向けて書かれています。
- Arch Linux を VPS で動かしている場合、Virtual Private Server#Moving your VPS from initscripts to systemd を参照してください。

### 移行前に考慮すべきこと

- 本家のホームページ で、systemd についてざっと読んでください。
- systemd の journal システムは、syslog を置き換えることができますが、この2つは共存できます。#Journal を見て下さい。
- systemd は cron、acpid、xinetd の機能の一部を代替できますが、あなたが望まない限り伝統的なデーモンを使うのを止める必要はありません。
- インタラクティブな initscript は sytemd では動きません。特に、起動時に netcfg-menu を使うことはできません (FS#31377)。

### インストール

1. 公式リポジトリから systemd をインストールしてください。
2. カーネルパラメータに次を加えます: `init=/usr/lib/systemd/systemd`
3. 完了したら、必要なサービスを `systemctl enable <service_name>.service` を使って有効にできます (大雑把に言うと `DAEMONS` 行にサービスを追加するのと同じです)。
4. システムを再起動し、`systemd` がアクティブになっていることを次のコマンドで確認します: `cat /proc/1/comm`。`systemd` の文字が返ってくるはずです。
5. systemd であなたのホストネームを設定します: `hostnamectl set-hostname myhostname` または `/etc/hostname`。
6. initscripts と sysvinit をシステムから削除し systemd-sysvcompat をインストールしてください。
7. もう必要なくなった `init=/usr/lib/systemd/systemd` パラメータを削除してください。systemd-sysvcompat がデフォルトの init になります。

### initscripts のエミュレーション

伝統的な Arch の設定ファイルは initscripts パッケージによって使われています。systemd と initscripts がインストールされていて、systemd によってシステムが動いている時、systemd は以下のことを行います:

1. `/etc/rc.conf` の `DAEMONS` 行をパースし、ブート時にデーモンを起動します
2. ブート中に `/etc/rc.local` を実行します
3. シャットダウン中に `/etc/rc.local.shutdown` を実行します

Initscripts のエミュレーションはユーザーが systemd に移行するのを手助けする過渡期の手段として存在しています、そして最終的には取り除かれる予定です。ネイティブな systemd は設定の中心として `rc.conf` を使いません、`/etc/rc.conf` が使えなくなる前にネイティブの systemd 設定ファイルを使うことを推奨します。

Note: `/etc/rc.local` を置換するには、起動時に実行したいもののカスタムサービスファイルを書くことを推奨します。このセクションに方法を記述しています。
Note: `Ctrl+Alt+Del` で再起動しないように `/etc/inittab` で設定していた場合、root で `systemctl mask ctrl-alt-del.target` を実行して systemd でも再設定する必要があります。
Warning: systemd (197-4 以降) と initscripts 両方をインストールしていて、`/etc/rc.local` が存在する場合、(systemd 197-4 から getty@tty1.service が rc-local.service を待たなくなり、getty が起動できなくなるために) ブートプロセスが終了しません。`/etc/rc.local` を削除するか名前を変えて下さい。

### DAEMONS 行からの移行

純粋な systemd セットアップのためには、完全に `/etc/rc.conf` ファイルを削除して `systemctl` だけを使ってサービスを有効にしなくてはなりません。`/etc/rc.conf` の `DAEMONS` 行のそれぞれの `<service_name>` に対して次を実行します:

    # systemctl enable <service_name>.service

Tip: 一般的に使われるデーモンの initscripts と systemd の比較表がここにあります。

`<service_name>.service` が存在しない場合:

- ほとんどの場合、systemd は違う名前を使っています。例えば、`crond` init デーモンは `cronie.service` に、`alsa` init デーモンは `alsa-store.service` と `alsa-restore.service` になっています。他にも `network` デーモンは、他のサービスファイルに置き換わっています (詳しくはネットワーク設定を見て下さい)。
- サービスファイルが systemd にない場合。その場合、起動中にサービスを作動させるのに `rc.conf` を使いつづける必要があります。

Tip: パッケージの中身を見て、どのサービス名でデーモン起動スクリプトが含まれているのか見ることができます。例:

    $ pacman -Ql cronie
    [...]
    cronie /etc/rc.d/crond                            #DAEMONS 行で使われるデーモン initscript ("純粋な" systemd では使われません)
    [...]
    cronie /usr/lib/systemd/system/cronie.service     #対応する systemd のデーモンサービス
    [...]

- 最後に、サービスによっては、ユーザーの操作で有効にする必要がないものがあります。例えば、`dbus.service` は `dbus-core` がインストールされると自動で有効にされます。`alsa-store.service` と `alsa-restore.service` も systemd によって自動で有効にされます。利用できるサービスと状態をチェックするには `systemctl` コマンドを使います: `systemctl status <service_name>`。

### 追加情報

- カーネルパラメータに `quiet` を設定している場合、それを削除することで、起動中に何が起こっているかわかりやすくなります。

- systemd を使っていてユーザーにグループ (`sys`, `disk`, `lp`, `network`, `video`, `audio`, `optical`, `storage`, `scanner`, `power`, etc.) を設定する必要はほとんどありません。グループは機能を破壊することさえあります。例えば、`audio` グループは高速なユーザー切り替えやアプリケーションのソフトウェアミキシングを無効にします。全ての PAM ログインは logind セッションを提供します。オーディオ/ビデオデバイスに POSIX ACL を通して権限を与えたり、udisks を使ってリムーバルディスクのマウントなどの操作を行います。

- ネットワークの設定方法はネットワーク設定を見て下さい。

## トラブルシューティング

### systemd のエラーを調査する

例えば、`systemd-modules-load` サービスのエラーを調べるとします:

1. 起動に失敗している systemd サービスを探しましょう:

    $ systemctl --state=failed

    systemd-modules-load.service   loaded failed failed  Load Kernel Modules

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`

More Debugging Information

### 特定のサービスの問題を診断

ある 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

そしてシステムを再起動してください。

### 再起動やシャットダウン時のエラーメッセージ

#### 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 パッケージに問題があるのかは判っていません [2]。2014年11月現在、Arch の systemd パッケージにバグレポートは送られていないようです。

#### watchdog watchdog0: watchdog did not stop!

このスレッドを見て下さい。

### 少しづつ起動時間が長くなっている

`systemd-analyze` を使用して、以前と比べて起動時間が明らかに伸びていると複数のユーザーが報告しています。`systemd-analyze blame` を使ってNetworkManager が起動するのに異常に長い時間かかるようになったという報告もあります。

問題の原因として `/var/log/journal` が巨大になりすぎている可能性があります。そのような場合、フォルダ内のファイルを全て削除して journal のファイルサイズをここに書かれているように制限するよう設定すれば解決します（できればファイルを削除する前に、どこかに一時的にバックアップしてください）。

## 参照

- 公式ウェブサイト
- Wikipedia article
- Manual Pages
- systemd Optimizations
- FAQ
- Tips And Tricks
- systemd for Administrators (PDF)
- About systemd on Fedora Project
- How to debug systemd problems
- Two part introductory article in The H Open magazine.
- Lennart's blog story
- status update
- status update2
- status update3
- most recent summary
- Fedora's SysVinit to systemd cheatsheet

Categories:

- Daemons and system services (日本語)
- Boot process (日本語)