openSUSE:Systemd の現状
目次
systemd との統合でやるべきことの一覧
- 既定のインストールで設定されるすべてのサービスが、 systemd ネイティブのサービスとして動作すること。
- SUSE の LSB 拡張 $ALL は現在対応していない。何らかの方法で解決する必要がある。ファイアウォールで使用?
- YaST2 のランレベルエディタを systemd に合わせて修正する必要がある。ランレベルエディタの API は他の YaST モジュールでも使用されていて、サービスの有効化/無効化/問い合わせに使われている。
- システム全体に対する ulimit (/etc/sysconfig/ulimit, /etc/initscript)?
- SUSE 固有の設定ファイルを、ディストリビューションに依存しない新しい設定形式にする: /etc/os-release, /etc/locale, /etc/tmpfiles.d/, /etc/vconsole.conf, /etc/modules-load.d/
- 現在までに見つかっているバグの修正 (下記)
有効化すべきサービスの一覧
下記に示すサービスは、いずれも既定のインストールで設定されるサービスで、 systemd でネイティブ対応されていないものの一覧です (AJ のシステムで確認したもので、すべてがそうであるとは限りません)。
- apparmor
- cycle
- ipconfig
- nfs
- ntp
- xdm
openSUSE と systemd との統合に関して、現在発生している問題とバグの一覧
これらのバグに対するご支援をお願いします:
- 12.1 での systemd バグ (英語)
- 12.2 での systemd バグ (英語)
- 12.3 での systemd バグ (英語)
- 13.1 での systemd バグ (英語)
一般的な機能追加のリクエストや SUSE 固有のものではないバグについては、 systemd のアップストリームの bugzilla (英語) に報告してください。
openSUSE のバグを報告される際は、そのバグを bnc#696902 - systemd as default boot handler bug report のブロッカーとして設定してください。
レシピ
サービスファイルの作成
サービスファイルの作成方法について、詳しくは Lennarts' systemd for admins, part 3 (英語) をお読みください。
Fedora プロジェクトでは、単純にコピーするだけで使うことのできる様々な systemd ファイルを用意しています。何もない状態から作成する前に、 Fedora と Lennart's unit files (いずれも英語) のページをご覧ください。
サービスの有効化
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
systemd と SysVinit の主な違い
systemd のゴールは、ディストリビューション間の対話であり、ディストリビューションを変更しても多くのものを共有できるようなするというものです。そのため、下記に示す変更のうちのいくつかは、システムを一体化するためのものでもあります:
- /var/run + /var/lock + /media がそれぞれ無条件に tmpfs でマウントされる
- /etc/tmpfiles.d を介してテンポラリファイルが作成されるようになる (/etc/tmpdirs.d は古い形式となる予定) (正確ではないので要修正)
- mingetty ではなく agetty が使用される
- systemd は /etc/mtab が通常のファイルである場合には対応しておらず、 /proc/self/mounts へのシンボリックリンクである必要がある。 systemd パッケージが先のリンクを作成する。また、カーネルのマウントファイルでは 'user' マウント解除には対応しておらず、プライベート mtab に対応するために util-linux 2.19+ が必要 (openSUSE 11.4 以降で対応済み)
- agetty を利用したシリアルコンソールのセットアップは systemd 内に内蔵されていて、追加の設定は不要
- 将来の systemd リリースで /etc/init.d/boot.d への対応は削除される予定。これらのファイルに対しては、大体のユニットファイルを提供するのがベスト。
- systemd では、暗号化されたパーティション (例: /home) を含め、 /etc/fstab の noauto を適切に読み込んで対応する。自動マウントに対応させるには、 noauto キーワードを削除するか、 "comment=systemd.automount" を追加する必要がある。
文書にまとめるべき質問類
パッケージング
- 私が作成しているパッケージには、デーモンのオプションを変更するための変数のみが含まれている sysconfig ファイルがあります。 systemd でもこれは使用できますか?そうだとしたら、どうすればよいですか?
- インストールされていれば既定で開始されるデーモンがあります。 systemd のファイルが含まれる新しいバージョンに更新した後はどうなりますか?既定で有効化されますか? (実際に更新を試したところ、更新後もサービスが問題なく起動できるようでしたが、更新した場合にのみ有効化され、新規インストールの際には有効化されませんか?)
- systemd のソケットアクティベーションサービスを多用するサービスについて、サービスを無効化するものの、サービスを自動的に開始するためにソケットを有効化しておきたい場合、何をすればよいでしょうか (システム設定に関して) ?特定の systemd パッケージを修正してサービスやソケットを有効化しておくことが唯一の方法でしょうか?これは妙なやり方ですし、少しわかりにくいものと思います。公式のディストリビューションパッケージを更新することなく、パッケージをインストールや更新をした際にサービスを起動する方法は、何かありますか?
- systemd の有効化されたサービスを sysvinit 版に戻す場合、 systemd で設定していた状態が反映されず、 sysvinit スクリプトを実行しても失敗してしまう場合があります (文書化する以前のバグだと思いますが) 。
systemd の使い方
ユーザおよびサードパーティ向け移行ガイド
上記までのような質問ではなく、ユーザ関連の機能や性能に関する直接的な比較は? たとえば sysVinit では、 "init S" や "init 3" のようにしてブートローダのコマンドラインで指定することができますが、 systemd ではどうすれば? また、サードパーティのスクリプト開発者などに対して、 init スクリプトとサービスファイルの機能比較などがあると望ましい。