blog移転してます

なにかの誤検出でブログをまるっと消されたり、申請して回復したと思ったらまた消されたりしてうんざりしてしまったのでbloggerの利用をやめてはてなブログに移転することにしました。

移転先はこちら →  https://mrwk.hateblo.jp/

Fedora Modularity雑感

Fedora 29でデフォルトmodularityが入ってきたのでちょっと触った感触をメモ。30分くらいしかいじってないので間違いがあったら教えてください。

• dnf module list でモジュール一覧がでてくる

# dnf module list
firmware for qemu, built by jenkins, fresh from git repos                                             2.4 kB/s | 2.9 kB     00:01    
Fedora Modular 29 - x86_64
Name             Stream         Profiles                                   Summary                                                    
ant              1.10           default [d]                                Java build tool                                            
avocado          latest         minimal, default                           Framework with tools and libraries for Automated Testing   
avocado          stable         minimal, default                           Framework with tools and libraries for Automated Testing   
container-tools  2017.0         default                                    Common tools and dependencies for container runtimes       
container-tools  2018.0         default                                    Common tools and dependencies for container runtimes       
cri-o            1.11           default                                    Kubernetes Container Runtime Interface for OCI-based contai
                                                                           ners
cri-o            2017.0         default                                    Kubernetes Container Runtime Interface for OCI-based contai
                                                                           ners
cri-o            2018.0         default                                    Kubernetes Container Runtime Interface for OCI-based contai
                                                                           ners
django           1.6            python2_development, default [d]           A high-level Python Web framework                          
docker           2017.0         default                                    Module for docker runtime and docker-distribution          
dwm              6.0            user, default [d]                          Dynamic window manager for X                               
dwm              6.1 [d]        user, default [d]                          Dynamic window manager for X                               
dwm              latest         user, default [d]                          Dynamic window manager for X                 

• moduleは実際上小さなリポジトリ。ただしmoduleを有効にしないとパッケージを取得できない。
• dnf module enable dwm:6.0 のようにmodule を有効にする
• リポジトリからmoduleへweak referenceが貼られて、インストール時の解決に使われるようになるイメージ
• dnf module disable をしてもweak refがかわるだけで今はいっているパッケージに影響はない
• dnf module enable をしてもweak refがかわるだけで今はいっているパッケージと競合するとしても特に警告などはない
• dnf module remove をすると指定したmoduleに属するパッケージを削除できる。
• moduleのenable/disableがrpmパッケージ群の状態と独立しているので……
• moduleを切り替えながらいろいろやるとバージョンが混在して依存関係解決がむずかしい
• rpmの別バージョンを同時にはインストールできない制約は有効なので致命的に壊れることはない
• 実用上はmoduleのバージョン切り替えをしたい場合はremoveするしかなさそう。

良い点: 今のRHSCLよりはまともな仕組みなのでhackyなshell scriptsが排除される。

悪い点: 同時にインストールできないからSoftware Collectionsより能力としては劣化してる。modularityの人はそういうときはコンテナ使えばいいと言っている。

予想されるまずいケース: rpmfindなりISV提供なりでmodularityを考慮していないrpm入れる→しばらくしたあとmoduleを使おうとする→moduleと競合する→わけがわからなくなる

/proc/1/io を見るとsystemdがすごくI/Oしてそうに見える件メモ

/proc/1/io を見ると systemdがI/O大量にやっている(ように見える)のが腑におちなくてちょっとしらべました。

task_io_accounting_add という関数があってioの集計情報を足すのですが
その関数がexit時によばれて子プロセスのio統計が親プロセスに加算されるようです。

linux-3.10.0-862.fc24.x86_64/kernel/exit.c
内で、
release_task → __exit_signal → task_io_accounting_add という順に呼ばれています。

動作を確認するため簡単に実験しました。bashからddを実行するとそのあとにwrite_bytesが100MiBくらい増えて統計情報だけみるとbashがI/Oしたかのようにみえるのがわかります。

snake:~$ cat /proc/$$/io
rchar: 4569105
wchar: 4335
syscr: 2875
syscw: 60
read_bytes: 0
write_bytes: 4096
cancelled_write_bytes: 0
 

snake:~$ dd if=/dev/zero of=/var/tmp/foo bs=1MiB count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.0308119 s, 3.4 GB/s
 

snake:~$ cat /proc/$$/io
rchar: 109501412
wchar: 104862679
syscr: 3095
syscw: 249
read_bytes: 8192
write_bytes: 104861696
cancelled_write_bytes: 0

Red Hat Identity Management or FreeIPA 利用前にチェックするべき項目

クライアントについて:

• OSは何で何台か?
  • クライアント側がサポートされるのはRHELの場合のみ

• SSSDが利用できるOS

• → SSSDのバージョンにより利用できる機能がかわるので要確認

• SSSDが利用できないOS

• → LDAP、Kerberosで接続できるがあまりスケールしないので要注意

サーバについて:

• 必要サーバ数について
  • 最低2システムは必要
    • IdMが壊れると全システムに影響するため可用性対策として必要
    • ネットワーク的にとても近い場合をのぞけば 2 × データセンタ数 あるとよい
    • マルチマスタレプリケーションによるActive-Active構成が基本
  • 1サーバあたり目安としてはクライアント2000〜3000台程度
  • サポート上限は60台

• サーバ構成について
  • 物理サーバ・仮想サーバのどちらでもよい
  • メモリ量の目安
    • For 10,000 users and 100 groups: at least 3 GB of RAM and 1 GB swap space
    • For 100,000 users and 50,000 groups: at least 16 GB of RAM and 4 GB of swap space
  • IPv6を有効にすることが必須
  • サーバはFQDN必須
  • サーバはDNSの正引き逆引きが可能であること
  • RHEL 7の最新での構築を推奨
  • SELinuxをenforcingで利用することを推奨
  • ※ コンテナ対応は現在のところtechnology preview

利用したい機能を決める:

• DNS
  • IdM内蔵のDNSを利用するか、外部のDNSを利用するか
  • 内蔵DNSを使う場合、root zoneをもたせるかどうか
  • クライアントからIdMの自動検出・自動冗長化、ドメイン参加による自動登録が可能

• OTP
  • IdM内蔵のHOTP/TOTPか、サードパーティOTPソリューションをRADIUSで統合か

• スマートカード認証
  • ドキュメントに動作確認済みスマートカード一覧があるので確認する

• パスワードポリシー設定

• DNS
  • 自動ディスカバリ、負荷分散に必要
  • 利用を推奨

• CA局
  • サービスとユーザ用
  • 外部CA局から発行された証明書を利用するか?
  • CA局は必ず2つ以上作成する

• SSH公開鍵配布
  • ホストのfinterprintをDNSで配るかLDAPで配るか決める

• sudoer配布
  • SSSDによるキャッシュが必須(RHEL 7.0+, 6.6+)

• NFS automount mapping

• HBAC

• Active Directory とのCross realm trustによるWindowsからのSSO
  • ADとIdMは別のドメインである必要がある

• Webアプリケーションの認証統合
  • 同一ドメインのみ
  • 別ドメインの場合はRed Hat SSOなどを利用したOpenID ConnectやSAMLでの接続を検討する

NG:

• ロードバランサによる負荷分散はしない(サポート対象外)
  • 通常はDNSで行うので不要。DNS利用できない場合はクライアント側SSSDにサーバを列挙

• 1台だけで構築しない

• ADや既存の他Kerberosと同じドメインにしない

• 一部のパッケージだけを更新しない。更新するときは全てを更新する。

深夜systemd雑談

深夜に某IRCでsystemdの話してたのをちょっと編集したログ

 コマンドオプション順序

ar*******> sudo systemctl hogehoge start にしてほしかった
moriwaka> sudo service hogehoge start とすればいいんじゃないかな
moriwaka> LSBにserviceがある限りたぶん永遠に残るよ
ar*******> なるほど
ar*******> service 使えばいいのはわかるんだけど、systemctl が service と記述順を違えたのはなんでかしら
ca***> command subcommand ... という書式で統一したかったとか?
moriwaka> command subcommand object にしたかったんでしょうなあ
moriwaka> shellの補完と相性よさそうだし
ar*******> stop して start してとかやるときの編集がめんどい
pl*****> コマンド順はあんまり気にならないんだけど、
pl*****> systemctl start hogehoge してから systemctl status hogehogeするのがたまにダルイ
ar*******> それ
moriwaka> わかる
ar*******> history 編集するときカーソル移動だるい
moriwaka> 僕もctrl-w で1 word消すのが癖になってるから今でも編集ミスるわ
pl*****> unit自分で書いてると頻繁にそれやるからつかれる
ar*******> カーソル移動の時間が積もり積もって過重労働に
moriwaka> Alt-Bとか使えばいいんだけど手癖がなあ……

Restartの契機

pl*****> 最近はまったのはRestart=(OnFailure=だったかな？)がType=simpleじゃないと機能しないこと
pl*****> simpleだと機能してoneshotだとダメなんだったっけ
pl*****> 忘れっちった
pl*****> コマンドをサービス化してるのでなるべくoneshot使ってるんだけど、typeによって使えない機能があったりするのは知らなかった・・・
moriwaka> oneshotだとprocessがexitするの想定された動作だから
moriwaka> processがexitしててもserviceとしてはactiveでrestart動かないのはまあそうかなという気持ち
pl*****> うむー
pl*****> 確かにそう言われるとそういうもんか

Conditionほげほげが好き

moriwaka> Conditionalなんとか が割と好きで、どの条件で失敗したかstatusで見えると「おお…… 進歩してる……」って感じになる
pl*****> conditionalって何？
moriwaka> Conditionなんとかか。ConditionPathExists= とか
pl*****> ConditionPathExistsとかか
pl*****> あれ便利なので多様してる〜

バイナリログつらい

ts******> systemdのユニットファイルなどは使いやすいけど、何故バイナリログにしてやがったのか・・・
pl*****> 並列起動だから出力されるログの順序が決定的じゃないってのもたまに騙される
ts******> "SYSTEMD_PAGER="を設定すると使い勝手が良くなる ＞systemd

WantedBy=multi-user.targetの動き

pl*****> 未だにちょっと理解できてないのが、
pl*****> WantedBy=multi-user.targetしてるユニットは、
pl*****> Reached target Multi-User System.ってログに出てたらキックされてるってことでいいのかな
pl*****> Reached target Multi-User System.って出た後にwants/wantedbyしてるユニットが起動されるのかな
moriwaka> それ[install]セクションにかくので
moriwaka> enableするとmulti-user.targetのWantsに追加される
moriwaka> Wantsなだけなので、前後関係は決まらない
moriwaka> systemdの「起動したいリスト」にはのってるはず
pl*****> あーーーっていうことは
pl*****> Reached target Multi-User System.って出てるから、サービスがキックされてるって保証はないのか・・・
pl*****> systemdは何をもってReached target 〜を出力してるんだろ・・・
moriwaka> そのtargetをactivateしたらじゃないの。
moriwaka> Before=multi-user.target とか書けばいいのでは(targetについた時点で起動がはじまってると保証してほしいときは
pl*****> だとするとbefore=multi-user.target必要になるのか・・・
pl*****> ふむ
pl*****> ぁーそーかーかなり勘違いしてたなぁ
moriwaka> わりとそのへんごちゃっとするよね……
pl*****> wants/requireは順序関係ないから、WantedBy=Xしてても「Reached target Xって出てるからサービスはキックされてるはず」とは鳴らないのか・・・
moriwaka> はい
pl*****> ぐへぇ。勉強になりました・・・
moriwaka> 「必要なんだから先に起動してるじゃろ」と思うのはすごくよくあると思うのでみんなハマるところだとおもう
pl*****> むずかしー
pl*****> ぜひmastering systemdを書いてほしい・・・
moriwaka> 本はしらないんだけどpacktとかにないのかな

Conflicts=shutdown.target

pl*****> あと、Conflicts=shutdown.targetって何の意味があるんだろう
moriwaka> shutdownコマンドとかでshutdown.target を呼びにいくときには俺を終了してくれよなという意味では>conflicts
pl*****> ぁーーーそうか。終了するときに shutdown.targetに遷移するから、その時に殺してくれるのか・・・
pl*****> conflicts=にサービスが設定されてると、このサービスはあのサービスと競合するんだなって分かるけど、
pl*****> shutdown.targetと競合する？どういうことだ？ってなってた・・・

moriwaka>
------------------------------------------------------------------------
shutdown.target
          A special target unit that terminates the services on system shutdown.

          Services that shall be terminated on system shutdown shall add Conflicts= and Before= dependencies to
          this unit for their service unit, which is implicitly done when DefaultDependencies=yes is set (the
          default).
------------------------------------------------------------------------
systemd.special(7)に↑の記載があったよ
pl*****> DefaultDependencies=noにしてる場合のみ必ず書く必要があるって感じか

systemdのドキュメント

pl*****> ぁー systemd.specialなんてあるのか・・・読んでませんでした
moriwaka> systemd組込みのunitは Documentation=man:systemd.special(7) みたいな感じでどこ読めばいいかも書いてくれてるからそこから辿っていくとやりやすいです
pl*****> ProtectSystem=とかすごい安心感ある・・・こんなのあるんだ
pl*****> ドキュメント辿ってるだけで時間が無限に過ぎそう
moriwaka> dpkg -L systemd|grep /man|wc -l → 198
多すぎてさすがにびびった。まあだいたい7章から辿れるはず……
pl*****> 片手間で鯖缶してる人なんかは、たしかにsystemd勉強するのは辛いかもね
pl*****> 読むもの大杉ってなりそう
moriwaka> おおざっぱには、systemd-* はあんまりユーザが叩かないコマンドとかなので
systemd.*(5) でunitの設定読んで、必要に応じて*.conf読んで、あと なんとかctl のman pagesを読んでおけばだいたい日常の用は足りるはず
systemd.directives.7.gz というのがunitで書けるディレクティブの辞書的になってて
こっから記載があるman pageがたどれる
pl*****> ふむ
moriwaka> unitファイル見たら知らないディレクティブがでたときむけ(だいたいsectionでわかるけど

コマンド分け……てるよ

ar*******> journalctl とか、わけるのかくっつけるのか、一貫性がないな。
ar*******> それわけるなら、systemctl をもう少し細かく分けたらいいのに。
aa**> systemdってなんでしょうか？サービスを管理するなにか？
moriwaka> linuxユーザーランドの基盤をととのえるプロジェクトの名前兼、initをやるデーモンの名前
pl*****> 個人的にユーザーランドに頭出してる第二のカーネルと思ってる
moriwaka>
------------------------------------------------------------------------
$ dpkg -L systemd | grep bin/
/bin/journalctl
/bin/loginctl
/bin/networkctl
/bin/systemctl
/bin/systemd-ask-password
/bin/systemd-escape
/bin/systemd-inhibit
/bin/systemd-machine-id-setup
/bin/systemd-notify
/bin/systemd-sysusers
/bin/systemd-tmpfiles
/bin/systemd-tty-ask-password-agent
/usr/bin/bootctl
/usr/bin/busctl
/usr/bin/hostnamectl
/usr/bin/kernel-install
/usr/bin/localectl
/usr/bin/systemd-analyze
/usr/bin/systemd-cat
/usr/bin/systemd-cgls
/usr/bin/systemd-cgtop
/usr/bin/systemd-delta
/usr/bin/systemd-detect-virt
/usr/bin/systemd-mount
/usr/bin/systemd-path
/usr/bin/systemd-resolve
/usr/bin/systemd-run
/usr/bin/systemd-socket-activate
/usr/bin/systemd-stdio-bridge
/usr/bin/timedatectl
/bin/systemd
/usr/bin/systemd-umount
------------------------------------------------------------------------
実行ファイルだけでこんだけある
まあsystemctl, journalctl, loginctlくらいしか日常叩かないけど

このへんのソフトウェア群がサービスが起動したりログインセッションはじまったりするための環境をととのえるために色々な仕事をします
aa**> あーそれなのか、systemctl, journalctl,はよくお世話になってます

timedatectlつかう?

pl*****> timedatectl、新し目のrhelだとtimesynd使うようになったり？
pl*****> 7系はchrony固定なのかな
moriwaka> 7はchronyかntpdですね。timesyncdは自分でつかったことがないからよく知らない
pl*****> なるほど

systemdのめっちゃ嬉しい機能をダラダラと説明する

2018/06/07〜2018/06/08 あたりにtwitterでつぶやいたsystemdのうれしいシーンまとめ

Package管理と相性がよい

• sysvinitのスクリプトちょっといじってulimit文足したあとにパッケージupdateしたら消えたりしたことがある人はsystemdならその不幸はもう起きない 
• systemdは設定ファイルが /usr, /etc, /run くらいにバラけて配置されるのでパッケージが提供するのをカスタマイズで変更するのは簡単にできるしパッケージシステムの更新などと相性もいい。
• バラバラだと作業が煩雑になりがちなので関連コマンドが充実
• パッケージのデフォルト、/etc/での設定、/run/の自動生成された設定などをまとめてunitを表示してくれる systemctl cat 
• unitをカスタマイズするときに適切なファイルを編集してくれる systemctl edit などのコマンドも便利
• 現在の設定を評価してデフォルトからどう変更されたかをまとめて表示してくれる systemd-delta コマンドもあるよ。 

sysvinit等でありがちだった罠にハマりにくい

• /etc/init.d/hoge を直接実行してserviceコマンド経由での起動時と環境変数やらが違うからハマった人、systemdならその不幸はもう起きない
• 同じサービスを1システム内で複数インスタンス構築してpidファイル被ったりログがどれがどれやら混乱したり、そういうことはsystemdをちゃんと使えば回避できる(残念ながら対応したパッケージは少ない) 
• 設定ファイルのunit名を @で終わらせると複数インスタンスに対応。たとえばgetty@tty1.service というunitはtty1用のgettyで、仮想端末にあわせてgettyをいくつも作成する。この場合設定ファイルはgetty@.serviceになる。
• /etc/init.d以下のスクリプトがしれっとタイムアウトしてるくせにexit 0してて「フザケンナ」ってなったことがある人、残念ながらsystemdでも敢えてやればできちゃうけど普通の使い方ならちゃんと失敗したらnon zeroなexit code返すよ 
• systemctl status で指定したunit(のどこかで)失敗が発生しているとexit codeがnon zeroになる
• systemdのunitではサービス実行前のチェック、サービス実行直前の準備コマンド、サービスそのもの、サービス実行直後に実行するコマンドなど細かくフェーズを分けてコマンドを記述できる。設定は面倒かもしれないが実際にどこかで失敗が発生したときにどのコマンドで問題が発生したか、exit codeは何かなどを細かくレポートしてくれて素敵。

Linuxの新しい機能などを上手くサポートしてくれる

• 一時ファイルを/tmpに作って置き換え可能なタイミングが発生する典型的なセキュリティホール作っちゃった人、systemdならそのサービス専用の/tmpをbind mountして分離する緩和策が1行書くだけで実施できるよ 
• PrivateTmp=true と指定するだけ
• mount namespaceとbind mountを使ってunitに特有の/tmp を作ってくれる
• 他にもいろいろ制限をかける仕組みがあるので systemd.exec(5) のSandboxingを見るとよい
• 「linuxはcgroupでリソース制限かけてメモリ+swapの上限とか設定できる」それどうやって使うんだろうと思った人、systemdならサービス毎にcgroup作ってるから設定1行書くだけでできるよ  
• MemoryMax=10G とか書く
• 詳しくは systemd.resource-control(5) にある

サービスの管理や追跡の機能が豊富 (いくつかはcgroup統合のおかげ)

• なぜか時々死ぬサービスを再起動するためにdaemontools入れたことある人、systemdならそれ最初からあるよ 
•  Restart=always とか。どういう条件でプロセス終了した場合に再起動するかなどをRestart=の設定で細かく指定できたり、再起動前の待ち時間をRestartSec=で指定できたりするよ。
• 「ん、このサービスいつ起動したっけ、先週月曜だっけ……?」ってログ漁ったことある人、systemdなら各サービス毎にいつ起動したかちゃんと覚えてるよ
• 謎のbashが動いてて「え、これ何から呼ばれてるの」と思ったけどpstreeで見たらinitの子になってて「なんだろー」ってなったことある人、systemdならどのサービスか、それともユーザーセッションから出てきたプロセスか即わかるよ 
• "systemctl status" だけ打つと各サービスやユーザセッションとの関係もでてきます
• libvirtが起動するdnsmasqがサービス終了しても継続して動作してて、killall -9 dnsmasqしてNetworkManagerが呼んでる関係ないdnsmasqまで殺したことがある人、systemdならlibvirt関連の全プロセスだけを一発でkillできるよ 
• "systemctl kill <サービス名>" で、 サービスに関連した全プロセスにkillを送れる
• systemdはサービス毎にcgroupで追跡してるから、「このサービスどのくらいメモリやCPUつかってるのかな」って思ったらsystemctl statusやるだけでわかるよ 

systemctl statusの例。起動時刻、CPUおよびメモリ消費、関連プロセス、最近のログ10行などがまとめて表示される

bus activationなどが素敵

• systemdは「ooがされたらxxを起動する」みたいな奴に色々(dbus, mount, デバイス, ファイル, socket等)対応してるから、cockpitみたいな「どこでも使えてほしいけど使わないときはリソース節約のため落ちていてほしい」サービスとかを設定しておくとリソースあまり使わずに待ちうけできるよ 
• cupsが駆使してる。job queue(/var/spool/cups)にjob fileがあれば起動、dbus経由でアクセスがあれば起動、tcp port631にアクセスがあれば起動
• udevがsystemdと連携して動作するので検出されたデバイスを依存関係に簡単に書ける。特定のデバイスが存在する場合にだけ有益なbluetoothdとか、lvmで必要なサービスを非同期で起動させるとか、ストレージの暗号化などで大活躍。

systemdの管理と統合されたsystemd-journaldによるログ管理素敵

• 複数台の/var/log/messagesを見比べて「何で時間が秒単位なん!どっちが先か後かわからん! (>_<)」ってなったことがある人、systemd-journaldならマイクロ秒まで保持してるよ 
• journalctl -o short-precise で時刻を細かくした出力が得られる
• トラブルシューティングでsyslogでためてるメッセージを解析する時に"warning"とかで検索してcriticalなメッセージ見逃したことがある人、systemd-journaldならログレベル保持してるからあらかじめ分けておかなくても「warn以上」とかですぐ絞りこめるよ 
• journalctl -p 3 で error以上、など。
• 全然ログらしいの吐かないデーモンについて詳しい人に聞いたら「daemonizeさせずにforegroundで動かしてstderr見ればいいんだよ」とか言われて「そんなん知らんがな」と思ったことがある人、systemd + systemd-journaldならサービスのstdout,stderrもきっちりログに収集するよ 
• systemdはサービス管理とロギングが統合されてるから journalctl -u サービス名 で特定のサービスに関連するプロセスが出したログだけ出してくれて便利。特に子プロセスの名前がメインのプロセスと違う時に見逃しがない。
• journaldはtimestampをUTCで保持しているのでシステムのTZに依存せず簡単にログを比較できるよ 
• 各システムにユニークなmachine-idがついて、そのmachine-idのディレクトリにログが保存されるので複数システムのログを同じところにまとめやすいし、まとめたログファイル群をマージして読めるよ
• /var/log/journal/b1cb7fb826fe490da1e256a4300f4c2f/system.journal みたいなファイルになります
• machine-idは /etc/machine-id に保存されている。このファイルを削除して再起動するか systemd-machine-id-setup コマンドで作り直しされる。

こまかい便利機能

• systemdは競合するサービスをConflict=で明示的に定義できるからntpd動いてるのにchrony動かそうとすると実際に競合する前に検出して失敗してくれるよ
• systemd、電源断や再起動だけでなくサスペンドやハイバネートもやるよ 

systemdに興味を持った人むけリンク

• systemd - Arch wiki 
• #きょうのsystemd: (翻訳)PID 1 を考え直す systemdの作者Lennert のblog翻訳
• http://popopopoon.hatenadiary.jp/search?q=systemd 他にもいくつか翻訳なさっています
• systemd によるサービス管理
  

  • RHELのドキュメントです。意外(?)に包括的にまとまっています。

3週間ほどGoogle Homeを使ったまとめ 小技編

サードパーティアプリの強制終了は「キャンセル」

サードパーティアプリそのものは玉石混交でまあどんどん変わっていくと思うので詳細には触れない。音声対話をしているときにサードパーティアプリが想定しているコマンドがわからなくなると「すみません、もう一回言ってください」「最後のコマンドを言い替えてください」などのループに簡単に陥って脱出の方法がわからなくなる。そんなときは「キャンセル」と言えば強制終了できる。

https://developers.google.com/actions/assistant/app-exits Actions on Googleのドキュメントを見ていると、英語では以下5コマンドで止められるらしい。僕は日本語で「終了」「終わり」「もういいです」「ストップ」「さようなら」くらいをためしたが全滅だった。困ったら「キャンセル」を覚えておくだけで全然違うとおもう。

• "exit"
• "cancel"
• "stop"
• "nevermind"
• "goodbye"

ショートカット作成はアクティビティログを見ながら

Google homeへのコマンド入力は、音声も含めてアクティビティログ  に記録されている。
Google homeアプリの「マイ アクティビティ」のほうが省略されないので見易い。

ショートカットを作成するときは、このマイアクティビティを見ると、どう認識したか、ショートカットをどう展開したか、その反応は何かがわかる。

たとえば「リアを再生」→「Liaを再生」というショートカットを作ってテストをすると以下のようなログが残ってちゃんと期待通り展開されていることがわかる。