Difference between revisions of "Systemd (日本語)"

Revision as of 07:33, 20 March 2013

zh-CN:Systemd Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end project web page より:

systemd は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、サービス起動時にソケットと D-Bus を有効化し、必要なサービスの開始と Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、（自動）マウントポイントの維持、依存に基づいたサービスのコントロールをサポートします。systemd は sysvinit の代替として動きます。

詳しくは、Wikipedia の記事や本家のホームページもどうぞ。

移行前に考慮すべきこと

• 本家のホームページで、systemd についてざっと読んでください。
• systemd の journal システムは、syslog の機能を提供し置き換えます。ただしこれらは共存できます。下の journal についてのセクションを読んでください。
• systemd が cron、acpid、xinetd の機能を代替しようとする計画がありますが、今はまだ伝統的なデーモンを使い続けることができます。
• インタラクティブな initscript は sytemd では動きません。特に、起動時に netcfg-menu を使うことはできません。

インストール

以下のセクションは systemd にまだ移行していない sysvinit と initscripts の Arch Linux のためのインストール方法です。

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

追加情報

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

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

• initscripts パッケージを消去すると rc.conf の互換性がなくなります。デーモンやネットワークの設定をそこで行なっていた場合、systemd に移行されないので注意してください。２つのシステムを共存させる方法について詳しくは initscripts のエミュレーションのセクションを見て下さい。

ネイティブの設定

ホストネーム

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

# hostnamectl set-hostname myhostname

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

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

/etc/hostname

myhostname

Locale

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

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

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

• ロケールについての詳しい情報が Locale (日本語) にあります。

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

/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

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

# 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 がある場合、削除しても問題ありません。

ハードウェアクロック

Systemd はデフォルトで UTC をハードウェアクロックに使います。

localtime をハードウェアクロックに

ハードウェアクロックで localtime を使うようにするには (するべきではありません):

# timedatectl set-local-rtc true

ハードウェアクロックを UTC に戻すには:

# timedatectl set-local-rtc false

警告したように、ハードウェアクロック (RTC) を localtime に設定すると、夏時間の扱いで問題が生じます。コンピュータの電源が切られている時に夏時間が変わると、次の起動時に時計がおかしくなります (詳しくはここを見て下さい)。最近のカーネルでは起動時にシステム時刻を直接 RTC からセットしますが、その際カーネルは RTC を UTC としてみなします。RTC が localtime だった場合、起動時に毎回システム時刻は間違ってセットされその後修正されることになります。これは予期せぬバグを引き起こす温床になりかねません（時計が戻るのはいいことではありません）。

RTC を localtime に設定する理由のひとつが Windows とのデュアルブートをするためです (Windows は localtime を使っています)。しかしながら、Windows は簡単な registry fix で UTC の RTC を扱うことができます。よって、Linux に localtime を使わせるよりも Windows に UTC を使わせるようにすることが推奨されます。Windows に UTC を使わせる場合、Windows のインターネット時刻機能をオフにするようにしてください。代わりに、上で提案しているように NTP デーモンを有効にすることで Linux を使って RTC を同期させる必要があります。

• 詳しくは Time を見て下さい。

カーネルモジュール

現在、すべての必要なカーネルモジュールは udev によって自動でロードされます。従って、サポート外のカーネルモジュールを使おうとしない限り、設定ファイルにモジュールをロードするように書く必要はありません。しかし、ブートプロセスでモジュールをロードしたい場合や、コンピュータを正しく機能させるためにモジュールをブラックリストに加える必要があるかもしれません。

起動時にモジュールをロード

/etc/modules-load.d/ 下のファイルに、ブート時に読み込むカーネルモジュールを設定します。それぞれの設定ファイルは /etc/modules-load.d/<program>.conf という名前です。設定ファイルには単純にロードすべきカーネルモジュールを一行毎に並べます。空の行や、スペース以外の最初の文字が # や ; の行は無視されます。

/etc/modules-load.d/virtio-net.conf

# Load virtio-net.ko at boot
virtio-net

詳しくは man 5 modules-load.d を見て下さい。

モジュールオプションの設定

追加モジュールオプションは /etc/modprobe.d/modprobe.conf に設定する必要があります。

例:

• ブート中にロードするために loop モジュールには /etc/modules-load.d/loop.conf があります。
• /etc/modprobe.d/modprobe.conf には追加のオプションを指定します、例えば options loop max_loop=64

その後、新しく設定したオプションを cat /sys/module/loop/parameters/max_loop によって検証することができます。

ブラックリスト

モジュールのブラックリストは、kmod によって扱われるので、initscripts の時と同じ方法で動作します。詳細は Module Blacklisting にあります。

ファイルシステムをマウントする

デフォルトのセットアップでは自動的に 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

LVM

initramfs でアクティベイトしていない LVM ボリュームがある場合、lvm2 パッケージで提供されている、lvm-monitoring サービスを有効にしてください:

# systemctl enable lvm-monitoring

同じように、暗号化されたデバイスで LVM をブートの後ろでマウントしている場合(例: /etc/crypttab からマウント)、lvm2 パッケージの、lvm-on-crypt サービスを有効化してください:

# systemctl enable lvm-on-crypt

ACPI 電源管理

systemd は電源関連の ACPI イベントを扱えます。/etc/systemd/logind.conf のオプションを使って設定できます:

• HandlePowerKey: パワーキーが押された時に行う動作を定めます。
• HandleSuspendKey: サスペンドキーが押された時に行う動作を定めます。
• HandleHibernateKey: ハイバネートキーが押された時に行う動作を定めます。
• HandleLidSwitch: フタが閉じられた時に行う動作を定めます。

定めることができる動作は ignore, poweroff, reboot, halt, suspend, hibernate, kexec のどれかです。

オプションが設定されていない時に、systemd が使うデフォルトは: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, HandleLidSwitch=suspend。

グラフィカルセットアップを走らせていなかったり i3 や awesome (日本語) などシンプルなウィンドウマネージャしか使っていないシステムでは、以前から ACPI イベントに反応するものとして使われていた acpid デーモンで置き換えることができるかもしれません。

In the current version of systemd, the Handle* options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.

Sleep フック

systemctl suspend, systemctl hibernate, systemctl hybrid-sleep が実行された時、Systemd はマシンをスリープ状態にするのに pm-utils を使いません; カスタムフックを含む、pm-utils フックは実行されません。ただし、こうしたイベントでカスタムスクリプトを動かすために systemd は２つの似た機構を提供しています。

サスペンド/リジューム サービスファイル

サービスファイルを suspend.target, hibernate.target, sleep.target にフックすることでサスペンド・ハイバネート前後に行うアクションを設定できます。ユーザー・システムアクションを行うにはファイルを分割する必要があります。ユーザーサービスファイルを作動させるには、# systemctl enable suspend@<user> && systemctl enable resume@<user>。例:

/etc/systemd/system/suspend@.service

[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'
ExecStart=/usr/bin/sflock

[Install]
WantedBy=sleep.target

/etc/systemd/system/resume@.service

[Unit]
Description=User resume actions
After=suspend.target

[Service]
User=%I
Type=simple
ExecStartPre=/usr/local/bin/ssh-connect.sh
ExecStart=/usr/bin/mysql -e 'slave start'

[Install]
WantedBy=suspend.target

root アクションでは (# systemctl enable root-suspend でアクティベイト):

/etc/systemd/system/root-resume.service

[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl restart mnt-media.automount

[Install]
WantedBy=suspend.target

/etc/systemd/system/root-suspend.service

[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/pkill sshfs

[Install]
WantedBy=sleep.target

サービスファイルについてのヒント（詳しくは man systemd.service）:

• Type=OneShot の場合、複数の ExecStart= 行を使うことができます。それ以外の場合は使える ExecStart は一行だけです。ExecStartPre を使ったりコマンドをセミコロンで分割することでコマンドを追加することができます（最初の例を見て下さい -- セミコロンの前後にはスペースが必要です）。
• A command prefixed with '-' will cause a non-zero exit status to be ignored and treated as a successful command.
• The best place to find errors when troubleshooting these service files is of course with journalctl.

サスペンド/リジューム サービスファイルの統合

With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).

Example and explanation:

/etc/systemd/system/wicd-sleep.service

[Unit]
Description=Wicd sleep hook
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/share/wicd/daemon/suspend.py
ExecStop=-/usr/share/wicd/daemon/autoconnect.py

[Install]
WantedBy=sleep.target

• RemainAfterExit=yes: After started, the service is always seen active until it is explicitly stopped.
• StopWhenUnneeded=yes: When active, the service will be stopped after sleep.target is stopped.
• Because sleep.target is pulled in by suspend.target, hibernate.target and hybrid-sleep.target and sleep.target itself is a StopWhenUnneeded service, the hook is guaranteed to start/stop properly for different tasks.

/usr/lib/systemd/system-sleep のフック

Systemd は /usr/lib/systemd/system-sleep/ 内の全ての実行可能ファイルを実行するときに、２つの引数を渡します:

• 引数 1: pre か post。マシンが停止するときと起動するとき。
• 引数 2: suspend か hibernate か hybrid-sleep。呼び出されるものによる。

pm-utils とは対照的に、systemd はスクリプトを（一つずつではなく）同時に実行します。

カスタムスクリプトの出力は systemd-suspend.service, systemd-hibernate.service, systemd-hybrid-sleep.service によって記録されます。出力を見るには systemd の journal を使って下さい:

# journalctl -b -u systemd-suspend

カスタムスクリプトを使うかわりに sleep.target, suspend.target, hibernate.target, hybrid-sleep.target を使ってユニットをスリープステートロジックにフックさせることもできます。

カスタムスリープスクリプトの例:

/usr/lib/systemd/system-sleep/example.sh

#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."
    ;;
  post/*)
    echo "Waking up from $2..."
    ;;
esac

スクリプトを実行可能にするのを忘れないで下さい:

# chmod a+x /usr/lib/systemd/system-sleep/example.sh

詳しくは man 7 systemd.special や man 8 systemd-sleep を見て下さい。

一時ファイル

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

詳細は man 5 tmpfiles.d を参照。

ユニット

ユニット設定ファイルは、systemd によって管理される、サービス、ソケット、デバイス、（自動）マウントポイント、スワップパーティション（ファイル）、ターゲット、ファイルシステムのパス、タイマーについての設定をまとめたものです。設定の構文は XDG の .desktop を真似ていて、これは Microsoft Windows の .ini ファイルに影響を受けています。

詳しくは　man 5 systemd.unit を参照。

initscripts から systemd への移行

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 設定ファイルを使うことを推奨します。

DAEMONS 行からの移行

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

# systemctl enable <service_name>.service

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

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

$ 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>。

systemctl の基本的な使い方

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

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

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

$ 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 を見てください。

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

# systemctl start <unit>

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

# systemctl stop <unit>

ユニットを再始動:

# systemctl restart <unit>

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

# systemctl reload <unit>

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

$ systemctl status <unit>

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

$ systemctl is-enabled <unit>

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

# systemctl enable <unit>

# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/

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

# systemctl disable <unit>

ユニットに関連する(ユニットファイルによってサポートされている）マニュアルページを参照する:

$ systemctl help <unit>

systemd をリロードし、新しい、もしくは変化のあったユニットをスキャンする:

# systemctl daemon-reload

電源管理

電源管理には polkit が必要です。 ローカルの systemd-logind のユーザーセッション中で、他のセッションがアクティブでなければ、ルート権限なしで次のコマンドが使えます。そうでなければ（他のユーザが tty でログインしている場合など)、systemd は自動的に root のパスワードを要求するでしょう。

再起動:

$ systemctl reboot

シャットダウンしてパワーオフ:

$ systemctl poweroff

サスペンド(待機):

$ systemctl suspend

ハイバネート(休止):

$ systemctl hibernate

ハイブリッドスリープ (or suspend-to-both):

$ systemctl hybrid-sleep

systemd でデスクトップ環境を動かす

グラフィカルログインを有効にするには、お好きなディスプレイマネージャデーモンを使って下さい (例: KDM)。現在、GDM, KDM, SLiM (日本語), XDM, LXDM, LightDM に対応したサービスファイルが存在します。

# systemctl enable kdm

これだけで動くはずですが、動かない場合、手動で default.target　を設定するか、前のインストールを使います:

# ls -l /etc/systemd/system/default.target

/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

シンボリックリンクを削除すれば systemd は保存した default.target (つまり graphical.target) を使うようになります。

# rm /etc/systemd/system/default.target

systemd-logind を使う

ユーザーセッションの状態を確認するには loginctl を使います。サスペンドや外部デバイスのマウントなどの全ての PolicyKit アクションはそのまま変更せずに動きます。

$ loginctl show-session $XDG_SESSION_ID

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

参照: 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 のシステムバスに乗ったときに使うことができるサービス。

ユニットファイルの編集

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

/etc/systemd/system/<unit>.d/customdependency.conf

[Unit]
Requires=<new dependency>
After=<new dependency>

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

# 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 を使う方法のほうが推奨されます。

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/ からシンボリックリンクを貼ることが示唆されています。

ターゲット表

現在のターゲットを変更する

systemd ではターゲットは"ターゲットユニット"として表現されます。ターゲットを変えるにはこのようにします:

# systemctl isolate graphical.target

これは現在のターゲットを変えるだけで、次の起動時には影響がありません。Sysvinit での、telinit 3 や telinit 5 のようなコマンドと同じです。

起動時のデフォルトターゲットを変更する

標準のターゲットは default.target で、デフォルトで graphical.target （おおよそランレベル 5 と同じ）にエイリアスされています。起動するデフォルトターゲットを変更するには、以下のカーネルパラメータのどれかをブートローダに加えてください:

• systemd.unit=multi-user.target (おおよそランレベル 3 と同じ),
• systemd.unit=rescue.target (おおよそランレベル 1 と同じ).

もしくは、ブートローダではなく default.target を変えることもできます。systemctl を使います:

# systemctl enable multi-user.target

このコマンドの効果は systemctl によって出力されます; 新しいデフォルトターゲットのシンボリックリンクは /etc/systemd/system/default.target に作成されます。ターゲットの設定ファイルに:

[Install]
Alias=default.target

があるときだけこれが動作します。現在、multi-user.target と graphical.target がこれを持っています。

Journal

systemd は、version 38 から自前のログシステムである journal を持っています。従って、syslog デーモンを起動する必要は既にありません。ログを読むには:

# journalctl

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

フィルタリング

journalctl を使って出力にフィルタをかけることができます。

例:

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

# journalctl -b

しかしながら、見たいメッセージは現在のブートではなく、以前のブートからの情報であることがよくあります (例: リカバリーできないシステムクラッシュが起こった場合)。現在、このような機能は実装されていませんが、systemd-devel@lists.freedesktop.org で議論がなされています (September/October 2012)。

今のところ、次のコマンドで（今日の）以前のブートのメッセージを表示できます:

# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac

多くのメッセージが存在する場合、このコマンドの出力にはかなり時間がかかることがあるので注意してください。

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

# journalctl -f

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

# journalctl /usr/lib/systemd/systemd

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

# journalctl _PID=1

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

# journalctl -u netcfg

詳しくは man journalctl, systemd.journal-fields や Lennert の blog post を見て下さい。

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 は必要な設定ファイルを自動的に提供します。

# systemctl enable syslog-ng

最適化

Improve Boot Performance を見て下さい。

ブートプロセスを解析する

systemd-analyze を使う

Systemd には systemd-analyze というツールがあり、どのプロセスが起動を遅くしているのか調べるためにブートプロセスを解析することができます。それに応じてシステムを最適化することも可能です。

起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るためには、シンプルに次を実行:

$ systemd-analyze

ユニットファイルを起動するのにかかった時間で並べて一覧するには:

$ systemd-analyze blame

Bootchart のように、ブートプロセスを視覚的にするために SVG ファイルを生成することもできます:

$ systemd-analyze plot > plot.svg

systemd-bootchart を使う

Bootchart は systemd にマージされ、オリジナルの bootchart と同じように使って起動ができます。カーネルラインに以下を追加してください:

initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart

bootchart2 を使う

bootchart を使うことでブートシークエンスを視覚化できます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、AUR の bootchart2^AUR パッケージにはドキュメント化されてない systemd サービスが付いています。bootchart2 をインストールした後に次を実行してください:

# systemctl enable bootchart

bootchart の使い方についての詳しい説明は bootchart documentation を読んで下さい。

Readahead

Systemd には readahead 機能があり、ほとんどの場合起動時間の短縮が望めます。しかし、どれくらい利益があるかは、あなたの使っているカーネルバージョンやハードドライブのタイプによって大きく変わります（遅くなることもあるかもしれません）。有効にするには次を実行してください:

# systemctl enable systemd-readahead-collect systemd-readahead-replay

readahed を機能させるには、何度か再起動させてやる必要があります。

トラブルシューティング

シャットダウン/再起動にものすごく時間がかかる

シャットダウンに非常に長い時間がかかる（もしくはフリーズする）場合、サービスが存在していないことが問題かもしれません。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 のように、ソケット接続を使ってデータを流すようカーネルを変更する必要があります。

See also

• 公式ウェブサイト
• 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