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

From ArchWiki
Jump to: navigation, search
m
m (temporary redirect)
 
(47 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Lowercase title}}
+
#redirect[[ja:Systemd]]
[[Category:Daemons and system services (日本語)]]
+
[[Category:Boot process (日本語)]]
+
[[ar:Systemd]]
+
[[en:Systemd]]
+
[[es:Systemd]]
+
[[fr:Systemd]]
+
[[it:Systemd]]
+
[[pt:Systemd]]
+
[[ru:Systemd]]
+
[[zh-CN:Systemd]]
+
{{Article summary start|概括}}
+
{{Article summary text|systemd をインストールし、設定する方法についての文書です。}}
+
{{Article summary heading|関連項目}}
+
{{Article summary wiki|systemd/User}}
+
{{Article summary wiki|systemd/Services}}
+
{{Article summary wiki|systemd/cron functionality}}
+
{{Article summary wiki|systemd FAQ (日本語)}}
+
{{Article summary wiki|init Rosetta (日本語)}}
+
{{Article summary wiki|Daemons List (日本語)}}
+
{{Article summary wiki|udev}}
+
{{Article summary wiki|Improve Boot Performance (日本語)}}
+
{{Article summary end}}
+
[http://freedesktop.org/wiki/Software/systemd project web page] より:
+
 
+
'''systemd''' は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。'''systemd''' はサービスの起動を積極的に並行化します。また、サービス起動時にソケットと [[D-Bus (日本語)|D-Bus]] を有効化し、必要なサービスの開始と Linux の [[cgroups]] によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動)マウントポイントの維持、依存に基づいたサービスのコントロールをサポートします。
+
 
+
{{Note|1=systemd が Arch に採用された理由については、[https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 フォーラムへのこの投稿]をご覧ください。}}
+
 
+
== SysVinit/initscripts からの移行 ==
+
 
+
{{Note|
+
* {{Pkg|systemd}} と {{Pkg|systemd-sysvcompat}} は [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 2012-10-13] 以降のインストールメディアではデフォルトでインストールされます。このセクションは未だに ''sysvinit'' や ''initscripts'' を使っている Arch Linux システムに向けて書かれています。
+
* Arch Linux を VPS で動かしている場合、[[Virtual Private Server#Moving your VPS from initscripts to systemd]] を参照してください。
+
}}
+
 
+
=== 移行前に考慮すべきこと ===
+
 
+
* [http://freedesktop.org/wiki/Software/systemd/ 本家のホームページ] で、systemd についてざっと読んでください。
+
* systemd の '''journal''' システムは、'''syslog''' を置き換えることができますが、この2つは共存できます。[[#Journal]] を見て下さい。
+
* systemd は '''cron'''、'''acpid'''、'''xinetd''' の機能の一部を代替できますが、あなたが望まない限り伝統的なデーモンを使うのを止める必要はありません。
+
* インタラクティブな initscript は sytemd では動きません。特に、起動時に '''netcfg-menu''' を使うことはできません ({{Bug|31377}})。
+
 
+
=== インストール ===
+
 
+
# [[Official Repositories (日本語)|公式リポジトリ]]から {{pkg|systemd}} を[[pacman (日本語)|インストール]]してください。
+
# [[Kernel parameters (日本語)|カーネルパラメータ]]に次を加えます: {{ic|1=init=/usr/lib/systemd/systemd}}
+
# 完了したら、必要なサービスを {{ic|systemctl enable <service_name>.service}} を使って有効にできます (大雑把に言うと {{ic|DAEMONS}} 行に[[Daemons List (日本語)|サービス]]を追加するのと同じです)。
+
# システムを再起動し、{{ic|systemd}} がアクティブになっていることを次のコマンドで確認します: {{ic|cat /proc/1/comm}}。{{ic|systemd}} の文字が返ってくるはずです。
+
# systemd であなたのホストネームを設定します: {{ic|hostnamectl set-hostname myhostname}} または {{ic|/etc/hostname}}。
+
# ''initscripts'' と ''sysvinit'' をシステムから削除し {{pkg|systemd-sysvcompat}} をインストールしてください。
+
# もう必要なくなった {{ic|1=init=/usr/lib/systemd/systemd}} パラメータを削除してください。{{pkg|systemd-sysvcompat}} がデフォルトの init になります。
+
 
+
=== initscripts のエミュレーション ===
+
 
+
伝統的な Arch の設定ファイルは {{Pkg|initscripts}} パッケージによって使われています。systemd と {{Pkg|initscripts}} がインストールされていて、systemd によってシステムが動いている時、systemd は以下のことを行います:
+
 
+
# {{ic|/etc/rc.conf}} の {{ic|DAEMONS}} 行をパースし、ブート時にデーモンを起動します
+
# ブート中に {{ic|/etc/rc.local}} を実行します
+
# シャットダウン中に {{ic|/etc/rc.local.shutdown}} を実行します
+
 
+
Initscripts のエミュレーションはユーザーが systemd に移行するのを手助けする過渡期の手段として存在しています、そして'''最終的には取り除かれる予定です'''。ネイティブな systemd は設定の中心として {{ic|rc.conf}} を使いません、{{ic|/etc/rc.conf}} が使えなくなる前に[[#ネイティブの設定|ネイティブの systemd 設定ファイル]]を使うことを推奨します。
+
 
+
{{Note|{{ic|/etc/rc.local}} を置換するには、起動時に実行したいもののカスタムサービスファイルを書くことを推奨します。[[#カスタム .service ファイルを書く|このセクション]]に方法を記述しています。}}
+
 
+
{{Note|{{ic|Ctrl+Alt+Del}} で再起動しないように {{ic|/etc/inittab}} で設定していた場合、root で {{ic|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 セットアップのためには、完全に {{ic|/etc/rc.conf}} ファイルを削除して {{ic|systemctl}} だけを使ってサービスを有効にしなくてはなりません。{{ic|/etc/rc.conf}} の {{ic|DAEMONS}} 行のそれぞれの {{ic|<service_name>}} に対して次を実行します:
+
 
+
# systemctl enable <service_name>.service
+
 
+
{{Tip|一般的に使われるデーモンの initscripts と systemd の比較表が[[Daemons List (日本語)|ここ]]にあります。}}
+
 
+
{{ic|<service_name>.service}} が存在しない場合:
+
 
+
* ほとんどの場合、systemd は違う名前を使っています。例えば、{{ic|crond}} init デーモンは {{ic|cronie.service}} に、{{ic|alsa}} init デーモンは {{ic|alsa-store.service}} と {{ic|alsa-restore.service}} になっています。他にも {{ic|network}} デーモンは、他のサービスファイルに置き換わっています (詳しくは [[Network Configuration (日本語)]] を見て下さい)。
+
* サービスファイルが systemd にない場合。その場合、起動中にサービスを作動させるのに {{ic|rc.conf}} を使いつづける必要があります。
+
 
+
{{Tip|パッケージの中身を見て、どのサービス名でデーモン起動スクリプトが含まれているのか見ることができます。例:
+
$ pacman -Ql cronie
+
[...]
+
cronie /etc/rc.d/crond                            #DAEMONS 行で使われるデーモン initscript ("純粋な" systemd では使われません)
+
[...]
+
cronie /usr/lib/systemd/system/cronie.service    #対応する systemd のデーモンサービス
+
[...]
+
}}
+
 
+
* 最後に、サービスによっては、ユーザーの操作で有効にする必要がないものがあります。例えば、{{ic|dbus.service}} は {{ic|dbus-core}} がインストールされると自動で有効にされます。{{ic|alsa-store.service}} と {{ic|alsa-restore.service}} も systemd によって自動で有効にされます。利用できるサービスと状態をチェックするには {{ic|systemctl}} コマンドを使います: {{ic|systemctl status <service_name>}}。
+
 
+
=== 追加情報 ===
+
 
+
* カーネルパラメータに {{ic|quiet}} を設定している場合、それを削除することで、起動中に何が起こっているかわかりやすくなります。
+
 
+
* systemd を使っていてユーザーに[[Users and Groups (日本語)|グループ]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) を設定する必要はほとんどありません。グループは機能を破壊することさえあります。例えば、{{ic|audio}} グループは高速なユーザー切り替えやアプリケーションのソフトウェアミキシングを無効にします。全ての PAM ログインは logind セッションを提供します。オーディオ/ビデオデバイスに [[Wikipedia:Access control list|POSIX ACL]] を通して権限を与えたり、[[udisks]] を使ってリムーバルディスクのマウントなどの操作を行います。
+
 
+
* ネットワークの設定方法は [[Network Configuration (日本語)]] を見て下さい。
+
 
+
== systemctl の基本的な使い方 ==
+
 
+
''systemd'' を管理したり内部情報を見るために使うメインのコマンドが {{ic|systemctl}} です。システムの状態を確かめたりシステムやサービスを管理するために使うのは使い方の一部です。詳しくは {{ic|man 1 systemctl}} を見て下さい。
+
 
+
{{Tip|{{ic|systemctl}} コマンドに {{ic|-H <user>@<host>}} を渡すと、リモートの systemd と対話できます。[[SSH]] を利用してリモートの systemd インスタンスに繋ぐのに使われます。}}
+
 
+
{{Note|{{ic|systemadm}} は {{ic|systemctl}} の公式グラフィカルフロントエンドです。{{AUR|systemd-ui-git}} パッケージが [[Arch User Repository (日本語)|AUR]] から入手可能です。}}
+
 
+
=== システムの状態を分析する ===
+
 
+
実行中のユニットを一覧する:
+
 
+
$ systemctl
+
 
+
または:
+
 
+
$ systemctl list-units
+
 
+
失敗したユニットを一覧する:
+
 
+
$ systemctl --failed
+
 
+
実行可能なユニットファイルは {{ic|/usr/lib/systemd/system/}} や {{ic|/etc/systemd/system/}} にあります(後者が優先的に使われます)。インストールされたユニットを一覧するには:
+
 
+
$ systemctl list-unit-files
+
 
+
=== ユニットを使う ===
+
 
+
ユニットには、例えば、サービス ({{ic|.service}}) やマウントポイント ({{ic|.mount}})、デバイス ({{ic|.device}})、ソケット ({{ic|.socket}}) などがあります。
+
 
+
{{ic|systemctl}} を使うとき、一般的には拡張子 (suffix) を含むユニットファイルの完全な名前を指定する必要があります。例えば、{{ic|sshd.socket}} のように。しかし、以下のような場合には省略形が存在します:
+
 
+
* 拡張子が指定されない場合、systemctlは {{ic|.service}} とみなします。例えば {{ic|netcfg}} と {{ic|netcfg.service}} は同じように扱われます。
+
* マウントポイントは自動的に対応する {{ic|.mount}} ユニットとして扱われます。例えば、{{ic|/home}} を指定することは {{ic|home.mount}} の指定と同じです。
+
* マウントポイントと同じく、デバイスも自動的に対応する {{ic|.device}} ユニットとして扱われます。従って、{{ic|/dev/sda2}} の指定は {{ic|dev-sda2.device}} と同じです。
+
 
+
詳細は {{ic|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|サービスに {{ic|[Install]}} セクションがない場合、大抵は他のサービスから自動的に起動されます。手動でのインストールが必要な場合、以下のコマンドを使ってください ({{ic|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
+
 
+
=== 電源管理 ===
+
 
+
電源管理には {{ic|polkit}} が必要です。
+
ローカルの {{ic|systemd-logind}} のユーザーセッション中で、他のセッションがアクティブでなければ、ルート権限なしで以下のコマンドが使えます。そうでなければ(他のユーザが tty でログインしている場合など)、systemd は自動的に root のパスワードを要求するでしょう。
+
 
+
再起動:
+
 
+
$ systemctl reboot
+
 
+
シャットダウンしてパワーオフ:
+
 
+
$ systemctl poweroff
+
 
+
サスペンド(待機):
+
 
+
$ systemctl suspend
+
 
+
ハイバネート(休止):
+
 
+
$ systemctl hibernate
+
 
+
ハイブリッドスリープ (or suspend-to-both):
+
 
+
$ systemctl hybrid-sleep
+
 
+
== systemd でデスクトップ環境を動かす ==
+
 
+
グラフィカルログインを有効にするには、お好きな[[Display Manager (日本語)|ディスプレイマネージャ]]デーモンを使って下さい (例: [[KDM]])。現在、[[GDM]], [[KDM]], [[SLiM (日本語)]], [[XDM]], [[LXDM]], [[LightDM]], {{AUR|SDDM}} に対応したサービスファイルが存在します。
+
 
+
# systemctl enable kdm
+
 
+
これだけで動くはずですが、動かない場合、手動で {{ic|default.target}} を設定するか、前のインストールを使います:
+
 
+
{{hc|# ls -l /etc/systemd/system/default.target|
+
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}
+
 
+
シンボリックリンクを削除すれば systemd は標準の {{ic|default.target}} (つまり {{ic|graphical.target}}) を使うようになります。
+
 
+
# rm /etc/systemd/system/default.target
+
 
+
=== systemd-logind を使う ===
+
 
+
ユーザーセッションの状態を確認するには {{ic|loginctl}} を使います。サスペンドや外部デバイスのマウントなどの全ての [[PolicyKit]] アクションはそのまま動きます。
+
 
+
$ loginctl show-session $XDG_SESSION_ID
+
 
+
== ネイティブの設定 ==
+
 
+
{{Note|これらのファイルを作る必要があります。全てのファイルのパーティションは {{ic|644}} で所有者は {{ic|root:root}} である必要があります。}}
+
 
+
=== ホストネーム ===
+
 
+
ホストネームは {{ic|/etc/hostname}} で設定します。このファイルにシステムのドメインを含めてはいけません。ホストネームを設定するには:
+
 
+
# hostnamectl set-hostname '''myhostname'''
+
 
+
詳しくは {{ic|man 5 hostname}} や {{ic|man 1 hostnamectl}} を見て下さい。
+
 
+
ファイルの設定サンプル:
+
{{hc|/etc/hostname|
+
myhostname
+
}}
+
 
+
=== ロケール ===
+
 
+
デフォルトのシステムロケールは {{ic|/etc/locale.conf}} で設定します。デフォルトロケールをセットするには:
+
 
+
# localectl set-locale LANG="ja_JP.UTF-8"
+
 
+
{{Note|デフォルトロケールを設定する前に、{{ic|/etc/locale.gen}} で利用するロケールをアンコメントして {{ic|locale-gen}} を root で実行してロケールを有効にしておく必要があります。{{ic|localectl}} でセットするロケールは {{ic|/etc/locale.gen}} で'''アンコメントされた'''ロケールでなければなりません。}}
+
 
+
詳しくは {{ic|man 1 localectl}} や {{ic|man 5 locale.conf}} を見て下さい。
+
 
+
* ロケールについての詳しい情報は [[Locale (日本語)]] にあります。
+
 
+
ファイルの設定サンプル:
+
{{hc|/etc/locale.conf|<nowiki>
+
LANG=ja_JP.UTF-8
+
</nowiki>}}
+
 
+
=== 仮想端末 ===
+
 
+
仮想端末 (キーボッドマップ、コンソールフォント、コンソールマップ) の設定は {{ic|/etc/vconsole.conf}} です:
+
 
+
{{hc|/etc/vconsole.conf|2=
+
KEYMAP=jp106
+
FONT=lat9w-16
+
FONT_MAP=8859-1_to_uni}}
+
 
+
{{Note|{{pkg|systemd}}-194 現在、{{ic|1=KEYMAP=}} や {{ic|1=FONT=}} が空だったり設定されていない場合、ビルトインの ''kernel'' フォントと ''us'' キーマップが使われます。}}
+
 
+
キーボッドマップ(キーマップ)を設定する別の方法は:
+
 
+
# localectl set-keymap jp106
+
 
+
<code>localectl</code> で X11 のキーマップを設定することもできます:
+
 
+
# localectl set-x11-keymap jp106
+
 
+
詳細は {{ic|man 1 localectl}} や {{ic|man 5 vconsole.conf}} を見て下さい。
+
 
+
* 詳しい情報は[[Fonts (日本語)#コンソールフォント|コンソールフォント]]や[[KEYMAP (日本語)|キーマップ]]を見て下さい。
+
 
+
=== タイムゾーン ===
+
 
+
タイムゾーンは適切な {{ic|/etc/localtime}} シンボリックリンクを作ることで設定します。リンク先は {{ic|/usr/share/zoneinfo/}} 下のゾーン情報ファイルです。自動で行うには:
+
 
+
# timedatectl set-timezone Asia/Tokyo
+
 
+
詳しくは {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}}, {{ic|man 7 archlinux}} を見て下さい。
+
 
+
または、あなた自身でシンボリックリンクを作って下さい:
+
<!-- DO NOT MAKE THIS AN ABSOLUTE SYMLINK, archlinux(7) clearly shows this should be a relative symlink -->
+
# ln -sf ../usr/share/zoneinfo/Asia/Tokyo /etc/localtime
+
 
+
古い設定ファイル {{ic|/etc/timezone}} がある場合、削除しても問題ありません。
+
 
+
=== カーネルモジュール ===
+
 
+
現在、すべての必要なカーネルモジュールは [[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]] のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って {{ic|/etc/fstab}} に明記しなくともローカル・リモードどちらのファイルシステムのマウントも問題ありません。
+
 
+
詳しくは {{ic|man 5 systemd.mount}} を見て下さい。
+
 
+
==== Automount ====
+
 
+
* {{ic|/home}} パーティションが大きい場合は、{{ic|/home}} を fsck でチェックしている間に {{ic|/home}} を使わないサービスを起動できるようにしたほうがいいかもしれません。これを行うには {{ic|/etc/fstab}} の {{ic|/home}} パーティションのエントリに次のオプションを追加してください:
+
 
+
noauto,x-systemd.automount
+
 
+
{{ic|/home}} にアクセスがあるとまず fsck とマウントを行い、準備が整うまで {{ic|/home}} への全てのファイルアクセスをカーネルによって遮断します。
+
 
+
Note: オプションの追加によって {{ic|/home}} ファイルシステムのタイプが {{ic|autofs}} になり、[[mlocate]] から(デフォルトで)無視されるようになります。システムによっては、{{ic|/home}} の automount のスピードアップは大して効果がない場合があります。
+
 
+
* リモートファイルシステムのマウントにも同じことが当てはまります。アクセス時にのみマウントするようにしたい場合は、{{ic|noauto,x-systemd.automount}} パラメータを使って下さい。さらに、{{ic|1=x-systemd.device-timeout=#}} オプションを使うことでネットワークが切れた時のタイムアウト時間を設定できます。
+
 
+
* ファイルシステムをキーファイルで暗号化しているときは、{{ic|/etc/crypttab}} の適切なエントリに {{ic|noauto}} パラメータを追加することもできます。Systemd は起動時に暗号化されたデバイスを開かなくなり、代わりに、デバイスが実際にアクセスされるまで待機して、それから指定したキーファイルで(マウントする前に)自動でデバイスを開くようになります。デバイスが有効になるまで systemd が待機することがなくなるので、暗号化した RAID デバイスなどを使っているときは起動時間が数秒節約できます。例:
+
 
+
{{hc|/etc/crypttab|
+
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 is pulled in by suspend.target, hibernate.target and hybrid-sleep.target and sleep.target itself is a StopWhenUnneeded service, the hook is guaranteed to start/stop properly for different tasks.
+
 
+
===== /usr/lib/systemd/system-sleep のフック =====
+
 
+
Systemd は {{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#About_udev_rules|udev ルール]]を書いて下さい。}}
+
 
+
== カスタム .service ファイルを書く ==
+
 
+
systemd の[[#ユニットを使う|ユニットファイル]]の構文は XDG の Desktop Entry Specification である .desktop から影響を受けています。そして .desktop は Microsoft Windows の .ini ファイルにインスパイアされたものです。
+
 
+
もっと多くのサンプルが [[Systemd/Services]] にあります。
+
 
+
=== 依存関係を解決する ===
+
 
+
systemd ではユニットファイルを適切に書くことで依存関係を解決します。一番典型的なケースは、ユニット {{ic|A}} が走る前に、ユニット {{ic|A}} がユニット {{ic|B}} を必要としている場合です。この場合、{{ic|A}} の {{ic|[Unit]}} セクションに {{ic|1=Requires=B}} と {{ic|1=After=B}} を加えます。依存が必然ではない場合、代わりに {{ic|1=Wants=B}} と {{ic|1=After=B}} を加えます。{{ic|1=Wants=}} と {{ic|1=Requires=}} は {{ic|1=After=}} を含まないことに注意してください、もし {{ic|1=After=}} を明記しなかったときは、2つのユニットは並行して実行されます。
+
 
+
基本的に、依存関係はターゲットではなくサービスに配置します。例えば、{{ic|network.target}} はネットワークインターフェースを設定する全てのサービスによって使われるので、{{ic|network.target}} が起動し終わってからあなたのカスタムユニットを起動させる順番にします。
+
 
+
=== タイプ ===
+
 
+
カスタムサービスファイルを書くときにどのスタートアップタイプを使うべきか考える必要があります。タイプは {{ic|[Service]}} セクションの {{ic|1=Type=}} パラメータで設定します。より詳しい説明は {{ic|man systemd.service}} を見て下さい。
+
 
+
* {{ic|1=Type=simple}} (デフォルト): このタイプのサービスは systemd によってすぐに起動されます。プロセスをフォークすることはできません。ソケットが有効になる前に他のサービスが必要なサービスに、このタイプを使ってはいけません。
+
* {{ic|1=Type=forking}}: プロセスがフォークされたり親プロセスが終了したときに systemd はこのタイプのサービスを起動します。このタイプでなくてもかまわないとき以外は、古典的なデーモンにはこのタイプを使って下さい。また {{ic|1=PIDFile=}} を指定することで systemd はメインプロセスの情報を追い続けます。
+
* {{ic|1=Type=oneshot}}: シングルジョブを行い終了するスクリプト用のタイプです。また {{ic|1=RemainAfterExit=yes}} を設定することで systemd はプロセスが終了した後もサービスがアクティブだとみなします。
+
* {{ic|1=Type=notify}}: {{ic|1=Type=simple}} と同じですが、利用可能になったときにデーモンが systemd に信号を送るように条件がつけられます。この通知のリファレンス実装は {{ic|libsystemd-daemon.so}} によって提供されています。
+
* {{ic|1=Type=dbus}}: 指定の {{ic|BusName}} が DBus のシステムバスに乗ったときに使うことができるサービス。
+
 
+
=== ユニットファイルの編集 ===
+
 
+
パッケージによって提供されたユニットファイルを編集するときは、{{ic|/etc/systemd/system/<unit>.d/}} という名のディレクトリ (例: {{ic|/etc/systemd/system/httpd.service.d/}}) を作成してそのなかに {{ic|*.conf}} を置くことでオプションを上書きしたり追加したりすることが可能です。Systemd が {{ic|*.conf}} ファイルをパースして元のユニットファイルの一番上に設定を適用します。例えば、ユニットに追加の依存を入れたい時は、以下のファイルを作成します:
+
 
+
{{hc|/etc/systemd/system/<unit>.d/customdependency.conf|2=
+
[Unit]
+
Requires=<new dependency>
+
After=<new dependency>}}
+
 
+
そして変更を適用するために次を実行してください:
+
 
+
# systemctl daemon-reload
+
# systemctl restart <unit>
+
 
+
または、古いユニットファイルを {{ic|/usr/lib/systemd/system/}} から {{ic|/etc/systemd/system/}} にコピーして変更を加えることもできます。{{ic|/etc/systemd/system/}} 内のユニットファイルは {{ic|/usr/lib/systemd/system/}} 内の同じユニットを上書きします。パッケージのアップグレードによって {{ic|/usr/lib/}} の元のユニットが変更されたとき、変更が {{ic|/etc/}} 内のあなたのカスタムユニットファイルには自動では適用されないことに注意してください。さらに、変更するたびに手動で {{ic|systemctl reenable <unit>}} によってユニットを reenable する必要があります。したがって前述の {{ic|*.conf}} を使う方法のほうが推奨されます。
+
 
+
{{Tip|{{ic|systemd-delta}} を使うことでどのファイルが上書きされ、どこが変更されたのか調べることができます。}}
+
 
+
時々、提供されているユニットファイルがアップデートされることがあるので、systemd-delta を使ってシステム管理を行なって下さい。
+
 
+
=== Vim でのユニットのシンタックスハイライト ===
+
 
+
[[Official Repositories (日本語)|公式リポジトリ]]から {{Pkg|vim-systemd}} をインストールすることで、[[Vim]] でのユニットファイルのシンタックスハイライトが可能です。
+
 
+
== ターゲット ==
+
 
+
Systemd ではランレベルに似たものとして''ターゲット''を使っています。ただしその挙動には少し違いがあります。それぞれの''ターゲット''はナンバリングされる代わりに名前がつけられ、ある特定の目的のために作られ、複数のターゲットを同時に有効にできるようになっています。''ターゲット''によっては、他の''ターゲット''のサービスを全て引継ぎ、そこにサービスを追加するよう実装されています。一般的な SystemVinit ランレベルに擬態する systemd ''ターゲット''もあり、親しみのある {{ic|telinit RUNLEVEL}} コマンドを使って使用する''ターゲット''を切り替えることが可能です。
+
 
+
=== 現在のターゲットを獲得 ===
+
 
+
systemd では {{ic|runlevel}} の代わりに次のコマンドが使われます:
+
 
+
$ systemctl list-units --type=target
+
 
+
=== カスタムターゲットを作る ===
+
 
+
標準の Fedora インストールではランレベルごとに特定の目的が設定されています; 0, 1, 3, 5, 6 のランレベルには特定の sytemd ''ターゲット''と一対一の対応関係が存在します。残念ながら、ユーザー定義のランレベル (2 や 4 など) で同じことをする良い方法はありません。もしあなたがそうしたいならば、既に存在しているランレベルをベースに新しい systemd ''ターゲット''を {{ic|/etc/systemd/system/<your target>}} として作り ({{ic|/usr/lib/systemd/system/graphical.target}} がサンプルになるかもしれません)、{{ic|/etc/systemd/system/<your target>.wants}} ディレクトリを作って、有効にしたいサービスに {{ic|/usr/lib/systemd/system/}} からシンボリックリンクを貼ることが示唆されています。
+
 
+
=== ターゲット表 ===
+
 
+
{| border="1"
+
! 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 での、{{ic|telinit 3}} や {{ic|telinit 5}} のようなコマンドと同じです。
+
 
+
=== 起動時のデフォルトターゲットを変更する ===
+
 
+
標準のターゲットは {{ic|default.target}} で、デフォルトで (昔のランレベル 5 に大体対応している) {{ic|graphical.target}} にエイリアスされています。起動時のデフォルトターゲットを変更するには、以下の[[kernel parameters (日本語)|カーネルパラメータ]]のどれかをブートローダに加えてください:
+
 
+
{{Tip|{{ic|.target}} 拡張子は省くことができます。}}
+
 
+
* {{ic|1=systemd.unit=multi-user.target}} (昔のランレベル 3 とほぼ同じ),
+
* {{ic|1=systemd.unit=rescue.target}} (昔のランレベル 1 とほぼ同じ).
+
 
+
また、ブートローダには修正を加えずに {{ic|default.target}} を変えることもできます。{{ic|systemctl}} を使います:
+
 
+
# systemctl enable multi-user.target
+
 
+
このコマンドの効果は {{ic|systemctl}} によって出力されます; 新しいデフォルトターゲットのシンボリックリンクは {{ic|/etc/systemd/system/default.target}} に作成されます。ターゲットの設定ファイルに:
+
 
+
[Install]
+
Alias=default.target
+
 
+
があるときだけこれが動作します。現在、{{ic|multi-user.target}} と {{ic|graphical.target}} がこれを持っています。
+
 
+
== タイマー ==
+
 
+
Systemd は cron の機能をほぼ全て置き換えることができます。詳しくは、[[systemd/cron functionality]] を参照してください。
+
 
+
== Journal ==
+
systemd は、version 38 から自前のログシステムである journal を持っています。従って、syslog デーモンを起動する必要は既にありません。ログを読むには:
+
 
+
# journalctl
+
 
+
デフォルトで ({{ic|/etc/systemd/journald.conf}} 内で {{ic|Storage&#61;}} が {{ic|auto}} に設定されているとき)、journal は {{ic|/var/log/journal/}} へ書き込みを行います。{{ic|/var/log/journal/}} ディレクトリは systemd の一部であり、あなたや何らかのプログラムがそれを削除した場合、systemd は自動で'''再作成しません'''が、systemd のアップデートがあるとディレクトリは作りなおされます。それまでログは代わりに {{ic|/run/systemd/journal}} に書き込まれます。ただし再起動時にこのログは消失してしまいます。
+
 
+
{{Tip|{{ic|/var/log/journal/}} が [[btrfs (日本語)|btrfs]] ファイルシステムに存在する場合、ディレクトリの [[Btrfs (日本語)#コピーオンライト (CoW)|Copy-on-Write]] を無効にするべきです:
+
# chattr +C /var/log/journal
+
}}
+
 
+
=== フィルタリング ===
+
 
+
{{ic|journalctl}} を使って出力にフィルタをかけることができます。
+
 
+
例:
+
 
+
起動時からの全てのメッセージを表示:
+
+
# journalctl -b
+
 
+
しかしながら、見たいメッセージは現在のブートではなく、以前のブートからの情報であることがよくあります (例: リカバリーできないシステムクラッシュが起こった場合)。現在、このような機能は実装されていませんが、[http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/6608 systemd-devel@lists.freedesktop.org] で議論がなされています (September/October 2012)。
+
 
+
今のところ、次のコマンドで(今日の)以前のブートのメッセージを表示できます:
+
 
+
# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac
+
 
+
多くのメッセージが存在する場合、このコマンドの出力にはかなり時間がかかることがあるので注意してください。
+
 
+
{{note|systemd バージョン 206 からはこれを簡単に出来るようになっています。{{ic|journalctl -b}} に {{ic|-0}} (最後のブート) と引数を付けられます。例えば {{ic|journalctl -b -3}} とすれば4番目から最後のブートまでの全てのメッセージが表示されます。}}
+
 
+
新しいメッセージを表示:
+
 
+
# journalctl -f
+
 
+
特定の実行ファイルによる全てのメッセージを表示:
+
 
+
# journalctl /usr/lib/systemd/systemd
+
 
+
特定のプロセスによる全てのメッセージを表示:
+
 
+
# journalctl _PID=1
+
 
+
特定のユニットによる全てのメッセージを表示:
+
 
+
# journalctl -u netctl
+
 
+
カーネルのリングバッファを表示:
+
 
+
# journalctl _TRANSPORT=kernel
+
 
+
詳しくは {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}} や Lennert の [http://0pointer.de/blog/projects/journalctl.html blog post] を見て下さい。
+
 
+
=== journal のサイズ制限 ===
+
 
+
journal が永続的(不揮発性)の場合、デフォルトではファイルシステムの容量の 10% に制限されます。例えば、{{ic|/var/log/journal}} が 50GiB の root パーティションにのっている場合、5GiB がログデータの上限になります。{{ic|/etc/systemd/journald.conf}} の {{ic|SystemMaxUse}} を変更すれば、最大サイズを変更できます。例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します:
+
 
+
SystemMaxUse=50M
+
 
+
詳細は {{ic|man journald.conf}} を参照してください。
+
 
+
=== journald と syslog の結合 ===
+
 
+
古典的な syslog との互換性は、すべてのメッセージがソケット {{ic|/run/systemd/journal/syslog}} に転送されることで実現されます。syslog を使うには、{{ic|/dev/log/}} の代わりにこのソケットを指定します([http://lwn.net/Articles/474968/ 公式アナウンス])。{{pkg|syslog-ng}} は必要な設定ファイルを自動的に提供します。
+
 
+
# systemctl enable syslog-ng
+
 
+
== トラブルシューティング ==
+
 
+
=== systemd のエラーを調査する ===
+
 
+
例えば、{{ic|systemd-modules-load}} サービスのエラーを調べるとします:
+
 
+
1. 起動に失敗している systemd サービスを探しましょう:
+
$ systemctl | grep -i failed
+
systemd-modules-load.service  loaded '''failed failed'''  Load Kernel Modules
+
 
+
2. Ok, {{ic|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) を入手しました。{{ic|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. カーネルモジュールに間違った設定がなされているようです。よって {{ic|/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. エラーメッセージ {{ic|Failed to find module 'blacklist usblp'}} はおそらく {{ic|blacklist.conf}} 内に間違った設定があることを示しています。手順 3 で見つけたオプションの前に '''#''' を挿入して無効化してみましょう:
+
$ nano /etc/modules-load.d/blacklist.conf
+
'''#''' blacklist usblp
+
'''#''' install usblp /bin/false
+
 
+
6. では、{{ic|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'''.
+
 
+
この種の問題は上のように解決できます。より詳しい調査をする場合は次の"'''ブート問題の診断'''"を見て下さい。
+
 
+
=== ブート問題の診断 ===
+
 
+
カーネルコマンドラインに次のパラメータをつけて起動してください:
+
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}
+
 
+
[http://freedesktop.org/wiki/Software/systemd/Debugging More Debugging Information]
+
 
+
=== シャットダウン/再起動にものすごく時間がかかる ===
+
 
+
シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。Systemd はサービスを kill する前に終了するのを待ちます。なにが原因か知るには [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually この記事] を見て下さい。
+
 
+
=== 短いプロセスがログを出力しない ===
+
 
+
{{ic|journalctl -u foounit.service}} が短いプロセスについてなにも表示しない場合、かわりに PID を見て下さい。例えば、{{ic|systemd-modules-load.service}} が失敗したとき、{{ic|systemctl status systemd-modules-load}} によってそれが PID 123 として動いているとわかったら、その PID の journal の出力を見ることができます、{{ic|journalctl -b _PID&#61;123}}。journal の _SYSTEMD_UNIT や _COMM などのメタデータは非同期に収集され {{ic|/proc}} ディレクトリにプロセスが存在している時だけ表示されます。これを修正するには、SCM_CREDENTIALS のように、ソケット接続を使ってデータを流すようカーネルを変更する必要があります。
+
 
+
=== クラッシュしたアプリケーションのダンプのジャーナルを無効にする ===
+
 
+
以下を実行して {{ic|/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
+
 
+
詳細は [http://www.freedesktop.org/software/systemd/man/sysctl.d.html sysctl.d] や [https://www.kernel.org/doc/Documentation/sysctl/kernel.txt the documentation for /proc/sys/kernel] を見て下さい。
+
 
+
== 参照 ==
+
 
+
*[http://www.freedesktop.org/wiki/Software/systemd 公式ウェブサイト]
+
*[[Wikipedia:ja:systemd|Wikipedia article]]
+
*[http://0pointer.de/public/systemd-man/ Manual Pages]
+
*[http://freedesktop.org/wiki/Software/systemd/Optimizations systemd Optimizations]
+
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]
+
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips And Tricks]
+
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]
+
*[http://fedoraproject.org/wiki/Systemd About systemd on Fedora Project]
+
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems How to debug systemd problems]
+
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] introductory article in ''The H Open'' magazine.
+
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]
+
*[http://0pointer.de/blog/projects/systemd-update.html status update]
+
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]
+
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]
+
*[http://0pointer.de/blog/projects/why.html most recent summary]
+
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]
+
*[[Allow Users to Shutdown|通常ユーザーがシャットダウンをできるように systemd を設定する]]
+

Latest revision as of 09:44, 1 March 2015

Redirect to: