Systemd

systemd

森若和雄

この資料の位置づけ

● この資料は systemdについて、Fedora 17時点での概要を説明するものです。

● 間違いや気になる点などありましたら森若([email protected])までお知らせください。

● (RHEL7にsystemdが同梱されることが発表されましたが、)この資料はRHEL7についてのものではありません。

agenda

● systemdってなにもの？● systemdの「unit」● unitの設定・種類● 以前からある実装に対応したsystemdの各種サービス● 主要なtargetと依存関係● unitの例● 管理用のユーザインタフェース

– systemctl

– systemadm

● 管理上の違いや問題になりそうな点

systemdってなにもの？● (基本的には) initの再実装● sysvinitのサービス起動の仕組みを作り直し

– rc.sysinitでおこなわれていたmoduleロードやコンソールの設定も行い● ConsoleKitが行っていたセッション管理も行い● サービスやセッション毎にcgroupを作成・設定し● ハードウェア認識時のサービス起動も統合してhotplugを置き換え● syslogd起動前のログも取りたいのでjournalを作り● xinetdを置換え、サービスを遅延起動するsocket activationを実装し

– socketだけでなくdbusオブジェクトや指定パスの状態監視も可能にし● suspend/hibernate/resumeを統合し● rescue/emergencyも含んで● automountやcryptsetupも管理するようにしたすごいやつ

unit

● サービスなどの定義はsysvinitのようなシェルスクリプトではなくunitとよばれる設定ファイルで定義する

● unitは実行可能ではなくsystemdがロードして実際の処理を行う。– アドホックなシェルスクリプトの改変によるカスタマイズが全くできない– 大抵の場合に必要な条件チェックやリソース設定等が用意されている

● start/stopを順に実施していくsysvinitとは異なり、unitは並列に処理される。

● xinetdがサービスのかわりにsocketを待つように、systemdが{socket, device, path, dbus}を待つことができる。– 何をどういう設定で待つかをunitで定義– 接続された時に起動するサービスもunitで定義

● unit間の依存などの関係も定義する

unit間の関係(の代表的なもの)unit

unit

socket

service

unitunit

unit

unit

unit unit

unit

Before After

両方とも起動される場合の前後関係

Service Socket

socket activation時の、systemdがlistenするsocketと、通信発生時に起動されるservice

BindTo

unitを他のunitとグループ化する。依存するunitがfail/消滅した場合即座に停止する。(例: deviceとmount)

Wants同時に起動してほしいunit。wantsで指定されたunitは失敗してもよい前後関係は定義されない

Requires

同時に起動することが必要なunit。requireで指定されたunitの起動がfailすると要求したunitの起動もfailする。前後関係は定義されない

unit unitConflicts

同時に起動できないunit。先にどちらかが起動していれば別のunitは起動しない。同時に起動する場合requiredなどの制約をみて片方だけで問題なければ起動する。

unitの種類● unitには10の種類があり、unit名

は対応する拡張子をもつ。またmanページも systemd.serviceのように名付けられている

● .service

– サービスの起動・終了● .socket

– ソケットによるサービス起動● .target

– なにもしない。– 同期ポイントとして利用

● .device

– udevによるデバイス

● .mount

– マウントポイント● .automount

– 自動マウントポイント● .swap

– swapエリア● .snapshot

– ある時点のunitの状態● .timer

– イベントからの時間経過● .path

– pathを監視

この3つはfstabから自動生成する

sysvinitに対応するサービス等

● 仮想端末セットアップ– [email protected], [email protected]等で実装– 端末が実際にアクセスされてからagettyを起動

● runlevel

– 互換性のため runlevelN.target が用意されている– デフォルトrunlevelにはdefault.targetが対応

● shutdown

– systemd-shutdownd.service で実装

rescue/emergency target

● カーネルコマンドライン systemd.unit= でターゲットを指定することで任意のtargetを起床する(何も指定しないとdefault.target)

● rescueとemergencyの違い– rescue.target: 基本的なシステムは構成されている

状態。従来のsingle user modeに相当– emergency.target: 障害時用で他のunitが失敗して

いても起動できる。root fsのmountに失敗するなど

fstab, automountの置き換え

● .mount, .automount, .swap unitはunitを明示的に作成しなくても、fstabを解析してunitを自動生成する

● /homeをマウントするunitは home.mount のようにマウントポイントから対応するunitの名前が生成される

● fstab中に"x-systemd.automount"というマウントオプションを記述しておくとautomountの指定として処理される

hotplugの置き換え

● udevからデバイスが検出されると .device ユニットが生成される

● 上記イベントで依存関係が満たされたユニットを起動する– 例: ブロックデバイスを検出すると対応するマウ

ントポイントをマウントする– 例: USBプリンタ接続を検出するとcupsd.service

を起動する

ConsoleKitの置き換え

● systemd-logind.service

– seat管理、ユーザセッション管理– dbus経由でConsoleKitと同じサービスに見える

● pam_systemd でユーザセッションをsystemd-logindへ登録する

● loginctlでセッション管理● ユーザセッション毎にcgroupを切り替え

ロギング

● systemd-journald でソケット /dev/log 経由のロギングを実施。– 従来のsyslogdへの窓口となっていたソケット

● デフォルトのシステムログ出力先は以下– /run/log/journal/(machine-id)/system.journal

– バイナリ形式で、ユーザ入力部とsystemd-journaldが生成する固定フィールドがある

– 永続化が必要な場合は/var以下に移行できる● journalctlでログの検索・表示をおこなう● machine-idはホスト識別用128bit16進数

systemd.journalイメージ図

systemd-journald

daemon

/dev/log

ロギングsyslogd

ロギング

journal

● cgroup, pidなど接続してきたプロセスの情報を同時にログに記録

● 細かい精度の時計(起動時からのmonotonic, wall clock timeの両方)も記録

● syslogdを利用するために、 /run/systemd/journal/syslog ソケットがあればsyslog形式でフォワードする

/run/systemd/journal/syslog

socket activation

● systemdがあらかじめsocketをlisten

– 外部からの接続があると対応する .serviceを起動

– 起動したdaemonなどで処理をおこなう

● デーモンの起動を遅延させてサーバ起動時間を短縮

● xinetdの置き換え– service名に接続情報を含めてイ

ンスタンスを作成する

systemd

socket

listenlisten

daemon

unit 起動

接続

systemd周辺の登場人物

● dbus

– systemdはdbus経由でサービスを提供します– udevや管理ツールとの通信もdbus経由です– systemdが実際のサービスの代わりにdbusのオブ

ジェクトへの問い合わせを監視できます● udev

– systemdはhotplugの置き換えとして動作します– systemdはudevからのイベント通知を検知して

deviceユニットを処理します

dbus, udev, systemd関連イメージ図

systemdudevd

dbus

デバイス検出イベント等

socketlisten

daemon

/dev/log

ロギングsyslogd

ロギング

listen

journal

daemon

socketsocket

主要targetと依存関係(1/2)local-fs-pre.target | v(various mounts and (various swap (various cryptsetup fsck services...) devices...) devices...) (various low-level (various low-level | | | services: udevd, API VFS mounts: v v v tmpfiles, random mqueue, configfs, local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...) | | | | | \__________________|_________________ | ___________________|____________________/ \|/ v sysinit.target | _________________/|\___________________ / | \ | | | v | v (various | rescue.service sockets...) | | | | v v | rescue.target sockets.target | | | \_________________ | \| v basic.target | __________________________________/| / | |

=runlevel1.target

unitのディレクトリ構成

● /lib/systemd/{system, user}

– パッケージで配置されるるunitファイル● /run/systemd/{system, user, generator}

– 動的に生成されたunitファイル置き場– rc.localをよびだすもの、fstabから生成されるもの

等● /etc/systemd/{system, user}

– 編集・設定されたunitファイル。/usr/libより優先

systemdのunitに特徴的な設定● 依存関係をあらわす指定

– Before, After, Requires, Wants, Conflictsなど– 失敗した時に依存するものが失敗するか等の違いでいろいろ

● socket activation

– socketのlistenをsystemdでおこない、接続がきた時点でサービスを起動しはじめ、サービスにひきつぐ

● dbus activation

– socketと同様にdbusの待ち受け● path-based activation

– 指定されたpathを監視して設定したイベントがあれば起動

unitの設定例(targetにひもづけ)

# cat /lib/systemd/system/libvirtd.service

[Unit]

Description=Virtualization daemon

After=syslog.target

After=udev.target

After=avahi.target

After=dbus.target

Before=libvirt-guests.service

[Service]

EnvironmentFile=-/etc/sysconfig/libvirtd

ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS

ExecReload=/bin/kill -HUP $MAINPID

KillMode=process

# Override the maximum number of opened files

#LimitNOFILE=2048

[Install]

WantedBy=multi-user.target

同時に実行されるなら「前」にactivateされているべきunit

「後」に実行されるべきunit

ulimit設定もここで行う

このunitを有効にする場合、multi-user.targetで必要とされるように設置する

unitの設定例(socket起動)# cat /lib/systemd/system/cups.service

[Unit]

Description=CUPS Printing Service

[Service]

ExecStart=/usr/sbin/cupsd -f

PrivateTmp=true

[Install]

Also=cups.socket cups.path

WantedBy=printer.target

# cat /lib/systemd/system/cups.socket

[Unit]

Description=CUPS Printing Service Sockets

[Socket]

ListenStream=/var/run/cups/cups.sock

ListenStream=631

ListenDatagram=0.0.0.0:631

BindIPv6Only=ipv6-only

[Install]

WantedBy=sockets.target

サービス本体は普通に定義

Alsoで「このunitを使う時に同時に必要とされるunit」を定義

systemdが代行してlistenするソケットの設定socketへ接続されるとデフォルトで同名のserviceを起動する

unitの設定例(dbus起動)

# cat /lib/systemd/system/colord.service

[Unit]

Description=Manage, Install and Generate Color Profiles

[Service]

Type=dbus

BusName=org.freedesktop.ColorManager

ExecStart=/usr/libexec/colord

User=colord

# We think that udev's AF_NETLINK messages are being filtered when

# network namespacing is on.

# PrivateNetwork=yes

PrivateTmp=yes

dbus上でのバス名を指定

typeはdbus

パスによる設定

● /etc/systemd/以下のディレクトリに配置されるファイルやリンクの配置により設定が表現される

● 例:

– /etc/systemd/system/default.target がデフォルトのターゲット。 runlevel5.targetへのリンクになっている

– /etc/systemd/system/multi-user.target.wants/ 以下にユニットへのリンクを貼ることで、multi-user.targetのWants=に設定したのと同等の効果がある

– /etc/systemd/system/foo.serviceを/dev/nullへのリンクにすることで /lib/systemd/system/foo.service を無効化する

● 不要サービスを止めたい時に有効

ユーザインタフェース

● systemctl

– systemdに対するリクエスト発行および状態取得の全般をあつかう

● bash auto complete同梱、ページャ自動起動など便利

– unitの操作: 一覧、状態取得、起動、終了、再起動, enable/disable, mask/unmask

– 状態操作: isolate, snapshot

– ショートカット用コマンド: rescue, emergency, halt, reboot, poweroff

GUIもあります (systemadm)

systemctl でアクティブなunit一覧UNIT LOAD ACTIVE SUB JOB DESCRIPTIONnet-binaries.automount loaded active waiting net-binaries.automountproc-sys-fs-binfmt_misc.automount loaded active waiting Arbitrary Executable File Formats File System Asys-devices-pci...:0:0:0-block-sda-sda1.device loaded active plugged WDC_WD1600YS-18S(中略)sys-devices-virtual-net-virbr0\x2dnic.device loaded active plugged /sys/devices/virtual/net/virbr0-nicsys-module-configfs.device loaded active plugged /sys/module/configfssys-module-fuse.device loaded active plugged /sys/module/fuse-.mount loaded active mounted /boot.mount loaded active mounted /bootdev-hugepages.mount loaded active mounted Huge Pages File Systemdev-mqueue.mount loaded active mounted POSIX Message Queue File Systemhome.mount loaded active mounted /homemedia.mount loaded active mounted Media Directoryproc-fs-nfsd.mount loaded active mounted RPC Pipe File Systemrun-user-kmoriwak-gvfs.mount loaded active mounted /run/user/kmoriwak/gvfssrv-sources.mount loaded failed failed /srv/sourcessys-fs-fuse-connections.mount loaded active mounted FUSE Control File Systemsys-kernel-config.mount loaded active mounted Configuration File Systemsys-kernel-debug.mount loaded active mounted Debug File Systemvar-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File Systemcups.path loaded active waiting CUPS Printer Service Spoolsystemd-ask-password-plymouth.path loaded active waiting Forward Password Requests to Plymouth Directorysystemd-ask-password-wall.path loaded active waiting Forward Password Requests to Wall Directory Wataccounts-daemon.service loaded active running Accounts Serviceacpid.service loaded active running ACPI Event Daemonatd.service loaded active running Job spooling toolsauditd.service loaded active running Security Auditing Service

ユニット名ユニットの状態ユニットの説明

systemctl statusでサービス状態確認

# systemctl status crond.service

crond.service - Command Scheduler

Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled)

Active: active (running) since Mon, 02 Jul 2012 18:43:54 +0900; 42min ago

Main PID: 3500 (crond)

CGroup: name=systemd:/system/crond.service

└ 3500 /usr/sbin/crond -n

Jul 02 18:43:55 dragon.nrt.redhat.com /usr/sbin/crond[3500]: (CRON) INFO (running with inotify support)

Jul 02 18:43:55 dragon.nrt.redhat.com /usr/sbin/crond[3500]: (CRON) INFO (@reboot jobs will be run at computer's startup.)

systemdが管理するサービスの属性

● 実行ファイル● 各サービスの定義から自動生成された依存関係● 提供するdbus オブジェクトやsocketのパスなど● cgroup● rlimit(ulimit), oom_score_adj, nice

● 開始時刻● などなど。

詳細を確認したい場合は以下のコマンド

systemctl show xxx.service

サービス管理で違いがでるところ● cgroupで管理するので

– 子プロセスを確実に殺せる● killする対象を、cgroupに属する全プロセスとするか、代表プロセスのみに

するかなどを選択可能

– 利用時間などをサービス単位で観測できる● systemd-cgtop でcgroup毎のCPU利用状況などが観測できる

– CPUやメモリの制限をサービス毎に詳細に設定できる● oom scoreやulimitの調整にdirty hackが不要● 依存関係を解決してから起動する

– 解決できないときには起動しない● ログの管理をしているためそのサービスの直近のログを状態

とともに確認できる

問題となる可能性のあるところ● service, chkconfigなどのコマンドの動作が変わるので手順書の更新が必要● socket activationのため、単純なPID監視がうまくいかない● サーバ起動時にサーバプロセスを必ず起動しておきたいものはmulti-

user.target.wants 等に登録しておく必要がある– 依存関係により必要になるまで起動しない可能性がある

● sysvinitのスクリプトを利用してサービスの起動・終了を実施するプログラムに問題がでる。具体的にはHAクラスタミドルウェアや運用監視ツール。– Pacemakerはsystemdのunitを管理対象にできるらしい

● 全ての操作にデフォルトで5分のタイムアウトが設定されている。無制限に設定することも可能だがサービス終了などで長時間待つ必要がある場合、個別にunitを設定・確認しないと問題になりうる

● start/stop/status/reload/restart以外の個別のコマンドは設定できない– sysvinitのスクリプト中でカスタムコマンドを作成している場合別途管理コマンドを作

成する必要がありそう

まめちしき

● systemdが監視しているサービスの状態をとるプログラム的な方法はdbusを使った問い合わせだが、ちょちょいとhackしたいときは……– systemctl status xxxx.service の出力をparseしようとする

と大変– そういうときはsystemctl show xxxx.service の出力のほう

がparseしやすい● ドキュメントは全て以下から辿れます:

– http://www.freedesktop.org/wiki/Software/systemd/

Systemd

Technology

Transcript of Systemd