Systemd

systemd森若和雄

この資料の位置づけ● この資料は systemdについて、Fedora 17時点での概要を説明するものです。● 間違いや気になる点などありましたら森若 (kmoriwak@redhat.com)までお知らせください。● (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 socket unit unit Conflicts Before After Service 同時に起動できないunit。 Socket 先にどちらかが起動していれば unit 別のunitは起動しない。 service両方とも起動される場合の同時に起動する場合requiredなどの socket activation時の、制約をみて片方だけで問題なければ前後関係 systemdがlistenするsocketと、起動する。通信発生時に起動されるservice unit unit Wants 同時に起動してほしいunit。 unit wantsで指定されたunitは失敗してもよい unit unit 前後関係は定義されない BindTo unitを他のunitとグループ化する。 unit unit Requires 依存するunitがfail/消滅した場合即座に停止する。同時に起動することが必要なunit。 (例: deviceとmount) requireで指定されたunitの起動がfailすると要求したunitの起動もfailする。前後関係は定義されない

unitの種類● unitには10の種類があり、unit名 ● .mount は対応する拡張子をもつ。また – マウントポイント manページも systemd.service ● .automount この3つはのように名付けられている fstabから – 自動マウントポイント● .service 自動生成する ● .swap – サービスの起動・終了 – swapエリア● .socket – ソケットによるサービス起動 ● .snapshot● .target – ある時点のunitの状態 – なにもしない。 ● .timer – 同期ポイントとして利用 – イベントからの時間経過● .device ● .path – udevによるデバイス – pathを監視

sysvinitに対応するサービス等● 仮想端末セットアップ – getty@.service, serial-getty@.service等で実装 – 端末が実際にアクセスされてから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イメージ図● cgroup, pidなど接続してきたプロセスの情報を同時に systemd-journald ログに記録 journal● 細かい精度の時計(起動時からのmonotonic, wall clock /run/systemd/ timeの両方)も記録 journal/syslog /dev/log● syslogdを利用するためロギングに、 /run/systemd/journal/syslog syslogd ロギングソケットがあればsyslog形式 daemon でフォワードする

socket activation● systemdがあらかじめsocket listen systemd 接続をlisten – 外部からの接続があると対応す unit 起動る .serviceを起動 socket – 起動したdaemonなどで処理を daemon おこなう● デーモンの起動を遅延させてサーバ起動時間を短縮● xinetdの置き換え – service名に接続情報を含めてインスタンスを作成する

systemd周辺の登場人物● dbus – systemdはdbus経由でサービスを提供します – udevや管理ツールとの通信もdbus経由です – systemdが実際のサービスの代わりにdbusのオブジェクトへの問い合わせを監視できます● udev – systemdはhotplugの置き換えとして動作します – systemdはudevからのイベント通知を検知して deviceユニットを処理します

dbus, udev, systemd関連イメージ図 dbus socket socket listen socket udevd systemd journal daemon /dev/log ロギングデバイス検出イベント等 syslogd ロギング daemon

主要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 sockets.target | | rescue.target =runlevel1.target | | _________________ | | v basic.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 daemonAfter=syslog.target 同時に実行されるなら「前」にAfter=udev.target activateされているべきunitAfter=avahi.targetAfter=dbus.target 「後」に実行されるべきunitBefore=libvirt-guests.service[Service]EnvironmentFile=-/etc/sysconfig/libvirtdExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGSExecReload=/bin/kill -HUP $MAINPIDKillMode=process# Override the maximum number of opened files ulimit設定もここで行う#LimitNOFILE=2048[Install]WantedBy=multi-user.target このunitを有効にする場合、multi-user.target で必要とされるように設置する

unitの設定例(socket起動)# cat /lib/systemd/system/cups.service[Unit] サービス本体は普通に定義Description=CUPS Printing Service[Service]ExecStart=/usr/sbin/cupsd -fPrivateTmp=true Alsoで「このunitを使う時に同時に必要とされるunit」を定義[Install]Also=cups.socket cups.pathWantedBy=printer.target# cat /lib/systemd/system/cups.socket[Unit]Description=CUPS Printing Service Sockets[Socket]ListenStream=/var/run/cups/cups.sockListenStream=631 systemdが代行してlistenするソケットの設定ListenDatagram=0.0.0.0:631 socketへ接続されるとデフォルトで同名のserviceをBindIPv6Only=ipv6-only 起動する[Install]WantedBy=sockets.target

unitの設定例(dbus起動)# cat /lib/systemd/system/colord.service[Unit]Description=Manage, Install and Generate Color Profiles[Service] typeはdbusType=dbus dbus上でのバス名を指定BusName=org.freedesktop.ColorManagerExecStart=/usr/libexec/colordUser=colord# We think that udevs AF_NETLINK messages are being filtered when# network namespacing is on.# PrivateNetwork=yesPrivateTmp=yes

パスによる設定● /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 Formasys-devices-pci...:0:0:0-block-sda-sda1.device loaded active plugged WDC_WD1600YS-18S(中略)sys-devices-virtual-net-virbr0x2dnic.device loaded active plugged /sys/devices/virtual/net/virbr0sys-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 Plsystemd-ask-password-wall.path loaded active waiting Forward Password Requests to Waaccounts-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.servicecrond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) Active: active (running) since Mon, 02 Jul 2012 18:43:54 +0900; 42minago Main PID: 3500 (crond) CGroup: name=systemd:/system/crond.service └ 3500 /usr/sbin/crond -nJul 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 computers 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/

https://twitter.com	14
https://si0.twimg.com	9
https://twimg0-a.akamaihd.net	1
http://translate.googleusercontent.com	1

Systemd

by Kazuo Moriwaka on Jul 10, 2012

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 25

Statistics

Systemd Presentation Transcript