systemd (日本語)
| 概括 |
|---|
| systemd をインストールし、設定する方法についての文書です。 |
| 関連項目 |
| systemd/User |
| systemd/Services |
| systemd/cron functionality |
| systemd FAQ (日本語) |
| init Rosetta (日本語) |
| Daemons List (日本語) |
| udev (日本語) |
| Improve Boot Performance (日本語) |
project web page より:
systemd は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、サービス起動時にソケットと D-Bus を有効化し、必要なサービスの開始と Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、（自動）マウントポイントの維持、依存に基づいたサービスのコントロールをサポートします。
Contents |
SysVinit/initscripts からの移行
移行前に考慮すべきこと
- 本家のホームページ で、systemd についてざっと読んでください。
- systemd の journal システムは、syslog を置き換えることができますが、この2つは共存できます。#Journal を見て下さい。
- systemd は cron、acpid、xinetd の機能の一部を代替できますが、あなたが望まない限り伝統的なデーモンを使うのを止める必要はありません。
- インタラクティブな initscript は sytemd では動きません。特に、起動時に netcfg-menu を使うことはできません (FS#31377)。
インストール
- 公式リポジトリから systemd をインストールしてください。
- カーネルパラメータに次を加えます:
init=/usr/lib/systemd/systemd - 完了したら、必要なサービスを
systemctl enable <service_name>.serviceを使って有効にできます (大雑把に言うとDAEMONS行にサービスを追加するのと同じです)。 - システムを再起動し、
systemdがアクティブになっていることを次のコマンドで確認します:cat /proc/1/comm。systemdの文字が返ってくるはずです。 - systemd であなたのホストネームを設定します:
hostnamectl set-hostname myhostnameまたは/etc/hostname。 - initscripts と sysvinit をシステムから削除し systemd-sysvcompat をインストールしてください。
- もう必要なくなった
init=/usr/lib/systemd/systemdパラメータを削除してください。systemd-sysvcompat がデフォルトの init になります。
initscripts のエミュレーション
伝統的な Arch の設定ファイルは initscripts パッケージによって使われています。systemd と initscripts がインストールされていて、systemd によってシステムが動いている時、systemd は以下のことを行います:
-
/etc/rc.confのDAEMONS行をパースし、ブート時にデーモンを起動します - ブート中に
/etc/rc.localを実行します - シャットダウン中に
/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 は違う名前を使っています。例えば、
crondinit デーモンはcronie.serviceに、alsainit デーモンはalsa-store.serviceとalsa-restore.serviceになっています。他にもnetworkデーモンは、他のサービスファイルに置き換わっています (詳しくは Network Configuration (日本語) を見て下さい)。 - サービスファイルが systemd にない場合。その場合、起動中にサービスを作動させるのに
rc.confを使いつづける必要があります。
- 最後に、サービスによっては、ユーザーの操作で有効にする必要がないものがあります。例えば、
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 を使ってリムーバルディスクのマウントなどの操作を行います。
- ネットワークの設定方法は Network Configuration (日本語) を見て下さい。
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>
システム起動時に実行されないように無効化する:
# 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, SDDM に対応したサービスファイルが存在します。
# 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
kdm を有効にした後、シンボリックリンク "display-manager.service" が /etc/systemd/system/ に設定されるはずです:
# ls -l /etc/systemd/system/display-manager.service
/etc/systemd/system/display-manager.service -> /usr/lib/systemd/system/kdm.service
systemd-logind を使う
ユーザーセッションの状態を確認するには loginctl を使います。サスペンドや外部デバイスのマウントなどの全ての PolicyKit アクションはそのまま動きます。
$ loginctl show-session $XDG_SESSION_ID
ネイティブの設定
ホストネーム
ホストネームは /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"
詳しくは 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 がある場合、削除しても問題ありません。
カーネルモジュール
現在、すべての必要なカーネルモジュールは 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
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 デーモンで置き換えることができるかもしれません。
現在のバージョンの systemd では、Handle* オプションは（デスクトップ環境のパワーマネージャなどの）プログラムによって "inhibited" (一時的にオフ) にされない限りシステム全体に適用されます。停止されなければ、systemd がシステムをサスペンドした状態で終わることができ、立ち上がった時に他のパワーマネージャによってもう一度停止されます。
systemctl hibernate を使うには Hibernation や Mkinitcpio Resume Hook (pm-utils をインストールする必要はありません) の指示に従う必要があります。
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を使ったりコマンドをセミコロンで分割することでコマンドを追加することができます（最初の例を見て下さい -- セミコロンの前後にはスペースが必要です）。 - コマンドの前に '-' を付けるとエラーが起こっても（終了ステータスが0以外でも）無視され、コマンドは成功したとして扱われます。
- サービスファイルのトラブルシューティングのときにエラーを見つけるには
journalctlを使うのがベストです。
サスペンド/レジューム サービスファイルの統合
サスペンド/レジューム サービスファイルを統合すれば、様々なフェイズ（スリープ・レジューム）やターゲット（サスペンド・ハイバネート・ハイブリッドスリープ）でやることをひとつのフックで行うことができます。
例と説明:
/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: 起動後、明示的に止められるまでサービスは常時 active になります。 -
StopWhenUnneeded=yes: active のとき、サービスは sleep.target が停止した後に止められます。 - Because sleep.target は suspend.target, hibernate.target, hybrid-sleep.target から呼ばれ sleep.target 自身は StopWhenUnneeded サービスなので、タスクごとにフックが正しく起動・停止することが保証されています。
/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
詳細は systemd-tmpfiles や tmpfiles.d(5) の man ページを参照してください。
カスタム .service ファイルを書く
systemd のユニットファイルの構文は XDG の Desktop Entry Specification である .desktop から影響を受けています。そして .desktop は Microsoft Windows の .ini ファイルにインスパイアされたものです。
もっと多くのサンプルが 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/ という名のディレクトリ (例: /etc/systemd/system/httpd.service.d/) を作成してそのなかに *.conf を置くことでオプションを上書きしたり追加したりすることが可能です。Systemd が *.conf ファイルをパースして元のユニットファイルの一番上に設定を適用します。例えば、ユニットに追加の依存を入れたい時は、以下のファイルを作成します:
/etc/systemd/system/<unit>.d/customdependency.conf
[Unit] Requires=<new dependency> After=<new dependency>
oneshot タイプでないユニットの {ic|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
そして変更を適用するために次を実行してください:
# 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 を使う方法のほうが推奨されます。
時々、提供されているユニットファイルがアップデートされることがあるので、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 ターゲット | Notes |
|---|---|---|
| 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 enable multi-user.target
このコマンドの効果は systemctl によって出力されます; 新しいデフォルトターゲットのシンボリックリンクは /etc/systemd/system/default.target に作成されます。ターゲットの設定ファイルに:
[Install] Alias=default.target
があるときだけこれが動作します。現在、multi-user.target と graphical.target がこれを持っています。
タイマー
Systemd は cron の機能をほぼ全て置き換えることができます。詳しくは、systemd/cron functionality を参照してください。
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 netctl
カーネルのリングバッファを表示:
# journalctl _TRANSPORT=kernel
詳しくは man 1 journalctl, man 7 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
トラブルシューティング
systemd のエラーを調査する
例えば、systemd-modules-load サービスのエラーを調べるとします:
1. 起動に失敗している systemd サービスを探しましょう:
$ systemctl | grep -i 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)
3. エラーを細かく調べるためのプロセス ID (PID) を入手しました。Process ID を使って (ここでは: 15630) 以下のコマンドを実行してください:
$ journalctl -b _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/ total 44 drwxr-xr-x 2 root root 4096 14. Jul 11:01 . drwxr-xr-x 114 root root 12288 25. Aug 11:40 .. -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 で見つけたオプションの前に # を挿入して無効化してみましょう:
$ nano /etc/modules-load.d/blacklist.conf # blacklist usblp # install usblp /bin/false
6. では、systemd-modules-load を起動してみることにします:
$ systemctl start systemd-modules-load.service
成功した場合、何も表示されないはずです。何かエラーが表示される場合は、手順 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 はサービスを 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 のように、ソケット接続を使ってデータを流すようカーネルを変更する必要があります。
クラッシュしたアプリケーションのダンプのジャーナルを無効にする
以下を実行して /lib/sysctl.d/ の設定を上書きして下さい:
# ln -s /dev/null /etc/sysctl.d/50-coredump.conf # sysctl kernel.core_pattern=core
これによってコアダンプの journal へのログを無効にします。
RLIMIT_CORE のデフォルト値である 0 はコアファイルも書き込まれないという意味なので注意してください。 コアファイルが欲しい場合、シェルでコアファイルのサイズの制限を解除 (unlimit) する必要があります:
$ ulimit -c unlimited
詳細は sysctl.d や the documentation for /proc/sys/kernel を見て下さい。
参照
- 公式ウェブサイト
- 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
- 通常ユーザーがシャットダウンをできるように systemd を設定する