Difference between revisions of "Systemd (日本語)"
m (→Automount) |
m |
||
Line 55: | Line 55: | ||
* {{Pkg|initscripts}} パッケージを消去すると {{ic|rc.conf}} の互換性がなくなります。デーモンやネットワークの設定をそこで行なっていた場合、systemd に移行されないので注意してください。2つのシステムを共存させる方法について詳しくは [[#initscripts のエミュレーション|initscripts のエミュレーションのセクション]]を見て下さい。 | * {{Pkg|initscripts}} パッケージを消去すると {{ic|rc.conf}} の互換性がなくなります。デーモンやネットワークの設定をそこで行なっていた場合、systemd に移行されないので注意してください。2つのシステムを共存させる方法について詳しくは [[#initscripts のエミュレーション|initscripts のエミュレーションのセクション]]を見て下さい。 | ||
− | |||
− | |||
== ネイティブの設定 == | == ネイティブの設定 == | ||
Line 164: | Line 162: | ||
詳しくは {{ic|man 5 modules-load.d}} を見て下さい。 | 詳しくは {{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=64}} | ||
+ | |||
+ | その後、新しく設定したオプションを {{ic|cat /sys/module/loop/parameters/max_loop}} によって検証することができます。 | ||
==== ブラックリスト ==== | ==== ブラックリスト ==== | ||
Line 186: | Line 194: | ||
* リモートファイルシステムのマウントにも同じことが当てはまります。アクセス時にのみマウントするようにしたい場合は、{{ic|noauto,x-systemd.automount}} パラメータを使って下さい。さらに、{{ic|1=x-systemd.device-timeout=#}} オプションを使うことでネットワークが切れた時のタイムアウト時間を設定できます。 | * リモートファイルシステムのマウントにも同じことが当てはまります。アクセス時にのみマウントするようにしたい場合は、{{ic|noauto,x-systemd.automount}} パラメータを使って下さい。さらに、{{ic|1=x-systemd.device-timeout=#}} オプションを使うことでネットワークが切れた時のタイムアウト時間を設定できます。 | ||
− | * | + | * ファイルシステムをキーファイルで暗号化しているときは、{{ic|/etc/crypttab}} の適切なエントリに {{ic|noauto}} パラメータを追加することもできます。Systemd は起動時に暗号化されたデバイスを開かなくなり、代わりに、デバイスが実際にアクセスされるまで待機して、それから指定したキーファイルで(マウントする前に)自動でデバイスを開くようになります。デバイスが有効になるまで systemd が待機することがなくなるので、暗号化した RAID デバイスなどを使っているときは起動が数秒早くなります。例: |
{{hc|/etc/crypttab| | {{hc|/etc/crypttab| | ||
Line 561: | Line 569: | ||
* {{ic|1=Type=dbus}}: 指定の {{ic|BusName}} が DBus のシステムバスに乗ったときに使うことができるサービス。 | * {{ic|1=Type=dbus}}: 指定の {{ic|BusName}} が DBus のシステムバスに乗ったときに使うことができるサービス。 | ||
− | === | + | === ユニットファイルの編集 === |
− | {{ic|/etc/systemd/system/ | + | パッケージによって提供されたユニットファイルを編集するときは、{{ic|/etc/systemd/system/<unit>.d/}} という名のディレクトリを作成してそのなかに {{ic|*.conf}} を置くことでオプションを上書きしたり追加したりすることが可能です。Systemd が {{ic|*.conf}} ファイルをパースして元のユニットファイルの一番上に設定を適用します。例えば、ユニットに追加の依存を入れたい時は、以下のファイルを作成します: |
− | |||
− | |||
− | |||
− | |||
+ | {{hc|/etc/systemd/system/<unit>.d/customdependency.conf|2= | ||
[Unit] | [Unit] | ||
Requires=<new dependency> | Requires=<new dependency> | ||
Line 575: | Line 580: | ||
そして変更を適用するために次を実行してください: | そして変更を適用するために次を実行してください: | ||
− | # systemctl | + | # systemctl daemon-reload |
# systemctl restart <unit> | # 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 を使ってシステム管理を行なって下さい。 | {{Tip|{{ic|systemd-delta}} を使うことでどのファイルが上書きされ、どこが変更されたのか調べることができます。}} 時々、提供されているユニットファイルがアップデートされることがあるので、systemd-delta を使ってシステム管理を行なって下さい。 | ||
Line 712: | Line 719: | ||
==== systemd-analyze を使う ==== | ==== systemd-analyze を使う ==== | ||
− | Systemd には {{ic|systemd-analyze}} | + | Systemd には {{ic|systemd-analyze}} というツールがあり、どのプロセスが起動を遅くしているのか調べるためにブートプロセスを解析することができます。それに応じてシステムを最適化することも可能です。 |
起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るためには、シンプルに次を実行: | 起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るためには、シンプルに次を実行: | ||
Line 718: | Line 725: | ||
$ systemd-analyze | $ systemd-analyze | ||
− | {{Tip|initramfs でどれくらい時間がかかったか見るためには、{{ic|/etc/[[mkinitcpio]].conf}} の {{ic|HOOKS}} 行に {{ic|timestamp}} フックを加え、root 権限で initramfs を {{ic|mkinitcpio -p linux}} で再生成してください。}} | + | {{Tip| |
+ | *initramfs でどれくらい時間がかかったか見るためには、{{ic|/etc/[[mkinitcpio]].conf}} の {{ic|HOOKS}} 行に {{ic|timestamp}} フックを加え、root 権限で initramfs を {{ic|mkinitcpio -p linux}} で再生成してください。 | ||
+ | *[[Unified Extensible Firmware Interface (日本語)|UEFI]] でブートしていて、かつ systemd の [http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface Boot Loader Interface] を実装しているブートローダ (今のところ [[Gummiboot]] のみ) を使っている場合は、systemd-analyze は EFI ファームウェアとブートローダでかかった時間も追加で表示します。 | ||
+ | }} | ||
ユニットファイルを起動するのにかかった時間で並べて一覧するには: | ユニットファイルを起動するのにかかった時間で並べて一覧するには: |
Revision as of 07:33, 20 March 2013
zh-CN:Systemd Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end project web page より:
systemd は SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。systemd はサービスの起動を積極的に並行化します。また、サービス起動時にソケットと D-Bus を有効化し、必要なサービスの開始と Linux の cgroups によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動)マウントポイントの維持、依存に基づいたサービスのコントロールをサポートします。systemd は sysvinit の代替として動きます。
詳しくは、Wikipedia の記事や本家のホームページもどうぞ。
Contents
- 1 移行前に考慮すべきこと
- 2 インストール
- 3 ネイティブの設定
- 4 initscripts から systemd への移行
- 5 systemctl の基本的な使い方
- 6 systemd でデスクトップ環境を動かす
- 7 カスタム .service ファイルを書く
- 8 ターゲット
- 9 Journal
- 10 最適化
- 11 トラブルシューティング
- 12 See also
移行前に考慮すべきこと
- 本家のホームページで、systemd についてざっと読んでください。
- systemd の journal システムは、syslog の機能を提供し置き換えます。ただしこれらは共存できます。下の journal についてのセクションを読んでください。
- systemd が cron、acpid、xinetd の機能を代替しようとする計画がありますが、今はまだ伝統的なデーモンを使い続けることができます。
- インタラクティブな initscript は sytemd では動きません。特に、起動時に netcfg-menu を使うことはできません。
インストール
以下のセクションは systemd にまだ移行していない sysvinit と initscripts の Arch Linux のためのインストール方法です。
- systemd をインストールして kernel line に次を加えます:
init=/usr/lib/systemd/systemd
- 完了したら、必要なサービスを
systemctl enable <service_name>.service
を使って有効にできます (大雑把に言うとDAEMONS
行に違う名前で追加するのと同じです)。 - システムを再起動し、
systemd
がアクティブになっていることを次のコマンドで確認します:cat /proc/1/comm
。systemd
の文字が返ってくるはずです。 - systemd であなたのホストネームを設定します:
hostnamectl set-hostname myhostname
。 - initscripts と sysvinit をシステムから削除し systemd-sysvcompat をインストールしてください。
- もう必要なくなった
init=/usr/lib/systemd/systemd
パラメータを削除してください。systemd-sysvcompat がデフォルトの init になります。
追加情報
- カーネルパラメータに
quiet
を設定している場合、それを削除することで、起動中に何が起こっているかわかりやすくなります。
- systemd を使う場合ユーザーにグループ (
sys
,disk
,lp
,network
,video
,audio
,optical
,storage
,scanner
,power
, etc.) を設定しなくてはいけないことはほとんどありません。グループは機能を破壊することさえあります。例えば、audio グループは高速ユーザー切り替えやアプリケーションのソフトウェアミキシングを無効にします。全ての PAM ログインは logind セッションを提供します。オーディオ/ビデオデバイスに POSIX ACL を通して権限を与えたり、udisks を使ってリムーバルディスクのマウントなどの操作を行います。
- initscripts パッケージを消去すると
rc.conf
の互換性がなくなります。デーモンやネットワークの設定をそこで行なっていた場合、systemd に移行されないので注意してください。2つのシステムを共存させる方法について詳しくは initscripts のエミュレーションのセクションを見て下さい。
ネイティブの設定
ホストネーム
ホストネームは /etc/hostname
で設定します。このファイルにシステムのドメインを含めてはいけません。ホストネームを設定するには:
# hostnamectl set-hostname myhostname
詳しくは man 5 hostname
や man 1 hostnamectl
を見て下さい。
ファイルの設定サンプル:
/etc/hostname
myhostname
Locale
デフォルトのシステムロケールは /etc/locale.conf
で設定します。デフォルトロケールをセットするには:
# localectl set-locale LANG="ja_JP.UTF-8"
/etc/locale.gen
で利用するロケールをアンコメントして locale-gen
を root で実行してロケールを有効にしておく必要があります。localectl
でセットするロケールは /etc/locale.gen
でアンコメントされたロケールでなければなりません。詳しくは man 1 localectl
や man 5 locale.conf
を見て下さい。
- ロケールについての詳しい情報が Locale (日本語) にあります。
ファイルの設定サンプル:
/etc/locale.conf
LANG=ja_JP.UTF-8
仮想端末
仮想端末 (キーボッドマップ、コンソールフォント、コンソールマップ) の設定は /etc/vconsole.conf
です:
/etc/vconsole.conf
KEYMAP=jp106 FONT=lat9w-16 FONT_MAP=8859-1_to_uni
キーボッドマップ(キーマップ)を設定する別の方法は:
# localectl set-keymap jp106
localectl
で X11 のキーマップを設定することもできます:
# localectl set-x11-keymap jp106
詳細は man 1 localectl
や man 5 vconsole.conf
を見て下さい。
タイムゾーン
タイムゾーンは適切な /etc/localtime
シンボリックリンクを作ることで設定します。リンク先は /usr/share/zoneinfo/
下のゾーン情報ファイルです。自動で行うには:
# timedatectl set-timezone Asia/Tokyo
詳しくは man 1 timedatectl
, man 5 localtime
, man 7 archlinux
を見て下さい。
または、あなた自身でシンボリックリンクを作って下さい:
# ln -sf ../usr/share/zoneinfo/Asia/Tokyo /etc/localtime
古い設定ファイル /etc/timezone
がある場合、削除しても問題ありません。
ハードウェアクロック
Systemd はデフォルトで UTC をハードウェアクロックに使います。
localtime をハードウェアクロックに
ハードウェアクロックで localtime を使うようにするには (するべきではありません):
# timedatectl set-local-rtc true
ハードウェアクロックを UTC に戻すには:
# timedatectl set-local-rtc false
警告したように、ハードウェアクロック (RTC) を localtime に設定すると、夏時間の扱いで問題が生じます。コンピュータの電源が切られている時に夏時間が変わると、次の起動時に時計がおかしくなります (詳しくはここを見て下さい)。最近のカーネルでは起動時にシステム時刻を直接 RTC からセットしますが、その際カーネルは RTC を UTC としてみなします。RTC が localtime だった場合、起動時に毎回システム時刻は間違ってセットされその後修正されることになります。これは予期せぬバグを引き起こす温床になりかねません(時計が戻るのはいいことではありません)。
RTC を localtime に設定する理由のひとつが Windows とのデュアルブートをするためです (Windows は localtime を使っています)。しかしながら、Windows は簡単な registry fix で UTC の RTC を扱うことができます。よって、Linux に localtime を使わせるよりも Windows に UTC を使わせるようにすることが推奨されます。Windows に UTC を使わせる場合、Windows のインターネット時刻機能をオフにするようにしてください。代わりに、上で提案しているように NTP デーモンを有効にすることで Linux を使って RTC を同期させる必要があります。
- 詳しくは Time を見て下さい。
カーネルモジュール
現在、すべての必要なカーネルモジュールは udev によって自動でロードされます。従って、サポート外のカーネルモジュールを使おうとしない限り、設定ファイルにモジュールをロードするように書く必要はありません。しかし、ブートプロセスでモジュールをロードしたい場合や、コンピュータを正しく機能させるためにモジュールをブラックリストに加える必要があるかもしれません。
起動時にモジュールをロード
/etc/modules-load.d/
下のファイルに、ブート時に読み込むカーネルモジュールを設定します。それぞれの設定ファイルは /etc/modules-load.d/<program>.conf
という名前です。設定ファイルには単純にロードすべきカーネルモジュールを一行毎に並べます。空の行や、スペース以外の最初の文字が #
や ;
の行は無視されます。
/etc/modules-load.d/virtio-net.conf
# Load virtio-net.ko at boot virtio-net
詳しくは man 5 modules-load.d
を見て下さい。
モジュールオプションの設定
追加モジュールオプションは /etc/modprobe.d/modprobe.conf
に設定する必要があります。
例:
- ブート中にロードするために
loop
モジュールには/etc/modules-load.d/loop.conf
があります。 -
/etc/modprobe.d/modprobe.conf
には追加のオプションを指定します、例えばoptions loop max_loop=64
その後、新しく設定したオプションを cat /sys/module/loop/parameters/max_loop
によって検証することができます。
ブラックリスト
モジュールのブラックリストは、kmod によって扱われるので、initscripts の時と同じ方法で動作します。詳細は Module Blacklisting にあります。
ファイルシステムをマウントする
デフォルトのセットアップでは自動的に fsck が行われサービスが起動する前にファイルシステムがマウントされます。例えば、systemd は NFS や Samba のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って /etc/fstab
に明記しなくともローカル・リモードどちらのファイルシステムのマウントも問題ありません。
詳しくは man 5 systemd.mount
を見て下さい。
Automount
-
/home
パーティションが大きい場合は、/home
を fsck でチェックしている間に/home
を使わないサービスを起動できるようにしたほうがいいかもしれません。これを行うには/etc/fstab
の/home
パーティションのエントリに次のオプションを追加してください:
noauto,x-systemd.automount
/home
にアクセスがあるとまず fsck とマウントを行い、準備が整うまで /home
への全てのファイルアクセスをカーネルによって遮断します。
Note: オプションの追加によって /home
ファイルシステムのタイプが autofs
になり、mlocate から(デフォルトで)無視されるようになります。システムによっては、/home
の automount のスピードアップは大して効果がない場合があります。
- リモートファイルシステムのマウントにも同じことが当てはまります。アクセス時にのみマウントするようにしたい場合は、
noauto,x-systemd.automount
パラメータを使って下さい。さらに、x-systemd.device-timeout=#
オプションを使うことでネットワークが切れた時のタイムアウト時間を設定できます。
- ファイルシステムをキーファイルで暗号化しているときは、
/etc/crypttab
の適切なエントリにnoauto
パラメータを追加することもできます。Systemd は起動時に暗号化されたデバイスを開かなくなり、代わりに、デバイスが実際にアクセスされるまで待機して、それから指定したキーファイルで(マウントする前に)自動でデバイスを開くようになります。デバイスが有効になるまで systemd が待機することがなくなるので、暗号化した RAID デバイスなどを使っているときは起動が数秒早くなります。例:
/etc/crypttab
data /dev/md0 /root/key noauto
LVM
initramfs でアクティベイトしていない LVM ボリュームがある場合、lvm2 パッケージで提供されている、lvm-monitoring
サービスを有効にしてください:
# systemctl enable lvm-monitoring
同じように、暗号化されたデバイスで LVM をブートの後ろでマウントしている場合(例: /etc/crypttab
からマウント)、lvm2 パッケージの、lvm-on-crypt
サービスを有効化してください:
# systemctl enable lvm-on-crypt
ACPI 電源管理
systemd は電源関連の ACPI イベントを扱えます。/etc/systemd/logind.conf
のオプションを使って設定できます:
-
HandlePowerKey
: パワーキーが押された時に行う動作を定めます。 -
HandleSuspendKey
: サスペンドキーが押された時に行う動作を定めます。 -
HandleHibernateKey
: ハイバネートキーが押された時に行う動作を定めます。 -
HandleLidSwitch
: フタが閉じられた時に行う動作を定めます。
定めることができる動作は ignore
, poweroff
, reboot
, halt
, suspend
, hibernate
, kexec
のどれかです。
オプションが設定されていない時に、systemd が使うデフォルトは: HandlePowerKey=poweroff
, HandleSuspendKey=suspend
, HandleHibernateKey=hibernate
, HandleLidSwitch=suspend
。
グラフィカルセットアップを走らせていなかったり i3 や awesome (日本語) などシンプルなウィンドウマネージャしか使っていないシステムでは、以前から ACPI イベントに反応するものとして使われていた acpid デーモンで置き換えることができるかもしれません。
In the current version of systemd, the Handle*
options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.
Handle
options to ignore
if you want your ACPI events to be handled by Xfce, acpid or other programs. New versions are on the way that will include this functionality.Sleep フック
systemctl suspend
, systemctl hibernate
, systemctl hybrid-sleep
が実行された時、Systemd はマシンをスリープ状態にするのに pm-utils を使いません; カスタムフックを含む、pm-utils フックは実行されません。ただし、こうしたイベントでカスタムスクリプトを動かすために systemd は2つの似た機構を提供しています。
サスペンド/リジューム サービスファイル
サービスファイルを suspend.target, hibernate.target, sleep.target にフックすることでサスペンド・ハイバネート前後に行うアクションを設定できます。ユーザー・システムアクションを行うにはファイルを分割する必要があります。ユーザーサービスファイルを作動させるには、# systemctl enable suspend@<user> && systemctl enable resume@<user>
。例:
/etc/systemd/system/suspend@.service
[Unit] Description=User suspend actions Before=sleep.target [Service] User=%I Type=forking Environment=DISPLAY=:0 ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop' ExecStart=/usr/bin/sflock [Install] WantedBy=sleep.target
/etc/systemd/system/resume@.service
[Unit] Description=User resume actions After=suspend.target [Service] User=%I Type=simple ExecStartPre=/usr/local/bin/ssh-connect.sh ExecStart=/usr/bin/mysql -e 'slave start' [Install] WantedBy=suspend.target
root アクションでは (# systemctl enable root-suspend
でアクティベイト):
/etc/systemd/system/root-resume.service
[Unit] Description=Local system resume actions After=suspend.target [Service] Type=simple ExecStart=/usr/bin/systemctl restart mnt-media.automount [Install] WantedBy=suspend.target
/etc/systemd/system/root-suspend.service
[Unit] Description=Local system suspend actions Before=sleep.target [Service] Type=simple ExecStart=-/usr/bin/pkill sshfs [Install] WantedBy=sleep.target
サービスファイルについてのヒント(詳しくは man systemd.service
):
-
Type=OneShot
の場合、複数のExecStart=
行を使うことができます。それ以外の場合は使える ExecStart は一行だけです。ExecStartPre
を使ったりコマンドをセミコロンで分割することでコマンドを追加することができます(最初の例を見て下さい -- セミコロンの前後にはスペースが必要です)。 - A command prefixed with '-' will cause a non-zero exit status to be ignored and treated as a successful command.
- The best place to find errors when troubleshooting these service files is of course with
journalctl
.
サスペンド/リジューム サービスファイルの統合
With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).
Example and explanation:
/etc/systemd/system/wicd-sleep.service
[Unit] Description=Wicd sleep hook Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStart=-/usr/share/wicd/daemon/suspend.py ExecStop=-/usr/share/wicd/daemon/autoconnect.py [Install] WantedBy=sleep.target
-
RemainAfterExit=yes
: After started, the service is always seen active until it is explicitly stopped. -
StopWhenUnneeded=yes
: When active, the service will be stopped after sleep.target is stopped. - 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 は /usr/lib/systemd/system-sleep/
内の全ての実行可能ファイルを実行するときに、2つの引数を渡します:
- 引数 1:
pre
かpost
。マシンが停止するときと起動するとき。 - 引数 2:
suspend
かhibernate
かhybrid-sleep
。呼び出されるものによる。
pm-utils とは対照的に、systemd はスクリプトを(一つずつではなく)同時に実行します。
カスタムスクリプトの出力は systemd-suspend.service
, systemd-hibernate.service
, systemd-hybrid-sleep.service
によって記録されます。出力を見るには systemd の journal を使って下さい:
# journalctl -b -u systemd-suspend
カスタムスクリプトを使うかわりに sleep.target
, suspend.target
, hibernate.target
, hybrid-sleep.target
を使ってユニットをスリープステートロジックにフックさせることもできます。
カスタムスリープスクリプトの例:
/usr/lib/systemd/system-sleep/example.sh
#!/bin/sh case $1/$2 in pre/*) echo "Going to $2..." ;; post/*) echo "Waking up from $2..." ;; esac
スクリプトを実行可能にするのを忘れないで下さい:
# chmod a+x /usr/lib/systemd/system-sleep/example.sh
詳しくは man 7 systemd.special
や man 8 systemd-sleep
を見て下さい。
一時ファイル
Systemd-tmpfiles は /usr/lib/tmpfiles.d/
と /etc/tmpfiles.d/
下にある設定ファイルを読み、通常 /run
や /tmp
などのディレクトリにある一時ファイル・ディレクトリの作成、内容の消去、削除などを行います。それぞれの設定ファイル名は /etc/tmpfiles.d/<program>.conf
です。/usr/lib/tmpfiles.d/
に同名の設定ファイルがある場合上書きされます。
tmpfiles は一時ファイルを必要とするデーモンのサービスファイルに同梱されます。例えば Samba デーモンは /run/samba
を一時ディレクトリとして使用するため、正しいパーミッションに設定されていることを期待します。これを表す tmpfile は以下のようになります:
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
tmpfiles は起動時にファイルに値を書き込むのにも使われることがあります。例えば、/etc/rc.local
を使って USB デバイスからの wakeup を無効化する echo USBE > /proc/acpi/wakeup
ことは、tmpfile では以下のように書けます:
/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE
詳細は man 5 tmpfiles.d
を参照。
ユニット
ユニット設定ファイルは、systemd によって管理される、サービス、ソケット、デバイス、(自動)マウントポイント、スワップパーティション(ファイル)、ターゲット、ファイルシステムのパス、タイマーについての設定をまとめたものです。設定の構文は XDG の .desktop を真似ていて、これは Microsoft Windows の .ini ファイルに影響を受けています。
詳しくは man 5 systemd.unit
を参照。
initscripts から systemd への移行
initscripts のエミュレーション
伝統的な Arch の設定ファイルは initscripts パッケージによって使われています。systemd と initscripts がインストールされていて、systemd によってシステムが動いている時、systemd は以下のことを行います:
-
/etc/rc.conf
のDAEMONS
行をパースし、ブート時にデーモンを起動します - ブート中に
/etc/rc.local
を実行します - シャットダウン中に
/etc/rc.local.shutdown
を実行します
Initscripts のエミュレーションはユーザーが systemd に移行するのを手助けする過渡期の手段として存在しています、そして最終的には取り除かれる予定です。ネイティブな systemd は設定の中心として rc.conf
を使いません、/etc/rc.conf
が使えなくなる前にネイティブの systemd 設定ファイルを使うことを推奨します。
/etc/rc.local
を置換するには、起動時に実行したいもののカスタムサービスファイルを書くことを推奨します。このセクションに方法を記述しています。/etc/inittab
で設定していた場合、root で systemctl mask ctrl-alt-del.target
を実行して systemd でも再設定する必要があります。DAEMONS 行からの移行
純粋な systemd セットアップのためには、完全に /etc/rc.conf
ファイルを削除して systemctl
だけを使ってサービスを有効にしなくてはなりません。/etc/rc.conf
の DAEMONS
行のそれぞれの <service_name>
に対して次を実行します:
# systemctl enable <service_name>.service
<service_name>.service
が存在しない場合:
- ほとんど場合、systemd は違う名前を使っています。例えば、
crond
init デーモンはcronie.service
に、alsa
init デーモンはalsa-store.service
とalsa-restore.service
になっています。他にもnetwork
デーモンは、他のサービスファイルに置き換わっています (詳しくは Network Configuration (日本語) を見て下さい)。 - サービスファイルが systemd にない場合。その場合、起動中にサービスを作動させるのに
rc.conf
を使いつづける必要があります。
$ pacman -Ql cronie [...] cronie /etc/rc.d/crond #DAEMONS 行で使われるデーモン initscript ("純粋な" systemd では使われません) [...] cronie /usr/lib/systemd/system/cronie.service #対応する systemd のデーモンサービス [...]
- 最後に、サービスによっては、ユーザーの操作で有効にする必要がないものがあります。例えば、
dbus.service
はdbus-core
がインストールされると自動で有効にされます。alsa-store.service
とalsa-restore.service
も systemd によって自動で有効にされます。利用できるサービスと状態をチェックするにはsystemctl
コマンドを使います:systemctl status <service_name>
。
systemctl の基本的な使い方
systemd を管理したり内部情報を見るために使うメインのコマンドが systemctl
です。システムの状態を確かめたりシステムやサービスを管理するために使うのは使い方の一部です。詳しくは man 1 systemctl
を見て下さい。
systemctl
コマンドに -H <user>@<host>
を渡すと、リモートの systemd と対話できます。SSH を利用してリモートの systemd インスタンスに繋ぐのに使われます。システムの状態を分析する
実行中のユニットを一覧する:
$ systemctl
または:
$ systemctl list-units
失敗したユニットを一覧する:
$ systemctl --failed
実行可能なユニットファイルは /usr/lib/systemd/system/
や /etc/systemd/system/
にあります(後者が優先的に使われます)。インストールされたユニットを一覧するには:
$ systemctl list-unit-files
ユニットを使う
ユニットには、例えば、サービス (.service
) やマウントポイント (.mount
)、デバイス (.device
)、ソケット (.socket
) などがあります。
systemctl
を使うとき、一般的には拡張子 (suffix) を含むユニットファイルの完全な名前を指定する必要があります。例えば、sshd.socket
のように。しかし、以下のような場合には省略形が存在します:
- 拡張子が指定されない場合、systemctlは
.service
とみなします。例えばnetcfg
とnetcfg.service
は同じように扱われます。 - マウントポイントは自動的に対応する
.mount
ユニットとして扱われます。例えば、/home
を指定することはhome.mount
の指定と同じです。 - マウントポイントと同じく、デバイスも自動的に対応する
.device
ユニットとして扱われます。従って、/dev/sda2
の指定はdev-sda2.device
と同じです。
詳細は man systemd.unit
を見てください。
いますぐユニットを実行:
# systemctl start <unit>
いますぐユニットを停止:
# systemctl stop <unit>
ユニットを再始動:
# systemctl restart <unit>
ユニットに設定を再読み込みするように通知:
# systemctl reload <unit>
ユニットの状態を表示(動いているかどうかなど):
$ systemctl status <unit>
有効化(起動時に自動で実行するよう設定)されているかどうか表示:
$ systemctl is-enabled <unit>
起動時に実行されるように有効化する:
# systemctl enable <unit>
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
systemd でデスクトップ環境を動かす
グラフィカルログインを有効にするには、お好きなディスプレイマネージャデーモンを使って下さい (例: KDM)。現在、GDM, KDM, SLiM (日本語), XDM, LXDM, LightDM に対応したサービスファイルが存在します。
# systemctl enable kdm
これだけで動くはずですが、動かない場合、手動で default.target
を設定するか、前のインストールを使います:
# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target
シンボリックリンクを削除すれば systemd は保存した default.target
(つまり graphical.target
) を使うようになります。
# rm /etc/systemd/system/default.target
systemd-logind を使う
ユーザーセッションの状態を確認するには loginctl
を使います。サスペンドや外部デバイスのマウントなどの全ての PolicyKit アクションはそのまま変更せずに動きます。
$ loginctl show-session $XDG_SESSION_ID
カスタム .service ファイルを書く
参照: Systemd/Services
依存関係を解決する
systemd ではユニットファイルを適切に書くことで依存関係を解決します。一番典型的なケースは、ユニット A
が走る前に、ユニット A
がユニット B
を必要としている場合です。この場合、A
の [Unit]
セクションに Requires=B
と After=B
を加えます。依存が必然ではない場合、代わりに Wants=B
と After=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/
という名のディレクトリを作成してそのなかに *.conf
を置くことでオプションを上書きしたり追加したりすることが可能です。Systemd が *.conf
ファイルをパースして元のユニットファイルの一番上に設定を適用します。例えば、ユニットに追加の依存を入れたい時は、以下のファイルを作成します:
/etc/systemd/system/<unit>.d/customdependency.conf
[Unit] Requires=<new dependency> After=<new dependency>
そして変更を適用するために次を実行してください:
# systemctl daemon-reload # systemctl restart <unit>
または、古いユニットファイルを /usr/lib/systemd/system/
から /etc/systemd/system/
にコピーして変更を加えることもできます。/etc/systemd/system/
内のユニットファイルは /usr/lib/systemd/system/
内の同じユニットを上書きします。パッケージのアップグレードによって /usr/lib/
の元のユニットが変更されたとき、変更が /etc/
内のあなたのカスタムユニットファイルには自動では適用されないことに注意してください。さらに、変更するたびに手動で systemctl reenable <unit>
によってユニットを reenable する必要があります。したがって前述の *.conf
を使う方法のほうが推奨されます。
systemd-delta
を使うことでどのファイルが上書きされ、どこが変更されたのか調べることができます。Vim でのユニットのシンタックスハイライト
公式リポジトリから vim-systemd をインストールすることで、Vim でのユニットファイルのシンタックスハイライトが可能です。
ターゲット
Systemd はランレベルと同じことをするためにターゲットを使いますが挙動には少し違いがあります。それぞれのターゲットはナンバリングの代わりに名前がつけられ、同時に複数のことが行えるようになっています。いくつかのターゲットには、他のターゲットのサービスを全て引継ぎ、サービスを追加する機能がつけられています。一般的な SystemVinit ランレベルに擬態する systemd ターゲットもあり、親しみのある telinit RUNLEVEL
コマンドを使って使用するターゲットをスイッチすることが可能です。
現在のターゲットを獲得
systemd では runlevel
の代わりに次を使います:
$ systemctl list-units --type=target
カスタムターゲットを作る
標準の Fedora インストールではランレベルごとに特定の目的が設定されています; 0, 1, 3, 5, 6 のランレベルには指定の sytemd ターゲットと一対一の対応関係があるのです。残念ながら、2 や 4 などのユーザー定義のランレベルでそれと同じようにするベストな方法はありません。もしあなたがそうしたいならば、既に存在しているランレベルをベースに新しい systemd ターゲットを /etc/systemd/system/<your target>
として作り (/usr/lib/systemd/system/graphical.target
がサンプルになるかもしれません)、/etc/systemd/system/<your target>.wants
ディレクトリを作って、有効にしたいサービスに /usr/lib/systemd/system/
からシンボリックリンクを貼ることが示唆されています。
ターゲット表
SysV ランレベル | systemd ターゲット | Notes |
---|---|---|
0 | runlevel0.target, poweroff.target | システムを停止。 |
1, s, single | runlevel1.target, rescue.target | シングルユーザーモード。 |
2, 4 | runlevel2.target, runlevel4.target, multi-user.target | ユーザー定義・サイト指定ランレベル。デフォルトでは、3 と同一。 |
3 | runlevel3.target, multi-user.target | マルチユーザー、非グラフィカル。一般的にマルチコンソールやネットワークを介してログインするのに使われます。 |
5 | runlevel5.target, graphical.target | マルチユーザー、グラフィカル。通常、ランレベル 3 の全てのサービスにグラフィカルログインを付加。 |
6 | runlevel6.target, reboot.target | 再起動 |
emergency | emergency.target | 緊急シェル |
現在のターゲットを変更する
systemd ではターゲットは"ターゲットユニット"として表現されます。ターゲットを変えるにはこのようにします:
# systemctl isolate graphical.target
これは現在のターゲットを変えるだけで、次の起動時には影響がありません。Sysvinit での、telinit 3
や telinit 5
のようなコマンドと同じです。
起動時のデフォルトターゲットを変更する
標準のターゲットは default.target
で、デフォルトで graphical.target
(おおよそランレベル 5 と同じ)にエイリアスされています。起動するデフォルトターゲットを変更するには、以下のカーネルパラメータのどれかをブートローダに加えてください:
.target
拡張子は省くことができます。-
systemd.unit=multi-user.target
(おおよそランレベル 3 と同じ), -
systemd.unit=rescue.target
(おおよそランレベル 1 と同じ).
もしくは、ブートローダではなく default.target
を変えることもできます。systemctl
を使います:
# systemctl enable multi-user.target
このコマンドの効果は systemctl
によって出力されます; 新しいデフォルトターゲットのシンボリックリンクは /etc/systemd/system/default.target
に作成されます。ターゲットの設定ファイルに:
[Install] Alias=default.target
があるときだけこれが動作します。現在、multi-user.target
と graphical.target
がこれを持っています。
Journal
systemd は、version 38 から自前のログシステムである journal を持っています。従って、syslog デーモンを起動する必要は既にありません。ログを読むには:
# journalctl
デフォルトで(/etc/systemd/journald.conf
内で Storage=
が auto
に設定されている場合)、journal は /var/log/journal/
へ書き込みを行います。/var/log/journal/
ディレクトリは systemd の一部であり、あなたや何らかのプログラムがそれを削除した場合、systemd は自動で再作成しませんが、systemd のアップデートがあるとディレクトリは作りなおされます。それまでログは代わりに /run/systemd/journal
に書き込まれます。ただし再起動時にこのログは消失してしまいます。
フィルタリング
journalctl
を使って出力にフィルタをかけることができます。
例:
起動時からの全てのメッセージを表示:
# journalctl -b
しかしながら、見たいメッセージは現在のブートではなく、以前のブートからの情報であることがよくあります (例: リカバリーできないシステムクラッシュが起こった場合)。現在、このような機能は実装されていませんが、systemd-devel@lists.freedesktop.org で議論がなされています (September/October 2012)。
今のところ、次のコマンドで(今日の)以前のブートのメッセージを表示できます:
# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac
多くのメッセージが存在する場合、このコマンドの出力にはかなり時間がかかることがあるので注意してください。
新しいメッセージを表示:
# journalctl -f
特定の実行ファイルによる全てのメッセージを表示:
# journalctl /usr/lib/systemd/systemd
特定のプロセスによる全てのメッセージを表示:
# journalctl _PID=1
特定のユニットによる全てのメッセージを表示:
# journalctl -u netcfg
詳しくは man journalctl
, systemd.journal-fields
や Lennert の blog post を見て下さい。
journal のサイズ制限
journal が永続的(不揮発性)の場合、デフォルトではファイルシステムの容量の 10% に制限されます。例えば、/var/log/journal
が 50GiB の root パーティションにのっている場合、5GiB がログデータの上限になります。/etc/systemd/journald.conf
の SystemMaxUse
を変更すれば、最大サイズを変更できます。例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します:
SystemMaxUse=50M
詳細は man journald.conf
を参照してください。
journald と syslog の結合
古典的な syslog との互換性は、すべてのメッセージがソケット /run/systemd/journal/syslog
に転送されることで実現されます。syslog を使うには、/dev/log/
の代わりにこのソケットを指定します(公式アナウンス)。syslog-ng は必要な設定ファイルを自動的に提供します。
# systemctl enable syslog-ng
最適化
Improve Boot Performance を見て下さい。
ブートプロセスを解析する
systemd-analyze を使う
Systemd には systemd-analyze
というツールがあり、どのプロセスが起動を遅くしているのか調べるためにブートプロセスを解析することができます。それに応じてシステムを最適化することも可能です。
起動時、カーネルスペースとユーザースペースでどれくらい時間がかかっているか見るためには、シンプルに次を実行:
$ systemd-analyze
- initramfs でどれくらい時間がかかったか見るためには、
/etc/mkinitcpio.conf
のHOOKS
行にtimestamp
フックを加え、root 権限で initramfs をmkinitcpio -p linux
で再生成してください。 - UEFI でブートしていて、かつ systemd の Boot Loader Interface を実装しているブートローダ (今のところ Gummiboot のみ) を使っている場合は、systemd-analyze は EFI ファームウェアとブートローダでかかった時間も追加で表示します。
ユニットファイルを起動するのにかかった時間で並べて一覧するには:
$ systemd-analyze blame
Bootchart のように、ブートプロセスを視覚的にするために SVG ファイルを生成することもできます:
$ systemd-analyze plot > plot.svg
systemd-bootchart を使う
Bootchart は systemd にマージされ、オリジナルの bootchart と同じように使って起動ができます。カーネルラインに以下を追加してください:
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart
bootchart2 を使う
bootchart を使うことでブートシークエンスを視覚化できます。セカンド init をカーネルコマンドラインに加えることができないので、標準の bootchart セットアップはできません。しかし、AUR の bootchart2AUR パッケージにはドキュメント化されてない systemd サービスが付いています。bootchart2 をインストールした後に次を実行してください:
# systemctl enable bootchart
bootchart の使い方についての詳しい説明は bootchart documentation を読んで下さい。
Readahead
Systemd には readahead 機能があり、ほとんどの場合起動時間の短縮が望めます。しかし、どれくらい利益があるかは、あなたの使っているカーネルバージョンやハードドライブのタイプによって大きく変わります(遅くなることもあるかもしれません)。有効にするには次を実行してください:
# systemctl enable systemd-readahead-collect systemd-readahead-replay
readahed を機能させるには、何度か再起動させてやる必要があります。
トラブルシューティング
シャットダウン/再起動にものすごく時間がかかる
シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。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 のように、ソケット接続を使ってデータを流すようカーネルを変更する必要があります。
See also
- 公式ウェブサイト
- Manual Pages
- systemd Optimizations
- FAQ
- Tips And Tricks
- systemd for Administrators (PDF)
- About systemd on Fedora Project
- How to debug systemd problems
- Two part introductory article in The H Open magazine.
- Lennart's blog story
- status update
- status update2
- status update3
- most recent summary
- Fedora's SysVinit to systemd cheatsheet