systemd (日本語)

From ArchWiki
Revision as of 14:44, 25 December 2012 by Kusakata (Talk | contribs)

Jump to: navigation, search

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 の代替として動きます。

Note: systemd が Arch に採用された理由については、フォーラムへのこの投稿をご覧ください。

詳しくは、Wikipedia の記事本家のホームページもどうぞ。

Contents

移行前に考慮すべきこと

  • 本家のホームページで、systemd についてざっと読んでください。
  • systemd の journal システムは、syslog の機能を提供し置き換えます。ただしこれらは共存できます。下の journal についてのセクションを読んでください。
  • systemd が cronacpidxinetd の機能を代替しようとする計画がありますが、今はまだ伝統的なデーモンを使い続けることができます。
  • インタラクティブな initscript は sytemd では動きません。特に、起動時に netcfg-menu 使うことはできません

インストール

Note: 2012-10-13 からの新しいインストールメディアでは systemdsystemd-sysvcompat が両方デフォルトでインストールされます。
Note: VPS で Arch Linux を実行している場合、このページを見て下さい。

以下のセクションは systemd にまだ以降していない sysvinitinitscripts による Arch Linux のためのインストールです。

  1. systemd をインストールして kernel line に次を加えます: init=/usr/lib/systemd/systemd
  2. 完了したら、必要なサービスを systemctl enable <service_name> を使って有効にできます (大雑把に言うと DAEMONS 行に違う名前で追加するのと同じです)。
  3. システムを再起動し、systemd がアクティブになっていることを次のコマンドで確認します: cat /proc/1/commsystemd の文字が返ってくるはずです。
  4. systemd であなたのホストネームを設定します: hostnamectl set-hostname myhostname
  5. initscriptssysvinit をシステムから削除し systemd-sysvcompat をインストールしてください。
  6. もう必要なくなった init=/usr/lib/systemd/systemd パラメータを削除してください。systemd-sysvcompat がデフォルトの init になります。

追加情報

  • If you have quiet in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.
  • Adding your user to groups (optical, audio, scanner, etc.) is not necessary for most use cases with systemd. The groups can even cause some functionality to break. For example, the audio group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via POSIX ACLs on audio/video devices, and allow certain operations like mounting removable storage via udisks.
  • Removing initscripts package will break compatibility with rc.conf. Be careful if you have static network set up there or use some daemons, which are not migrated to systemd yet. See the Initscripts emulation section for more details on how the two systems can coexist.
  • If you mount LVM devices in fstab your system will wait for them and time out. Wait for the time out to happen and enter your root password in the emergency console. Then type systemctl enable lvm to enable lvm in systemd. After another reboot the lvm devices should be mountable.

ネイティブの設定

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

ホストネーム

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

# hostnamectl set-hostname myhostname

詳しくは man 5 hostnameman 1 hostnamectl を見て下さい。

ファイルの設定サンプル:

/etc/hostname
myhostname

Locale

デフォルトのシステムロケールは /etc/locale.conf で設定します。デフォルトロケールをセットするには:

# localectl set-locale LANG="de_DE.utf8"
Note: Before you set the default locale, you first need to enable locales available to the system by uncommenting them in /etc/locale.gen and then executing locale-gen as root. The locale set via localectl must be one of the uncommented locales in /etc/locale.gen.

詳しくは man 1 localectlman 5 locale.conf を見て下さい。

ファイルの設定サンプル:

/etc/locale.conf
LANG=en_US.utf8

仮想端末

仮想端末 (キーボッドマップ、コンソールフォント、コンソールマップ) の設定は /etc/vconsole.conf です:

/etc/vconsole.conf
KEYMAP=us
FONT=lat9w-16
FONT_MAP=8859-1_to_uni
Note: systemd-194 現在、KEYMAP=FONT= が空だったり設定されていない場合、ビルトインの kernel フォントと us キーマップが使われます。

キーボッドマップ(キーマップ)を設定する別の方法は:

# localectl set-keymap de

この方法なら X11 でも同じキーマップを使うように設定されます。

詳細は 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

ハードウェアクロック

Systemd はデフォルトで UTC をハードウェアクロックに使います。

Tip: システム時刻をインターネット時刻やハードウェアクロックと同期するために Network Time Protocol daemon を使うことが推奨されます。

localtime をハードウェアクロックに

If you want to change the hardware clock to use local time (STRONGLY DISCOURAGED) do: ハードウェアクロックで localtime を使うようにするには (するべきではありません):

# timedatectl set-local-rtc true

ハードウェアクロックを UTC に戻すには:

# timedatectl set-local-rtc false

警告したように、ハードウェアクロックを localtime に設定すると、夏時間の扱いで問題が生じます。 If the DST changes when your computer is off, your clock will be wrong on next boot (there is a lot more to it). Recent kernels set the system time from the RTC directly on boot, assuming that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is the root of certain weird bugs (time going backwards is rarely a good thing).

One reason for allowing the RTC to be in local time is to allow dual boot with Windows (which uses localtime). However, Windows is able to deal with the RTC being in UTC with a simple registry fix. There, it is recommended that Windows are changed to use UTC, rather than Linux to use localtime. If you make Windows use UTC, also remember to disable the "Internet Time Update" Windows feature, so that Windows don't mess with the hardware clock, trying to sync it with internet time. You should instead leave touching the RTC and syncing it to internet time to Linux, by enabling an NTP daemon, as suggested previously.

  • 詳しくは Time を見て下さい。

カーネルモジュール

現在、すべての必要なカーネルモジュールは udev によって自動でロードされます。従って、サポート外のカーネルモジュールを使おうとしない限り、設定ファイルにモジュールをロードするように書く必要はありません。しかし、ブートプロセスでモジュールをロードしたい場合や、コンピュータを正しく機能させるためにモジュールをブラックリストに加える必要があるかもしれません。

起動時にモジュールをロード

Extra kernel modules to be loaded during boot are configured as a static list in files under /etc/modules-load.d/. Each configuration file is named in the style of /etc/modules-load.d/<program>.conf. Configuration files simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is # or ; are ignored.

/etc/modules-load.d/virtio-net.conf
# Load virtio-net.ko at boot
virtio-net

See man 5 modules-load.d for more details.

/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 を見て下さい。

ブラックリスト

モジュールのブラックリストは、kmod によって扱われるので、initscripts の時と同じ方法で動作します。詳細は Module Blacklisting にあります。

ファイルシステムをマウントする

デフォルトのセットアップでは自動的に fsck が行われサービスが起動する前にファイルシステムがマウントされます。例えば、systemd は NFSSamba のようなネットワーク接続が必要なリモートファイルシステムも自動でマウントしようとします。従って /etc/fstab に明記しなくともローカル・リモードどちらのファイルシステムのマウントも問題ありません。

詳しくは man 5 systemd.mount を見て下さい。

Automount

  • If you have a large /home partition, it might be better to allow services that do not depend on /home to start while /home is checked by fsck. This can be achieved by adding the following options to the /etc/fstab entry of your /home partition:
noauto,x-systemd.automount

This will fsck and mount /home when it is first accessed, and the kernel will buffer all file access to /home until it is ready.

  • The same applies to remote filesystem mounts. If you want them to be mounted only upon access, you will need to use the noauto,x-systemd.automount parameters. In addition, you can use the x-systemd.device-timeout=# option to specify a timeout in case the network resource is not available.
  • If you have encrypted filesystems with keyfiles, you can also add the noauto parameter to the corresponding entries in /etc/crypttab. Systemd will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd doesn't have to wait for the device to become available. For example:
/etc/crypttab
data /dev/md0 /root/key noauto

LVM

If you have LVM volumes not activated via the initramfs, enable the lvm-monitoring service, which is provided by the lvm2 package:

# systemctl enable lvm-monitoring

Similarly, if you have LVM on encrypted devices mounted later during boot (e.g. from /etc/crypttab), enable the lvm-on-crypt service, which is also provided by the lvm2 package:

# systemctl enable lvm-on-crypt

acpid を systemd で置き換える

systemd は電源関連のACPIイベントを扱えます。これは、/etc/systemd/logind.confのオプションを使って設定できます。

  • HandlePowerKey : 電源ボタンが押された(システムがシャットダウンされるべき)時。
  • HandleSleepKey : スリープボタンが押された(システムがスリープすべき)時。
  • HandleLidSwitch : ラップトップのフタが閉じられた(システムがスリープすべき)時。

このオプションに設定された値によって、ログインユーザがいない時(no-session)や、アクティブなユーザセッションが1つだけの時(any-session)のみこれらのイベントが発生するようにできます。詳しくはman logind.conf を参照。 GnomeXFCE のようなデスクトップ環境は、ACPI を自前で処理するのでこのオプションは使うべきでありません。けれども、i3awesomeのようなウィンドウマネージャを単体で使用している場合、この機能をacpidの代わりに使えるでしょう。

スリープ・休止状態へのフック

systemd は systemctl suspend or systemctl hibernate を実行するときに pm-utils を使いません。 したがって、pm-utilsへのフックは無効になります。しかし、systemdには似たようなメカニズムを提供しています。イベント発生時に/usr/lib/systemd/system-sleep/以下にある全てのプログラムに二つの引数を渡して実行します。

  1. pre または post で、スリープするのか復帰するのかを表します。
  2. suspend または hibernateで、サスペンドかハイバネートかを表します。

pm-utilsと異なり、これらのスクリプトは並列に実行されます。

スリープの記録はsystemd-suspend.servicesystemd-hibernate.serviceによって記録され、journalで見ることができます。

また、スクリプトの代わりに sleep.targetsuspend.targethibernate.targetによってunitをフックしてスリープ状態にすることもできます。 詳細はman systemd.specialman systemd-sleepを参照。

/usr/lib/systemd/system-sleep/example.sh
case "$1" in
  pre )
    echo going to $2 ...
    ;;
  post )
    echo waking up from $2 ...
    ;;
esac

一時ファイル

Systemd-tmpfiles は /usr/lib/tmpfiles.d//etc/tmpfiles.d/ にある設定ファイルを読み、通常/runや/tmp以下にあるテンポラリファイル・テンポラリディレクトリの作成、内容の消去、削除などを行います。ファイル名は/etc/tmpfiles.d/<program>.confとなります。/etc/以下の設定は/usr/lib/tmpfiles.d/にある同名の設定をオーバーライドします。tmpfilesは一時ファイルを必要とするデーモンのサービスファイルに同梱されます。Sambaデーモンは/var/run/sambaをテンポラリディレクトリとして使用でき、正しいパーミッションに設定されていることを期待します。これを表すtmpfileは以下のようになります。

/usr/lib/tmpfiles.d/samba.conf
D /var/run/samba 0755 root root

しかし、tmpfiles はブート時にファイルに書き込むのにも使われます。例えば、USBデバイスからのwakeupを無効化する echo USBE > /proc/acpi/wakeup は、tmpfileで以下のように書けます。

/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE

systemdは実際には /etc/rc.localをサポートしないので、このtmpfilesを用いる方法が推奨されます。 詳細はman tmpfiles.dを参照。

Unit

unit 設定ファイルはサービス、ソケット、デバイス、(自動)マウントポイント、スワップパーティション(ファイル)、ターゲット、ファイルシステムのパス、タイマーについての設定をまとめたものです。設定の構文は XDG の .desktop を真似たもので、これは Microsoft WIndows の .ini ファイルに影響を受けています。詳しくはman systemd.unit を参照。

initscripts から systemd への移行

initscripts のエミュレーション

以前の設定ファイルrc.confとの統合は、initscriptsパッケージで提供されます。これはinitscriptsからsystemdへ移行するユーザへの暫時的な便宜として使われることを意図しています。

Note: /etc/inittab は全く使われていません。

STGR-ALT-DEL でリブートするのを /etc/inittab で無効化している人は、同じ機能をsystemd で # systemctl mask ctrl-alt-del.target と設定できます。

rc.conf

いくつかの /etc/rc.confの変数はこのグルーに認識されます。/etc/rc.conf よりも優先されて認識されるネイティブの設定ファイルに移行することが推奨されます。

サポートしている変数

  • LOCALE
  • KEYMAP
  • CONSOLEFONT
  • CONSOLEMAP
  • HOSTNAME
  • DAEMONS

サポートされていない変数

  • TIMEZONE: /etc/localtimeから設定したい地域のzoneinfoに手動でsimlinkを張ってください。
  • HARDWARECLOCK: ハードウェアクロックと時刻を参照。
  • USELVM: lvm2によって提供される lvm.service を使ってください。
  • USECOLOR
  • MODULES

systemctl の基本的な使い方

  • systemctl: systemdシステムとサービスマネージャの状態の調査とコントロール。
  • systemd-cgls: Linux control groupの階層をツリー状に再帰的に表示。
  • systemadm: グラフィカルフロントエンド。AURsystemd-ui-gitAURパッケージから利用可。

詳細はmanページを見よ。

Tip: systemctl-H <user>@<host> を渡すと、リモートのsystemdと対話できます。SSHを利用してリモートのインスタンスにつないでいます。

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

実行中のユニットを一覧するには、

$ 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は同じに扱われる。
    Note: 現在、この省略はenabledisableには使えない
  • マウントポイントは対応する .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セクションがない場合、たいてい自動的に他のサービスから呼ばれる。 しかし、手動でのインストールが必要なら以下のコマンドを使う。
# ln -s /usr/lib/systemd/system/<unit>.service /etc/systemd/system/graphical.target.wants/

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

# systemctl disable <unit>

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

$ systemctl help <unit>

電源管理

ローカルのConsoleKitのユーザーセッション中で、他のセッションがアクティブでなければ、ルート権限なしで次のコマンドが使える。そうでなければ、(他のユーザがttyでログインしているとか)systemdは自動的にrootのパスワードを要求するだろう。

再起動

$ systemctl reboot

シャットダウンして電源断

$ systemctl poweroff

シャットダウンして停止

$ systemctl halt

サスペンド(待機)

$ systemctl suspend

ハイバネート(休止)

$ systemctl hibernate

Running DEs under systemd

To enable graphical login, run your preferred Display Manager daemon (e.g. KDM). At the moment, service files exist for GDM, KDM, SLiM, XDM, LXDM and LightDM.

# systemctl enable kdm

This should work out of the box. If not, you might have a default.target set manually or from a older install:

# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

Simply delete the symlink and systemd will use its stock default.target (i.e. graphical.target).

# rm /etc/systemd/system/default.target

Using systemd-logind

Note: As of 2012-10-30, ConsoleKit has been replaced by systemd-logind as the default mechanism to login to the DE.

In order to check the status of your user session, you can use loginctl. All PolicyKit actions like suspending the system or mounting external drives will work out of the box.

$ loginctl show-session $XDG_SESSION_ID

Writing custom .service files

See: Systemd/Services

Handling dependencies

With systemd, dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit A requires the unit B to be running before A is started. In that case add Requires=B and After=B to the [Unit] section of A. If the dependency is optional, add Wants=B and After=B instead. Note that Wants= and Requires= do not imply After=, meaning that if After= is not specified, the two units will be started in parallel.

Dependencies are typically placed on services and not on targets. For example, network.target is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since network.target is started anyway.

Type

There are several different start-up types to consider when writing a custom service file. This is set with the Type= parameter in the [Service] section. See man systemd.service for a more detailed explanation.

  • Type=simple: systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
  • Type=forking: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify PIDFile= as well so systemd can keep track of the main process.
  • Type=oneshot: This is useful for scripts that do a single job and then exit. You may want to set RemainAfterExit=yes as well so that systemd still considers the service as active after the process has exited.
  • Type=notify: Identical to Type=simple, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by libsystemd-daemon.so.
  • Type=dbus: The service is considered ready when the specified BusName appears on DBus's system bus.

Replacing provided unit files

The unit files in /etc/systemd/system/ take precedence over the ones in /usr/lib/systemd/system/. To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from /usr/lib/ to /etc/ and make your changes there. Alternatively you can use .include to parse an existing service file and then override or add new options. For example, if you simply want to add an additional dependency to a service file, you may use:

/etc/systemd/system/<service-name>.service
.include /usr/lib/systemd/system/<service-name>.service

[Unit]
Requires=<new dependency>
After=<new dependency>

Then run the following for your changes to take effect:

# systemctl reenable <unit>
# systemctl restart <unit>
Tip: You can use systemd-delta to see which unit files have been overridden and what exactly has been changed.
As the provided unit files will be updated from time to time, use systemd-delta for system maintenance.

Syntax highlighting for units within Vim

Syntax highlighting for systemd unit files within Vim can be enabled by installing vim-systemd from the official repositories.

ターゲット

Systemd uses targets which serve a similar purpose as runlevels but act a little different. Each target is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some targets are implemented by inheriting all of the services of another target and adding additional services to it. There are systemd targets that mimic the common SystemVinit runlevels so you can still switch targets using the familiar telinit RUNLEVEL command.

Get current targets

The following should be used under systemd instead of runlevel:

$ systemctl list-units --type=target

Create custom target

The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific systemd target. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named systemd target as /etc/systemd/system/<your target> that takes one of the existing runlevels as a base (you can look at /usr/lib/systemd/system/graphical.target as an example), make a directory /etc/systemd/system/<your target>.wants, and then symlink the additional services from /usr/lib/systemd/system/ that you wish to enable.

Targets table

SysV Runlevel systemd Target Notes
0 runlevel0.target, poweroff.target Halt the system.
1, s, single runlevel1.target, rescue.target Single user mode.
2, 4 runlevel2.target, runlevel4.target, multi-user.target User-defined/Site-specific runlevels. By default, identical to 3.
3 runlevel3.target, multi-user.target Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5 runlevel5.target, graphical.target Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.
6 runlevel6.target, reboot.target Reboot
emergency emergency.target Emergency shell

Change current target

In systemd targets are exposed via "target units". You can change them like this:

# systemctl isolate graphical.target

This will only change the current target, and has no effect on the next boot. This is equivalent to commands such as telinit 3 or telinit 5 in Sysvinit.

Change default target to boot into

The standard target is default.target, which is aliased by default to graphical.target (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following kernel parameters to your bootloader:

Tip: The .target extension can be left out.
  • systemd.unit=multi-user.target (which roughly corresponds to the old runlevel 3),
  • systemd.unit=rescue.target (which roughly corresponds to the old runlevel 1).

Alternatively, you may leave the bootloader alone and change default.target. This can be done using systemctl:

# systemctl enable multi-user.target

The effect of this command is outputted by systemctl; a symlink to the new default target is made at /etc/systemd/system/default.target. This works if, and only if:

[Install]
Alias=default.target

is in the target's configuration file. Currently, multi-user.target and graphical.target both have it.

Journal

systemd は、version 38から自前のログシステム journal を持っています。

デフォルトでは、syslogdを起動する必要はもうありません。ログを読むには、

# journalctl

とします。 journal は /run/systemd/journalへ書き込むのでリブートすると消えます。 非揮発性のログを残すには、/var/log/journal/を作成してください。

# mkdir /var/log/journal/

Filtering output

journalctlは出力をフィルタすることができます。

ログを吐いたプロセスの実行ファイルのパスによるフィルタ

# journalctl /usr/lib/systemd/systemd

ログを吐いたプロセスによるフィルタ

# journalctl _PID=1

unitによるフィルタ。

# journalctl _SYSTEMD_UNIT=netcfg.service

詳細はman journalctlsystemd.journal-fields にあります。

journal のサイズ制限

不揮発性のログを取る場合、デフォルトでファイルシステムの大きさの10%に制限されます。例えば/var/log/journalが50GiBのルートパーティションにあった場合、5GiBがログデータの上限になります。/etc/systemd/journald.confSystemMaxUseを変更すれば、この制限を変更できます。

SystemMaxUse=50M

詳細はman journald.confにあります。

journald と syslog の結合

syslogとの互換性は、すべてのメッセージがソケット/run/systemd/journal/syslogに転送されることで提供されます。syslogを使うには、/dev/log/の代わりにこのソケットを指定します。(systemdによるアナウンス) syslog-ngは、設定ファイル/etc/syslog-ng/syslog-ng.confsource srcセクションを

source src {
    unix-dgram("/run/systemd/journal/syslog");
    internal();
    file("/proc/kmsg");
};

と変更し、systemdでsyslog-ngを有効化します。

# systemctl enable syslog-ng.service

最適化

See Improve Boot Performance.

Analyzing the boot process

Using systemd-analyze

Systemd provides a tool called systemd-analyze that allows you to analyze your boot process so you can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly. You have to install python2-cairo and python2-gobject to use it.

To see how much time was spent in kernelspace and userspace on boot, simply use:

$ systemd-analyze
Tip: To see how much time was spent in the initramfs, append the timestamp hook to your HOOKS array in /etc/mkinitcpio.conf and as root, rebuild your initramfs with mkinitcpio -p linux

To list the started unit files, sorted by the time each of them took to start up:

$ systemd-analyze blame

You can also create a SVG file which describes your boot process graphically, similiar to Bootchart:

$ systemd-analyze plot > plot.svg

Using bootchart

You could also use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the bootchart2AUR package from AUR comes with an undocumented systemd service. After you've installed bootchart2 do:

# systemctl enable bootchart

Read the bootchart documentation for further details on using this version of bootchart.

Readahead

Systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:

# systemctl enable systemd-readahead-collect systemd-readahead-replay

Remember that in order for the readahead to work its magic, you should reboot a couple of times.

トラブルシューティング

"Error: No space left on device" when trying to start/restart a service

Note: I don't know if this is a proper solution, but it seems to have worked for me (I didn't use the same value as they said to, however).

See this link: CrashPlan Support

Thanks to Fedora Forum for pointing me to this site.

Shutdown/reboot takes terribly long

If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. Systemd waits some time for each service to exit before trying to kill it. To find out if you are affected, see this article.

Short lived processes don't seem to log any output

If systemctl -u foounit.service doesn't show any output for a short lived service, look at the PID instead. For example, if systemd-modules-load.service fails, and systemctl status systemd-modules-load shows that it ran as PID 123, then you might be able to see output in the journal for that PID, i.e. journalctl -b _PID=123. Metadata fields for the journal such as _SYSTEMD_UNIT and _COMM are collected asynchronously and rely on the /proc directory for the process existing. Fixing this requires fixing the kernel to provide this data via a socket connection, similar to SCM_CREDENTIALS.

See also