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

From ArchWiki
Jump to: navigation, search
m (ACPI 電源管理)
Line 10: Line 10:
 
[[ru:Systemd]]
 
[[ru:Systemd]]
 
[[zh-CN:Systemd]]
 
[[zh-CN:Systemd]]
{{Article summary start|概括}}
+
{{Related articles start (日本語)}}
{{Article summary text|systemd をインストールし、設定する方法についての文書です。}}
+
{{Related|systemd/User}}
{{Article summary heading|関連項目}}
+
{{Related|systemd/Services}}
{{Article summary wiki|systemd/User}}
+
{{Related|systemd/cron functionality}}
{{Article summary wiki|systemd/Services}}
+
{{Related2|systemd FAQ (日本語)|systemd FAQ}}
{{Article summary wiki|systemd/cron functionality}}
+
{{Related2|init Rosetta (日本語)|init Rosetta}}
{{Article summary wiki|systemd FAQ (日本語)}}
+
{{Related2|Daemons List (日本語)|デーモン一覧}}
{{Article summary wiki|init Rosetta (日本語)}}
+
{{Related2|udev (日本語)|udev}}
{{Article summary wiki|Daemons List (日本語)}}
+
{{Related2|Improve Boot Performance (日本語)|ブートパフォーマンスの向上}}
{{Article summary wiki|udev (日本語)}}
+
{{Related articles end}}
{{Article summary wiki|Improve Boot Performance (日本語)}}
+
 
{{Article summary end}}
+
[http://freedesktop.org/wiki/Software/systemd プロジェクトウェブページ] より:
[http://freedesktop.org/wiki/Software/systemd project web page] より:
+
  
 
:'''systemd''' は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。'''systemd''' はサービスの起動を積極的に並行化します。また、サービス起動時にソケットと [[D-Bus (日本語)|D-Bus]] を有効化し、必要なサービスの開始と Linux の [[cgroups]] によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動)マウントポイントの維持、依存に基づいたサービスのコントロールをサポートします。
 
:'''systemd''' は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。'''systemd''' はサービスの起動を積極的に並行化します。また、サービス起動時にソケットと [[D-Bus (日本語)|D-Bus]] を有効化し、必要なサービスの開始と Linux の [[cgroups]] によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動)マウントポイントの維持、依存に基づいたサービスのコントロールをサポートします。
Line 278: Line 277:
 
古い設定ファイル {{ic|/etc/timezone}} がある場合、削除しても問題ありません。
 
古い設定ファイル {{ic|/etc/timezone}} がある場合、削除しても問題ありません。
  
=== カーネルモジュール ===
+
=== ファイルシステムのマウント ===
 
+
現在、すべての必要なカーネルモジュールは [[udev (日本語)|udev]] によって自動でロードされます。従って、サポート外のカーネルモジュールを使おうとしない限り、設定ファイルにモジュールをロードするように書く必要はありません。しかし、ブートプロセスでモジュールをロードしたい場合や、コンピュータを正しく機能させるためにモジュールをブラックリストに加える必要があるかもしれません。
+
 
+
==== 起動時にモジュールをロード ====
+
 
+
{{ic|/etc/modules-load.d/}} 下のファイルに、ブート時に読み込むカーネルモジュールを設定します。それぞれの設定ファイルは {{ic|/etc/modules-load.d/<program>.conf}} という名前です。設定ファイルには単純にロードすべきカーネルモジュールを一行毎に並べます。空の行や、スペース以外の最初の文字が {{ic|#}} や {{ic|;}} の行は無視されます。
+
 
+
{{hc|/etc/modules-load.d/virtio-net.conf|
+
# Load virtio-net.ko at boot
+
virtio-net}}
+
 
+
詳しくは {{ic|man 5 modules-load.d}} を見て下さい。
+
 
+
==== モジュールオプションの設定 ====
+
 
+
追加モジュールオプションは {{ic|/etc/modprobe.d/modprobe.conf}} に設定する必要があります。
+
 
+
例:
+
* ブート中にロードするために {{ic|loop}} モジュールには {{ic|/etc/modules-load.d/loop.conf}} があります。
+
* {{ic|/etc/modprobe.d/modprobe.conf}} には追加のオプションを指定します、例えば {{ic|options loop max_loop&#61;64}}
+
 
+
その後、新しく設定したオプションは {{ic|cat /sys/module/loop/parameters/max_loop}} によって確認することができます。
+
 
+
==== ブラックリスト ====
+
モジュールのブラックリストは、{{Pkg|kmod}} によって扱われるので、{{Pkg|initscripts}} の時と同じ方法で動作します。詳細は [[Kernel modules (日本語)#ブラックリスト|Module Blacklisting]] にあります。
+
 
+
=== ファイルシステムをマウントする ===
+
  
 
デフォルトのセットアップでは自動的に fsck が行われサービスが起動する前にファイルシステムがマウントされます。例えば、systemd は [[NFS]] や [[Samba (日本語)|Samba]] のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って {{ic|/etc/fstab}} に明記しなくともローカル・リモードどちらのファイルシステムのマウントも問題ありません。
 
デフォルトのセットアップでは自動的に fsck が行われサービスが起動する前にファイルシステムがマウントされます。例えば、systemd は [[NFS]] や [[Samba (日本語)|Samba]] のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って {{ic|/etc/fstab}} に明記しなくともローカル・リモードどちらのファイルシステムのマウントも問題ありません。
Line 327: Line 299:
 
{{hc|/etc/crypttab|
 
{{hc|/etc/crypttab|
 
data /dev/md0 /root/key noauto}}
 
data /dev/md0 /root/key noauto}}
 
==== LVM ====
 
 
[[mkinitcpio (日本語)|initramfs]] でアクティベイトしていない LVM ボリュームがある場合、{{pkg|lvm2}} パッケージで提供されている、{{ic|lvm-monitoring}} サービスを有効にしてください:
 
 
# systemctl enable lvm-monitoring
 
 
=== ACPI 電源管理 ===
 
 
systemd は電源関連の [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] イベントを扱えます。{{ic|/etc/systemd/logind.conf}} のオプションを使って設定できます:
 
 
* {{ic|HandlePowerKey}}: パワーキーが押された時に行う動作を定めます。
 
* {{ic|HandleSuspendKey}}: サスペンドキーが押された時に行う動作を定めます。
 
* {{ic|HandleHibernateKey}}: ハイバネートキーが押された時に行う動作を定めます。
 
* {{ic|HandleLidSwitch}}: フタが閉じられた時に行う動作を定めます。
 
 
定めることができる動作は {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}}, {{ic|kexec}} のどれかです。
 
 
オプションが設定されていない時に、systemd が使うデフォルトは: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, {{ic|1=HandleLidSwitch=suspend}}。
 
 
グラフィカルセットアップを走らせていなかったり [[i3]] や [[awesome (日本語)|awesome]] などシンプルなウィンドウマネージャしか使っていないシステムでは、以前から ACPI イベントに反応するものとして使われていた [[acpid]] デーモンで置き換えることができるかもしれません。
 
 
{{Note|Systemd は AC やバッテリの ACPI イベントを取り扱うことはできません、[[Laptop Mode Tools]] などのツールを使うには、依然として [[acpid]] が必要になります。}}
 
 
現在のバージョンの systemd では、{{ic|Handle*}} オプションは(デスクトップ環境のパワーマネージャなどの)プログラムによって "inhibited" (一時的にオフ) にされない限りシステム全体に適用されます。停止されなければ、systemd がシステムをサスペンドした状態で終わることができ、立ち上がった時に他のパワーマネージャによってもう一度停止されます。
 
 
{{Warning|現在、最新の [[KDE (日本語)|KDE]] と [[GNOME (日本語)|GNOME]] の電源マネージャは "inhibited" コマンドを実行します。[[Xfce (日本語)|Xfce]] や、[[acpid]] など他のプログラムで ACPI イベントを管理したい場合は、{{ic|Handle}} オプションを {{ic|ignore}} に設定する必要があります。開発中の新しいバージョンではこの機能が含まれる予定です。}}
 
 
{{Note|デフォルトの''カーネル''バックエンドに加え、Systemd は他のサスペンドバックエンド ([[Uswsusp]] や [[TuxOnIce]] など)を使ってコンピュータをスリープ・ハイバネート状態にすることができます。}}
 
 
{{ic|systemctl hibernate}} を使うには [[Pm-utils#Hibernation_.28suspend2disk.29|Hibernation]] や [[Pm-utils#Mkinitcpio_Resume_Hook|Mkinitcpio Resume Hook]] ({{ic|pm-utils}} をインストールする必要はありません) の指示に従う必要があります。
 
 
==== Sleep フック ====
 
 
{{ic|systemctl suspend}}, {{ic|systemctl hibernate}}, {{ic|systemctl hybrid-sleep}} が実行された時、Systemd はマシンをスリープ状態にするのに [[pm-utils]] を使いません; [[Pm-utils#Creating_your_own_hooks|カスタムフック]]を含む、[[pm-utils]] フックは実行されません。ただし、こうしたイベントでカスタムスクリプトを動かすために systemd は2つの似た機構を提供しています。
 
 
===== サスペンド/リジューム サービスファイル =====
 
 
サービスファイルを suspend.target, hibernate.target, sleep.target にフックすることでサスペンド・ハイバネート前後に行うアクションを設定できます。ユーザー・システムアクションを行うにはファイルを分割する必要があります。ユーザーサービスファイルを作動させるには、{{ic|# systemctl enable suspend@<user> && systemctl enable resume@<user>}}。例:
 
 
{{hc|/etc/systemd/system/suspend@.service|2=<nowiki>
 
[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</nowiki>}}
 
 
{{hc|/etc/systemd/system/resume@.service|2=<nowiki>
 
[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</nowiki>}}
 
 
root アクションでは ({{ic|# systemctl enable root-suspend}} でアクティベイト):
 
 
{{hc|/etc/systemd/system/root-resume.service|2=<nowiki>
 
[Unit]
 
Description=Local system resume actions
 
After=suspend.target
 
 
[Service]
 
Type=simple
 
ExecStart=/usr/bin/systemctl restart mnt-media.automount
 
 
[Install]
 
WantedBy=suspend.target</nowiki>}}
 
 
{{hc|/etc/systemd/system/root-suspend.service|2=<nowiki>
 
[Unit]
 
Description=Local system suspend actions
 
Before=sleep.target
 
 
[Service]
 
Type=simple
 
ExecStart=-/usr/bin/pkill sshfs
 
 
[Install]
 
WantedBy=sleep.target</nowiki>}}
 
 
サービスファイルについてのヒント(詳しくは {{ic|man systemd.service}}):
 
* {{ic|1=<nowiki>Type=OneShot</nowiki>}} の場合、複数の {{ic|1=<nowiki>ExecStart=</nowiki>}} 行を使うことができます。それ以外の場合は使える ExecStart は一行だけです。{{ic|ExecStartPre}} を使ったりコマンドをセミコロンで分割することでコマンドを追加することができます(最初の例を見て下さい -- セミコロンの前後にはスペースが必要です)。
 
* コマンドの前に '-' を付けるとエラーが起こっても(終了ステータスが0以外でも)無視され、コマンドは成功したとして扱われます。
 
* サービスファイルのトラブルシューティングのときにエラーを見つけるには {{ic|journalctl}} を使うのがベストです。
 
 
===== サスペンド/レジューム サービスファイルの統合 =====
 
 
サスペンド/レジューム サービスファイルを統合すれば、様々なフェイズ(スリープ・レジューム)やターゲット(サスペンド・ハイバネート・ハイブリッドスリープ)でやることをひとつのフックで行うことができます。
 
 
例と説明:
 
 
{{hc|/etc/systemd/system/wicd-sleep.service|2=<nowiki>
 
[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</nowiki>}}
 
 
* {{ic|1=<nowiki>RemainAfterExit=yes</nowiki>}}: 起動後、明示的に止められるまでサービスは常時 active になります。
 
* {{ic|1=<nowiki>StopWhenUnneeded=yes</nowiki>}}: active のとき、サービスは sleep.target が停止した後に止められます。
 
* Because sleep.target は suspend.target, hibernate.target, hybrid-sleep.target から呼ばれ sleep.target 自身は StopWhenUnneeded サービスなので、タスクごとにフックが正しく起動・停止することが保証されています。
 
 
===== /usr/lib/systemd/system-sleep のフック =====
 
 
Systemd は {{ic|/usr/lib/systemd/system-sleep/}} 内の全ての実行可能ファイルを実行するときに、2つの引数を渡します:
 
 
* 引数 1: {{ic|pre}} か {{ic|post}}。マシンが停止するときと起動するとき。
 
* 引数 2: {{ic|suspend}} か {{ic|hibernate}} か {{ic|hybrid-sleep}}。呼び出されるものによる。
 
 
[[pm-utils]] とは対照的に、systemd はスクリプトを(一つずつではなく)同時に実行します。
 
 
カスタムスクリプトの出力は {{ic|systemd-suspend.service}}, {{ic|systemd-hibernate.service}}, {{ic|systemd-hybrid-sleep.service}} によって記録されます。出力を見るには systemd の [[#Journal|journal]] を使って下さい:
 
# journalctl -b -u systemd-suspend
 
 
カスタムスクリプトを使うかわりに {{ic|sleep.target}}, {{ic|suspend.target}}, {{ic|hibernate.target}}, {{ic|hybrid-sleep.target}} を使ってユニットをスリープステートロジックにフックさせることもできます。
 
 
カスタムスリープスクリプトの例:
 
 
{{hc|/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
 
 
詳しくは {{ic|man 7 systemd.special}} や {{ic|man 8 systemd-sleep}} を見て下さい。
 
 
=== 一時ファイル ===
 
 
Systemd-tmpfiles は {{ic|/usr/lib/tmpfiles.d/}} と {{ic|/etc/tmpfiles.d/}} 下にある設定ファイルを読み、通常 {{ic|/run}} や {{ic|/tmp}} などのディレクトリに存在している一時ファイル・ディレクトリの作成、内容の消去、削除などを行います。それぞれの設定ファイル名は {{ic|/etc/tmpfiles.d/<program>.conf}} です。{{ic|/usr/lib/tmpfiles.d/}} に同名の設定ファイルがある場合上書きされます。
 
 
tmpfiles は一時ファイルを必要とするデーモンのサービスファイルに同梱されます。例えば [[Samba]] デーモンは {{ic|/run/samba}} を一時ディレクトリとして使用するため、正しいパーミッションに設定されていることを期待します。これを表す tmpfile は以下のようになります:
 
 
{{hc|/usr/lib/tmpfiles.d/samba.conf|
 
D /run/samba 0755 root root}}
 
 
tmpfiles は起動時にファイルに値を書き込むのにも使われることがあります。例えば、{{ic|/etc/rc.local}} を使って USB デバイスからの wakeup を無効化する {{ic|echo USBE > /proc/acpi/wakeup}} は、tmpfile では以下のように書けます:
 
 
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
 
w /proc/acpi/wakeup - - - - USBE}}
 
 
詳細は {{ic|systemd-tmpfiles}} や {{ic|tmpfiles.d(5)}} の man ページを参照してください。
 
 
{{Note|''systemd-tmpfiles-setup'' サービスは適切なモジュールがロードされる前に実行されることがあるので、{{ic|/sys}} にオプションを設定するのにこの方法は使えません。このため設定したいオプションのパラメータをモジュールが持っているか確認するには {{ic|modinfo ''module''}} を使い、オプションを設定は[[Modprobe.d#Configuration|/etc/modprobe.d 下の設定ファイル]]を使って下さい。もしくはデバイスが現れたときにすぐ適切な属性を設定する [[Udev (日本語)#udev ルールについて|udev ルール]]を書いて下さい。}}
 
  
 
== カスタム .service ファイルを書く ==
 
== カスタム .service ファイルを書く ==
  
systemd の[[#ユニットを使う|ユニットファイル]]の構文は XDG の Desktop Entry Specification である .desktop から影響を受けています。そして .desktop は Microsoft Windows の .ini ファイルにインスパイアされたものです。
+
systemd の[[#ユニットを使う|ユニットファイル]]の構文は XDG の Desktop Entry Specification である ''.desktop'' から影響を受けています。そして ''.desktop'' は Microsoft Windows の ''.ini'' ファイルからインスパイアされています。
  
 
もっと多くのサンプルが [[Systemd/Services]] にあります。
 
もっと多くのサンプルが [[Systemd/Services]] にあります。
Line 624: Line 422:
  
 
があるときだけこれが動作します。現在、{{ic|multi-user.target}} と {{ic|graphical.target}} がこれを持っています。
 
があるときだけこれが動作します。現在、{{ic|multi-user.target}} と {{ic|graphical.target}} がこれを持っています。
 +
 +
== 一時ファイル ==
 +
 +
Systemd-tmpfiles は {{ic|/usr/lib/tmpfiles.d/}} と {{ic|/etc/tmpfiles.d/}} 下にある設定ファイルを読み、通常 {{ic|/run}} や {{ic|/tmp}} などのディレクトリに存在している一時ファイル・ディレクトリの作成、内容の消去、削除などを行います。それぞれの設定ファイル名は {{ic|/etc/tmpfiles.d/<program>.conf}} です。{{ic|/usr/lib/tmpfiles.d/}} に同名の設定ファイルがある場合上書きされます。
 +
 +
tmpfiles は一時ファイルを必要とするデーモンのサービスファイルに同梱されます。例えば [[Samba]] デーモンは {{ic|/run/samba}} を一時ディレクトリとして使用するため、正しいパーミッションに設定されていることを期待します。これを表す tmpfile は以下のようになります:
 +
 +
{{hc|/usr/lib/tmpfiles.d/samba.conf|
 +
D /run/samba 0755 root root}}
 +
 +
tmpfiles は起動時にファイルに値を書き込むのにも使われることがあります。例えば、{{ic|/etc/rc.local}} を使って USB デバイスからの wakeup を無効化する {{ic|echo USBE > /proc/acpi/wakeup}} は、tmpfile では以下のように書けます:
 +
 +
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
 +
w /proc/acpi/wakeup - - - - USBE}}
 +
 +
詳細は {{ic|systemd-tmpfiles}} や {{ic|tmpfiles.d(5)}} の man ページを参照してください。
 +
 +
{{Note|''systemd-tmpfiles-setup'' サービスは適切なモジュールがロードされる前に実行されることがあるので、{{ic|/sys}} にオプションを設定するのにこの方法は使えません。このため設定したいオプションのパラメータをモジュールが持っているか確認するには {{ic|modinfo ''module''}} を使い、オプションを設定は[[Modprobe.d#Configuration|/etc/modprobe.d 下の設定ファイル]]を使って下さい。もしくはデバイスが現れたときにすぐ適切な属性を設定する [[Udev (日本語)#udev ルールについて|udev ルール]]を書いて下さい。}}
  
 
== タイマー ==
 
== タイマー ==
Line 642: Line 458:
 
=== フィルタリング ===
 
=== フィルタリング ===
  
{{ic|journalctl}} を使って出力にフィルタをかけることができます。
+
{{ic|journalctl}} を使って出力にフィルタをかけることができます。表示したりフィルタリングをするメッセージが大量にある場合、かなり時間がかかります。コマンドの出力は相当の時間がたってから表示されるかもしれません。
  
 
例:
 
例:
Line 650: Line 466:
 
  # journalctl -b
 
  # journalctl -b
  
{{note|{{ic|journalctl -b}} {{ic|-0}} (最後のブート) と引数を付けられます。例えば {{ic|journalctl -b -3}} とすれば4番目から最後のブートまでの全てのメッセージが表示されます。}}
+
場合によっては最新のブートメッセージではなく、以前のブートのメッセージを読みたいことがあります (例えば復旧できないシステムクラッシュが起こった場合)。{{ic|-b}} フラグに任意のパラメータを付けることでメッセージをオフセットして読むことが可能です: {{ic|journalctl -b -0}} は最新のブートのメッセージを、{{ic|journalctl -b -1}} は一つ前のブートのメッセージを表示し {{ic|journalctl -b -2}} は二つ前、と続きます。詳しくは {{ic|man 1 journalctl}} を見て下さい、セマンティックスはより強力です。
  
 
新しいメッセージを表示:
 
新しいメッセージを表示:
Line 687: Line 503:
  
 
  # systemctl enable syslog-ng
 
  # systemctl enable syslog-ng
 +
 +
=== journald を /dev/tty12 に転送する ===
 +
 +
{{ic|/etc/systemd/journald.conf}} で以下を有効にしてください:
 +
 +
ForwardToConsole=yes
 +
TTYPath=/dev/tty12
 +
MaxLevelConsole=info
 +
 +
{{ic|sudo systemctl restart systemd-journald}} を実行して journald を再起動してください。
  
 
== トラブルシューティング ==
 
== トラブルシューティング ==
Line 695: Line 521:
  
 
1. 起動に失敗している systemd サービスを探しましょう:
 
1. 起動に失敗している systemd サービスを探しましょう:
$ systemctl | grep -i failed
+
{{hc|1=$ systemctl --state=failed|2=
systemd-modules-load.service  loaded '''failed failed'''  Load Kernel Modules
+
systemd-modules-load.service  loaded '''failed failed'''  Load Kernel Modules
 +
}}
  
 
2. Ok, {{ic|systemd-modules-load}} サービスに問題が発生していることがわかりました。詳しく見てみましょう:
 
2. Ok, {{ic|systemd-modules-load}} サービスに問題が発生していることがわかりました。詳しく見てみましょう:
$ systemctl status systemd-modules-load
+
{{hc|$ systemctl status systemd-modules-load|2=
systemd-modules-load.service - Load Kernel Modules
+
systemd-modules-load.service - Load Kernel Modules
    Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
+
  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
+
  Active: '''failed''' (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago
      Docs: man:systemd-modules-load.service(8).
+
    Docs: man:systemd-modules-load.service(8).
            man:modules-load.d(5)
+
          man:modules-load.d(5)
  Process: '''15630''' ExecStart=/usr/lib/systemd/systemd-modules-load ('''code=exited, status=1/FAILURE''')
+
  Process: '''15630''' ExecStart=/usr/lib/systemd/systemd-modules-load ('''code=exited, status=1/FAILURE''')
 +
}}
  
 
3. エラーを細かく調べるためのプロセス ID (PID) を入手しました。{{ic|Process ID}} を使って (ここでは: 15630) 以下のコマンドを実行してください:
 
3. エラーを細かく調べるためのプロセス ID (PID) を入手しました。{{ic|Process ID}} を使って (ここでは: 15630) 以下のコマンドを実行してください:
$ journalctl -b _PID=15630
+
{{hc|1=$ journalctl -b _PID=15630|2=
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. --
+
-- 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 'blacklist usblp''''
Aug 25 11:48:13 mypc systemd-modules-load[15630]: '''Failed to find module 'install usblp /bin/false''''  
+
Aug 25 11:48:13 mypc systemd-modules-load[15630]: '''Failed to find module 'install usblp /bin/false''''  
 +
}}
  
 
4. カーネルモジュールに間違った設定がなされているようです。よって {{ic|/etc/modules-load.d/}} 下の設定を見てみましょう:
 
4. カーネルモジュールに間違った設定がなされているようです。よって {{ic|/etc/modules-load.d/}} 下の設定を見てみましょう:
$ ls -al /etc/modules-load.d/
+
{{hc|$ ls -Al /etc/modules-load.d/|
total 44
+
...
drwxr-xr-x  2 root root  4096 14. Jul 11:01 .
+
-rw-r--r--  1 root root    79  1. Dez 2012  blacklist.conf
drwxr-xr-x 114 root root 12288 25. Aug 11:40 ..
+
-rw-r--r--  1 root root    1  2. Mär 14:30 encrypt.conf
-rw-r--r--  1 root root    79  1. Dez 2012  blacklist.conf
+
-rw-r--r--  1 root root    3  5. Dez 2012  printing.conf
-rw-r--r--  1 root root    1  2. Mär 14:30 encrypt.conf
+
-rw-r--r--  1 root root    6 14. Jul 11:01 realtek.conf
-rw-r--r--  1 root root    3  5. Dez 2012  printing.conf
+
-rw-r--r--  1 root root    65  2. Jun 23:01 virtualbox.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. エラーメッセージ {{ic|Failed to find module 'blacklist usblp'}} はおそらく {{ic|blacklist.conf}} 内に間違った設定があることを示しています。手順 3 で見つけたオプションの前に '''#''' を挿入して無効化してみましょう:
 
5. エラーメッセージ {{ic|Failed to find module 'blacklist usblp'}} はおそらく {{ic|blacklist.conf}} 内に間違った設定があることを示しています。手順 3 で見つけたオプションの前に '''#''' を挿入して無効化してみましょう:
$ nano /etc/modules-load.d/blacklist.conf
+
{{hc|/etc/modules-load.d/blacklist.conf|
'''#''' blacklist usblp
+
'''#''' blacklist usblp
'''#''' install usblp /bin/false
+
'''#''' install usblp /bin/false
 +
}}
  
 
6. では、{{ic|systemd-modules-load}} を起動してみることにします:
 
6. では、{{ic|systemd-modules-load}} を起動してみることにします:
Line 734: Line 564:
  
 
全て問題ないならば、サービスが正しく起動したか次のコマンドで確認することができます:
 
全て問題ないならば、サービスが正しく起動したか次のコマンドで確認することができます:
$ systemctl status systemd-modules-load
+
{{hc|$ systemctl status systemd-modules-load|2=
systemd-modules-load.service - Load Kernel Modules
+
systemd-modules-load.service - Load Kernel Modules
 
   Loaded: '''loaded''' (/usr/lib/systemd/system/systemd-modules-load.service; static)
 
   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
 
   Active: '''active (exited)''' since So 2013-08-25 12:22:31 CEST; 34s ago
 
     Docs: man:systemd-modules-load.service(8)
 
     Docs: man:systemd-modules-load.service(8)
 
           man:modules-load.d(5)
 
           man:modules-load.d(5)
  Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
+
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'''.
+
Aug 25 12:22:31 mypc systemd[1]: '''Started Load Kernel Modules'''.
 +
}}
  
この種の問題は上のように解決できます。より詳しい調査をする場合は次の"'''ブート問題の診断'''"を見て下さい。
+
この種の問題は上のように解決できます。より詳しい調査をする場合は次の[[#ブート問題の診断|ブート問題の診断]]を見て下さい。
  
 
=== ブート問題の診断 ===
 
=== ブート問題の診断 ===

Revision as of 15:34, 27 November 2013

Template:Related articles start (日本語)

  • systemd/User
  • systemd/Services
  • systemd/cron functionality
  • systemd FAQ
  • init Rosetta
  • デーモン一覧
  • udev
  • ブートパフォーマンスの向上
  • </ul></div>

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

    systemd は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、サービス起動時にソケットと D-Bus を有効化し、必要なサービスの開始と Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動)マウントポイントの維持、依存に基づいたサービスのコントロールをサポートします。
    Note: systemd が Arch に採用された理由については、フォーラムへのこの投稿をご覧ください。

    SysVinit/initscripts からの移行

    Note:

    移行前に考慮すべきこと

    • 本家のホームページ で、systemd についてざっと読んでください。
    • systemd の journal システムは、syslog を置き換えることができますが、この2つは共存できます。#Journal を見て下さい。
    • systemd は cronacpidxinetd の機能の一部を代替できますが、あなたが望まない限り伝統的なデーモンを使うのを止める必要はありません。
    • インタラクティブな 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/commsystemd の文字が返ってくるはずです。
    5. systemd であなたのホストネームを設定します: hostnamectl set-hostname myhostname または /etc/hostname
    6. initscriptssysvinit をシステムから削除し systemd-sysvcompat をインストールしてください。
    7. もう必要なくなった init=/usr/lib/systemd/systemd パラメータを削除してください。systemd-sysvcompat がデフォルトの init になります。

    initscripts のエミュレーション

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

    1. /etc/rc.confDAEMONS 行をパースし、ブート時にデーモンを起動します
    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.confDAEMONS 行のそれぞれの <service_name> に対して次を実行します:

    # systemctl enable <service_name>.service
    
    Tip: 一般的に使われるデーモンの initscripts と systemd の比較表がここにあります。

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

    • ほとんどの場合、systemd は違う名前を使っています。例えば、crond init デーモンは cronie.service に、alsa init デーモンは alsa-store.servicealsa-restore.service になっています。他にも network デーモンは、他のサービスファイルに置き換わっています (詳しくは Network Configuration (日本語) を見て下さい)。
    • サービスファイルが systemd にない場合。その場合、起動中にサービスを作動させるのに rc.conf を使いつづける必要があります。
    Tip: パッケージの中身を見て、どのサービス名でデーモン起動スクリプトが含まれているのか見ることができます。例:
    $ pacman -Ql cronie
    [...]
    cronie /etc/rc.d/crond                            #DAEMONS 行で使われるデーモン initscript ("純粋な" systemd では使われません)
    [...]
    cronie /usr/lib/systemd/system/cronie.service     #対応する systemd のデーモンサービス
    [...]
    
    • 最後に、サービスによっては、ユーザーの操作で有効にする必要がないものがあります。例えば、dbus.servicedbus-core がインストールされると自動で有効にされます。alsa-store.servicealsa-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 を使ってリムーバルディスクのマウントなどの操作を行います。

    systemctl の基本的な使い方

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

    Tip: systemctl コマンドに -H <user>@<host> を渡すと、リモートの systemd と対話できます。SSH を利用してリモートの systemd インスタンスに繋ぐのに使われます。
    Note: systemadmsystemctl の公式グラフィカルフロントエンドです。systemd-ui-gitAUR パッケージが AUR から入手可能です。

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

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

    $ 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 とみなします。例えば netcfgnetcfg.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>
    
    Note: サービスに [Install] セクションがない場合、大抵は他のサービスから自動的に起動されます。手動でのインストールが必要な場合、以下のコマンドを使ってください (foo をサービスの名前に置換してください)。
    # 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
    

    ネイティブの設定

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

    ホストネーム

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

    # hostnamectl set-hostname myhostname
    

    詳しくは man 5 hostnameman 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 localectlman 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 localectlman 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 は NFSSamba のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って /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 ファイルからインスパイアされています。

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

    依存関係を解決する

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

    基本的に、依存関係はターゲットではなくサービスに配置します。例えば、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 タイプでないユニットの 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 を使う方法のほうが推奨されます。

    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 ターゲット 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 3telinit 5 のようなコマンドと同じです。

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

    標準のターゲットは default.target で、デフォルトで (昔のランレベル 5 に大体対応している) graphical.target にエイリアスされています。起動時のデフォルトターゲットを変更するには、以下のカーネルパラメータのどれかをブートローダに加えてください:

    Tip: .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.targetgraphical.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-tmpfilestmpfiles.d(5) の man ページを参照してください。

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

    タイマー

    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 に書き込まれます。ただし再起動時にこのログは消失してしまいます。

    Tip: /var/log/journal/btrfs ファイルシステムに存在する場合、ディレクトリの Copy-on-Write を無効にするべきです:
    # chattr +C /var/log/journal
    

    フィルタリング

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

    例:

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

    # journalctl -b
    

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

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

    # 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.confSystemMaxUse を変更すれば、最大サイズを変更できます。例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します:

    SystemMaxUse=50M
    

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

    journald と syslog の結合

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

    # systemctl enable syslog-ng
    

    journald を /dev/tty12 に転送する

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

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

    sudo systemctl restart systemd-journald を実行して journald を再起動してください。

    トラブルシューティング

    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)

    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/
    ...
    -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.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

    More Debugging Information

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

    シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。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.dthe documentation for /proc/sys/kernel を見て下さい。

    参照