「Systemd」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎ターゲット: デフォルトのターゲット順序を翻訳して追加)
304行目: 304行目:
 
これは現在のターゲットを変えるだけで、次の起動時には影響がありません。[[SysVinit]] での、{{ic|telinit 3}} や {{ic|telinit 5}} のようなコマンドと同じです。
 
これは現在のターゲットを変えるだけで、次の起動時には影響がありません。[[SysVinit]] での、{{ic|telinit 3}} や {{ic|telinit 5}} のようなコマンドと同じです。
   
=== 起動時のデフォルトターゲットを変更する ===
+
=== 起動するデフォルトターゲットを変更 ===
   
標準のターゲットは {{ic|default.target}} で、デフォルトで (昔のランレベル 5 に大体対応している) {{ic|graphical.target}} にエイアスされています。起動時のデフォルトターゲットを変更するには、以下の[[カーネパラメータ]]のどれかをブートローダ加えてください:
+
標準のターゲットは {{ic|default.target}} で、これは {{ic|graphical.target}} へのシンボックリンクです。これは、古いランレベ5ほぼ対応します。
   
  +
''systemctl'' を使用して現在のターゲットを確認するには、次の手順に従います。
{{Tip|{{ic|.target}} 拡張子は省くことができます。}}
 
   
  +
$ systemctl get-default
* {{ic|1=systemd.unit=multi-user.target}} (昔のランレベル 3 とほぼ同じ)。
 
* {{ic|1=systemd.unit=rescue.target}} (昔のランレベル 1 とほぼ同じ)。
 
   
また、ブートには修正を加えずに {{ic|default.target}} を変えることもできます。{{ic|systemctl}} を使います:
+
ブート先のデフォルトタゲットを変更するには{{ic|default.target}} シンボリックリンクを変更します。''systemctl'' の場合
   
# systemctl set-default multi-user.target
+
{{hc|1=# systemctl set-default multi-user.target|2=
  +
Removed /etc/systemd/system/default.target.
  +
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.}}
  +
  +
または、次の [[カーネルパラメータ]] のいずれかをブートローダに追加します。
  +
  +
* {{ic|1=systemd.unit=multi-user.target}} (これは、古いランレベル3にほぼ対応しています)
  +
* {{ic|1=systemd.unit=rescue.target}} (これは、古いランレベル1にほぼ対応しています)
   
 
=== デフォルトのターゲット順序 ===
 
=== デフォルトのターゲット順序 ===

2021年12月1日 (水) 05:58時点における版

関連記事

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

systemd は Linux 環境の基本構成スイートであり、SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、ソケットや D-Bus のアクティベーションを使用してサービスを起動し、必要なデーモンの開始を行うことができ、Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動) マウントポイントの管理、煩雑な依存関係に基づいたサービスのコントロールを処理します。systemd は sysvinit の代替として SysV や LSB init スクリプトをサポートしています。init としての機能以外にも、ログデーモンやホストネーム・時刻・ロケールなどシステムの基本設定を制御するユーティリティ、ログイン中のユーザーから実行中のコンテナや仮想マシン、システムアカウントまで管理する機能、ネットワーク設定や時刻同期あるいは名前解決などを管理するシンプルなデーモンも含まれています。
ノート: systemd が Arch に採用された理由については、フォーラムへのこの投稿をご覧ください。

目次

systemctl の基本的な使い方

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

ヒント:
  • systemctl コマンドに -H <user>@<host> を渡すと、リモートの systemd と対話できます。SSH を利用してリモートの systemd インスタンスに繋ぐのに使われます。
  • systemctl の公式グラフィカルフロントエンドとして systemadm が存在します。公式リポジトリからインストールできる systemd-ui に入っています。
  • Plasma を使っている場合 systemd-kcmAUR をインストールすることで systemctl のグラフィカルフロントエンドを使えます。モジュールをインストールすると System administration の下に設定が追加されます。

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

システムの状態を表示:

$ systemctl status

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

$ systemctl

または:

$ systemctl list-units

失敗したユニットを一覧する:

$ systemctl --failed

実行可能なユニットファイルは /usr/lib/systemd/system//etc/systemd/system/ にあります (後者が優先的に使われます)。インストールされたユニットを一覧するには:

$ systemctl list-unit-files

ユニットを使う

ユニットには、例えば、サービス (.service) やマウントポイント (.mount)、デバイス (.device)、ソケット (.socket) などがあります。

systemctl を使うとき、一般的には拡張子 (suffix) を含むユニットファイルの完全な名前を指定する必要があります。例えば、sshd.socket のように。しかし、以下のような場合には省略形が存在します:

  • 拡張子が指定されない場合、systemctl は .service とみなします。例えば netctlnetctl.service は同じように扱われます。
  • マウントポイントは自動的に対応する .mount ユニットとして扱われます。例えば、/home を指定することは home.mount の指定と同じです。
  • マウントポイントと同じく、デバイスも自動的に対応する .device ユニットとして扱われます。従って、/dev/sda2 の指定は dev-sda2.device と同じです。

詳細は systemd.unit(5) を見てください。

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

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

# systemctl start unit

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

# systemctl stop unit

ユニットを再始動:

# systemctl restart unit

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

# systemctl reload unit

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

$ systemctl status unit

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

$ systemctl is-enabled unit

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

# systemctl enable unit

ユニットを有効化して今すぐ起動する:

# systemctl enable --now unit

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

# systemctl disable unit

ユニットをマスクすることで起動しないようにできます:

# systemctl mask unit

ユニットのマスクを解除:

# systemctl unmask unit

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

$ systemctl help unit

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

# systemctl daemon-reload
ヒント: systemd 220 から、--now スイッチを使うことで enable で指定したユニットをすぐに起動して、disablemask したユニットを停止できるようになりました。

電源管理

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

再起動:

$ systemctl reboot

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

$ systemctl poweroff

サスペンド(待機):

$ systemctl suspend

ハイバネート(休止):

$ systemctl hibernate

ハイブリッドスリープ (もしくは suspend-to-both):

$ systemctl hybrid-sleep

ユニットファイル

systemd の ユニットファイル の構文は XDG の Desktop Entry Specification である .desktop から影響を受けています。そして .desktop は Microsoft Windows の .ini ファイルからインスパイアされています。ユニットファイルは複数の場所に配置されます (配置場所のリストを確認するには systemctl show --property=UnitPath を実行してください)。優先度が低い方から説明すると:

  • /usr/lib/systemd/system/: インストールしたパッケージに含まれているユニット
  • /etc/systemd/system/: システムの管理者がインストールしたユニット
ノート:
  • ユーザーモードsystemd を動作させたときにロードされるパスは完全に異なります。
  • systemd ユニットの名前に使うことができるのは ASCII 英数字とアンダーバー、ピリオドだけです。他の文字列は "\x2d" エスケープに置き換える必要があります。詳しくは systemd.unit(5)systemd-escape(1) を見て下さい。

依存関係を解決する

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

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

タイプ

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

  • Type=simple (デフォルト): systemd はプロセスを起動した時点でサービスが立ち上がったとみなします。プロセスをフォークすることはできません。ソケットアクティベーション以外で他のサービスが必要な場合に、このタイプを使ってはいけません。
  • Type=forking: 起動したプロセスが一旦フォークし、親プロセス側が終了したときに、 systemd はサービスが立ち上がったとみなします。このタイプでなくてもかまわないとき以外は、古典的なデーモンにはこのタイプを使って下さい。また PIDFile= を指定することで systemd はメインプロセスの情報を追い続けます。
  • Type=oneshot: シングルジョブを行い終了するスクリプト用のタイプです。また RemainAfterExit=yes を設定することで systemd はプロセスが終了した後もサービスがアクティブだとみなします。
  • Type=notify: Type=simple と同じですが、利用可能になったときにデーモンが systemd に信号を送るように条件がつけられます。この通知のリファレンス実装は libsystemd-daemon.so によって提供されています。
  • Type=dbus: 指定の BusName が DBus のシステムバスに乗ったときに使うことができるサービス。
  • Type=idle: idle の挙動は Type=simple と非常に似ています。ただし、サービスバイナリの実行は全てのジョブが処理されるまで待たされます。これを使えば、コンソールに状態を出力するシェルサービスで、出力が混じってしまうのを避けることができます。

ユニットファイルの編集

パッケージに入っているユニットファイルを編集する方法は2つあります: 新しいユニットファイルで完全に置き換えるか、ドロップインファイルを作成して既存のユニットファイルに上書きして適用させるかです。どちらの方法でも、変更を加えた後はユニットをリロードする必要があります。systemctl edit でユニットを編集するか (自動でユニットがリロードされます) または次のコマンドで全てのユニットをリロードしてください:

# systemctl daemon-reload
ヒント:
  • systemd-delta を使うことでどのファイルが上書きされ、どこが変更されたのか調べることができます。
  • ユニットファイルや関連するドロップインファイルの中身を見るには systemctl cat unit を使います。
  • 公式リポジトリから vim-systemdAUR をインストールすることで、Vimsystemd ユニットファイルのシンタックスハイライトが可能です。

ユニットファイルを置換する

ユニットファイル /usr/lib/systemd/system/unit を置き換えたいときは、/etc/systemd/system/unit ファイルを作成してユニットを再有効することでシンボリックリンクをアップデートします:

# systemctl reenable unit

もしくは、次を実行:

# systemctl edit --full unit

このコマンドはテキストエディタで /etc/systemd/system/unit を開いて (ファイルが存在しない場合はインストールされているユニットがコピーされます)、編集を終えた時に自動的にユニットをリロードします。

ノート: Pacman は元のユニットファイルが更新されても置き換えられたユニットファイルをアップデートしません。そのため、この方法ではシステムメンテナンスが多少厄介になります。この理由があるために、次のセクションで説明する方法の方が推奨されます。

ドロップインファイル

ユニットファイル /usr/lib/systemd/system/unit のドロップインファイルを作成するには、/etc/systemd/system/unit.d/ という名のディレクトリ (例: /etc/systemd/system/httpd.service.d/) を作成してその中に *.conf を配置します。このファイルを使ってオプションを上書きしたり追加してください。systemd*.conf ファイルをパースして元のユニットファイルの一番上に設定を適用します。

ドロップインファイルを作成する一番簡単な方法は次のコマンドを実行することです:

# systemctl edit unit

テキストエディタで /etc/systemd/system/unit.d/override.conf ファイルが開かれ (必要であればファイルが作成されます)、編集を終えた時に自動でユニットがリロードされます。

初期状態にリバート

systemctl edit を使って変更したユニットを元に戻したい場合、以下のコマンドを実行:

# systemctl revert unit

サンプル

例えば、ユニットに依存するデーモンを追加したい場合、以下のファイルを作成することができます:

/etc/systemd/system/<unit>.d/customdependency.conf
[Unit]
Requires=<new dependency>
After=<new dependency>

oneshot タイプでないユニットの ExecStart ディレクティブを置き換えるには、以下のファイルを作成します:

/etc/systemd/system/unit.d/customexec.conf
[Service]
ExecStart=
ExecStart=new command
ノート: ExecStart は置き換える前に空白にする必要があるので注意してください ([1])。タイマーの OnCalendar など複数回指定できるアイテムも同じです。

サービスが自動的に再起動されるようにするには:

/etc/systemd/system/unit.d/restart.conf
[Service]
Restart=always
RestartSec=30

ターゲット

Systemd ではランレベルに似たものとしてターゲットを使っています。ただしその挙動には少し違いがあります。それぞれのターゲットはナンバリングされる代わりに名前がつけられ、ある特定の目的のために作られ、複数のターゲットを同時に有効にできるようになっています。ターゲットによっては、他のターゲットのサービスを全て引継ぎ、そこにサービスを追加するよう実装されています。一般的な SystemVinit ランレベルに擬態する systemd ターゲットもあり、親しみのある telinit RUNLEVEL コマンドを使って使用するターゲットを切り替えることが可能です。

現在のターゲットを獲得

systemd では runlevel の代わりに次のコマンドが使われます:

$ systemctl list-units --type=target

カスタムターゲットを作る

標準の Fedora インストールではランレベルごとに特定の目的が設定されています; 0, 1, 3, 5, 6 のランレベルには特定の sytemd ターゲットと一対一の対応関係が存在します。残念ながら、ユーザー定義のランレベル (2 や 4 など) で同じことをする良い方法はありません。もしあなたがそうしたいならば、既に存在しているランレベルをベースに新しい systemd ターゲット/etc/systemd/system/<your target> として作り (/usr/lib/systemd/system/graphical.target がサンプルになるかもしれません)、/etc/systemd/system/<your target>.wants ディレクトリを作って、有効にしたいサービスに /usr/lib/systemd/system/ からシンボリックリンクを貼ることが示唆されています。

SysV ランレベルと systemd ターゲットの対応表

SysV ランレベル systemd ターゲット 説明
0 runlevel0.target, poweroff.target システムを停止。
1, s, single runlevel1.target, rescue.target シングルユーザーモード。
2, 4 runlevel2.target, runlevel4.target, multi-user.target ユーザー定義・サイト指定ランレベル。デフォルトでは、3 と同一。
3 runlevel3.target, multi-user.target マルチユーザー、非グラフィカル。一般的にマルチコンソールやネットワークを介してログインするのに使われます。
5 runlevel5.target, graphical.target マルチユーザー、グラフィカル。通常、ランレベル 3 の全てのサービスにグラフィカルログインを付加。
6 runlevel6.target, reboot.target 再起動
emergency emergency.target 緊急シェル

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

systemd ではターゲットは"ターゲットユニット"を通して扱うことができます。ターゲットを変えるには次のようにします:

# systemctl isolate graphical.target

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

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

標準のターゲットは default.target で、これは graphical.target へのシンボリックリンクです。これは、古いランレベル5にほぼ対応します。

systemctl を使用して現在のターゲットを確認するには、次の手順に従います。

$ systemctl get-default

ブート先のデフォルトターゲットを変更するには、default.target シンボリックリンクを変更します。systemctl の場合

# systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

または、次の カーネルパラメータ のいずれかをブートローダに追加します。

  • systemd.unit=multi-user.target (これは、古いランレベル3にほぼ対応しています)
  • systemd.unit=rescue.target (これは、古いランレベル1にほぼ対応しています)

デフォルトのターゲット順序

systemd は、次の順序に従って default.target を選択します。

  1. 上記のカーネルパラメータ
  2. /etc/systemd/system/default.target への Symlink
  3. /usr/lib/systemd/system/default.target への Symlink

一時ファイル

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 ページを参照してください。

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

タイマー

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

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

マウント

systemd は System V init を置き換えるため、/etc/fstab に指定されたマウントも処理します。起動時、またはシステムマネージャの設定の再読込時に systemd-fstab-generator(8) によって /etc/fstab のエントリが systemd ユニットに変換されます。

fstab の通常機能だけでなく、x-systemd. が前に付く特殊なマウントオプションを利用することが可能です。拡張機能を使用する具体的な例として Fstab#systemd による自動マウントには必要に応じて自動マウントする方法が書かれています。拡張機能のドキュメントは [2] を参照してください。

Journal

systemd/ジャーナルを見てください。

ヒントとテクニック

インストールされたユニットをデフォルトで有効にする

Arch Linux の /usr/lib/systemd/system-preset/99-default.preset には disable * と記述されています。systemctl プリセットがデフォルトで全てのユニットを無効化するようになり、新しいパッケージがインストールされたときも、ユーザーが手動でユニットを有効化する必要があります。

自動的に有効化させたい場合、/etc/systemd/system-preset/99-default.preset から /dev/null にシンボリックリンクを作成して設定ファイルを上書きしてください。systemctl プリセットの設定ディレクトリで指定しないかぎり、インストールされた全てのユニットが有効化されるようになります。詳しくは systemd.preset(5) の man ページを参照。

ノート: デフォルトで全てのユニットを有効化すると、パッケージに(互いに両立しない)複数のユニットが含まれている場合に問題が生じます。systemctl プリセットはディストリビューションやシステム管理者によって使われることを意図されて作られています。衝突するユニットが有効化されてしまう場合、systemd.preset の man ページに書かれているように、プリセットの設定ファイルを使ってどちらか片方を明示的に無効化させる必要があります。

アプリケーション環境のサンドボックス化

ユニットファイルをサンドボックスとして作成して堅牢な仮想環境にアプリケーションやプロセスを分離させることが可能です。systemd は名前空間ケイパビリティのホワイトリスト・ブラックリスト、Cgroups を活用して 実行環境を設定 しプロセスをコンテナ化します。

既存の systemd ユニットファイルを使ってアプリケーションをサンドボックス化するには strace, stderr, journalctl などでエラーや出力を確認しながら試行錯誤が必要です。まずは上流のドキュメントを検索して先例がないか確認すると良いでしょう。

CapabilityBoundingSet では許可されるケイパビリティのホワイトリストを定義できますが、特定のケイパビリティをブラックリストに追加する用途で使うこともできます。例: CapabilityBoundingSet=~ CAP_SYS_ADMIN

トラブルシューティング

systemd のエラーを調査する

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

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

$ systemctl --state=failed
systemd-modules-load.service  loaded failed failed  Load Kernel Modules

もしくは systemd のライブログメッセージを確認します:

$ journalctl -fp err

2. Ok, systemd-modules-load サービスに問題が発生していることがわかりました。詳しく見てみましょう:

$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago
     Docs: man:systemd-modules-load.service(8).
           man:modules-load.d(5)
  Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)

Process ID が載っていない場合は、systemctl restart systemd-modules-load で失敗したサービスを再実行してください。

3. エラーを細かく調べるためのプロセス ID (PID) を入手しました。Process ID を使って (ここでは: 15630) 以下のコマンドを実行してください:

$ journalctl _PID=15630
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. --
Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp'
Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'

4. カーネルモジュールに間違った設定がなされているようです。よって /etc/modules-load.d/ 下の設定を見てみましょう:

$ ls -Al /etc/modules-load.d/
...
-rw-r--r--   1 root root    79  1. Dez 2012  blacklist.conf
-rw-r--r--   1 root root     1  2. Mär 14:30 encrypt.conf
-rw-r--r--   1 root root     3  5. Dez 2012  printing.conf
-rw-r--r--   1 root root     6 14. Jul 11:01 realtek.conf
-rw-r--r--   1 root root    65  2. Jun 23:01 virtualbox.conf
...

5. エラーメッセージ Failed to find module 'blacklist usblp' はおそらく blacklist.conf 内に間違った設定があることを示しています。手順 3 で見つけたオプションの前に # を挿入して無効化してみましょう:

/etc/modules-load.d/blacklist.conf
# blacklist usblp
# install usblp /bin/false

6. では、systemd-modules-load を起動してみることにします:

$ systemctl start systemd-modules-load

成功した場合、何も表示されないはずです。何かエラーが表示される場合は、手順 3 に戻って下さい。そして新しい PID を使って残った問題を解決してください。

全て問題ないならば、サービスが正しく起動したか次のコマンドで確認することができます:

$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
 Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.

この種の問題は上のように解決できます。より詳しい調査をする場合は次のブート問題の診断を見て下さい。

ブート問題の診断

カーネルコマンドラインに次のパラメータをつけて起動してください: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

詳しくはブートデバッグ[3] を見て下さい。

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

ある systemd サービスが上手く動作せず、どうなっているのか詳しい情報が欲しい場合、環境変数 SYSTEMD_LOG_LEVELdebug に設定してください。以下は systemd-networkd デーモンをデバッグモードで動かす例です:

# systemctl stop systemd-networkd
# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

もしくは同じようにサービスファイルを修正してください:

/lib/systemd/system/systemd-networkd.service
[Service]
...
Environment=SYSTEMD_LOG_LEVEL=debug
....

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

シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。Systemd はサービスを kill する前に終了するのを待ちます。なにが原因か知るには この記事 を見て下さい。

短いプロセスがログを出力しない

journalctl -u foounit.service が短いプロセスについてなにも表示しない場合、かわりに PID を見て下さい。例えば、systemd-modules-load.service が失敗したとき、systemctl status systemd-modules-load によってそれが PID 123 として動いているとわかったら、その PID の journal の出力を見ることができます、journalctl -b _PID=123。journal の _SYSTEMD_UNIT_COMM などのメタデータは非同期に収集され /proc ディレクトリにプロセスが存在している時だけ表示されます。これを修正するには、SCM_CREDENTIALS のように、ソケット接続を使ってデータを流すようカーネルを変更する必要があります。

クラッシュしたアプリケーションのダンプのジャーナルを無効にする

/etc/systemd/coredump.conf ファイルを編集して次の行を追加してください:

Storage=none

そして設定をリロードしてください:

# systemctl daemon-reload

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

cgroup : option or name mismatch, new: 0x0 "", old: 0x4 "systemd"

この警告は kernel/cgroup.c のカーネルコードから来ています:

       /* Don't allow flags or name to change at remount */
       if (((opts.flags ^ root->flags) & CGRP_ROOT_OPTION_MASK) ||
           (opts.name && strcmp(opts.name, root->name))) {
               pr_err("option or name mismatch, new: 0x%x \"%s\", old: 0x%x \"%s\"\n",
                      opts.flags & CGRP_ROOT_OPTION_MASK, opts.name ?: "",
                      root->flags & CGRP_ROOT_OPTION_MASK, root->name);
               ret = -EINVAL;
               goto out_unlock;
       }

つまり、何かが cgroups を別の名前で再マウントしようとしてカーネルがそれに抵抗しているというわけです。ローカルの設定ファイルのエラーではなく、エラーメッセージ以外には何も症状が現れません。これが systemd のバグなのか、Arch の systemd パッケージに問題があるのかは判っていません [4]。2014年11月現在、Arch の systemd パッケージにバグレポートは送られていないようです。

watchdog watchdog0: watchdog did not stop!

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

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

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

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

起動時に systemd-tmpfiles-setup.service の実行に失敗する

systemd 219 から、/usr/lib/tmpfiles.d/systemd.conf/var/log/journal 下のディレクトリに対して ACL 属性を指定しており、それによって、ジャーナルが存在するファイルシステムで ACL のサポートを有効にしなくてはならなくなっています。

/var/log/journal が存在するファイルシステムで ACL を有効化する方法はアクセス制御リスト#ACL の有効化を見て下さい。

systemctl enable で /etc/systemd/system にシンボリックリンクが作成されない

/etc/systemd/system/foo.service がシンボリックリンクの場合、systemctl enable foo.service を実行しても以下のエラーで失敗します:

Failed to issue method call: No such file or directory

これは systemd の 仕様 です。絶対パスで有効にすることで回避できます:

# systemctl enable /absolute/path/foo.service

起動時に表示される systemd のバージョンがインストールしているパッケージのバージョンと違う

initramfs を再生成することでバージョンが一致するようになるはずです。

ヒント: systemd がアップグレードされると自動的に initramfs が生成されるように pacman フックを設定することができます。フォーラムスレッドPacman#フックを見てください。

リモートマシンで緊急モードを無効化

リモートマシン (例えば Azure や Google Cloud でホストしている仮想マシン) の緊急モードは無効化すると良いでしょう。緊急モードが起動すると、ネットワークからマシンに接続できなくなってしまうからです。無効化するには以下のコマンドを実行:

# systemctl mask emergency.service
# systemctl mask emergency.target

参照