systemd
関連記事
プロジェクトウェブページ より:
- systemd は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、ソケットや D-Bus のアクティベーションを使用してサービスを起動し、必要なデーモンの開始を行うことができ、Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動) マウントポイントの管理、煩雑な依存関係に基づいたサービスのコントロールを処理します。
目次
- 1 systemctl の基本的な使い方
- 2 ネイティブの設定
- 3 カスタム .service ファイルを書く
- 4 ターゲット
- 5 一時ファイル
- 6 タイマー
- 7 Journal
- 8 SysVinit/initscripts からの移行
- 9 トラブルシューティング
- 10 参照
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
ハイブリッドスリープ (もしくは suspend-to-both):
$ systemctl hybrid-sleep
ネイティブの設定
ホストネーム
ホストネームは /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 を見て下さい。
- ロケールについての詳しい情報はロケールのページにあります。
ファイルの設定サンプル:
/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 がある場合、削除しても問題ありません。
ファイルシステムのマウント
デフォルトのセットアップでは自動的に 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/: システムの管理者がインストールしたユニット
もっと多くのサンプルが Systemd/サービス にあります。
依存関係を解決する
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
サービスを自動的に再起動するには:
/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 ターゲット | 説明 |
|---|---|---|
| 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
以前に設定した 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 ページを参照してください。
タイマー
タイマーは ".timer" で終わる名前を持つユニット設定ファイルで、時間に基づく実行を行うために、systemd で制御・管理するタイマーの情報をエンコードしています。systemd/タイマー を参照してください。
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 に書き込まれます。ただし再起動時にこのログは消失してしまいます。
フィルタリング
journalctl を使って出力にフィルタをかけることができます。表示したりフィルタリングをするメッセージが大量にある場合、かなり時間がかかります。コマンドの出力は相当の時間がたってから表示されるかもしれません。
例:
- 起動時からの全てのメッセージを表示:
# 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 のブログ記事 を見て下さい。
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 からの移行
移行前に考慮すべきこと
- 本家のホームページ で、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デーモンは、他のサービスファイルに置き換わっています (詳しくはネットワーク設定を見て下さい)。 - サービスファイルが 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 を使ってリムーバルディスクのマウントなどの操作を行います。
- ネットワークの設定方法はネットワーク設定を見て下さい。
トラブルシューティング
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
特定のサービスの問題を診断
ある 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