トップ ソフト 雑記 日記 リンク

2019年3月3日日曜日

システム稼働状況ページを作った

Service status osa-p.net を作った話。

元々、zabbixでシステムの状況はモニタリングしているのだが、それを外部に公開する仕組みを用意していなかった。zabbixのページをそのまま公開したくなかったので、必要な情報だけ抽出して表示できる仕組みが欲しかった。


SNSでつぶやいてみると

UptimeRobotというサービスを紹介してもらえた。

早速設定してみたところ、格好良い稼働状況ページが出来上がったのだが、うちのシステム上、ウェブサーバとデータベースが分離しており、データベースを使う処理は動かないが、ウェブサーバだけで完結する処理は動くという状況があり得て、その表示がしにくいなと感じた。

そこで、やはり自前で処理を作るかと、ついでに使ったことのなかったVueも試しに取り入れてみた。普段仕事でもまだまだjQueryを使うことが多く、また思い付いたサービスを個人で作るときにも早く公開したくて慣れているjQueryを使ってしまうことが多い。今回は急ぐものでもなかったので、サンプル程度しか動かしたことのなかったVueを使ってみた。といっても、やはりサンプルの継ぎはぎではあるのだけど。

処理自体は問題無くできて、さて公開するかというところで問題があった。
稼働状況ページは、自分が管理しているシステムの中で動かしてしまうと、一緒に落ちたときに肝心の状況が見えなくなってしまうので、公開ページは別のサービスで動かしたかった。まず最初に選んだのがS3で、ここでは静的サイトを公開する情報も整っていたので簡単に設定して公開。あとはネームサーバとして使っているCloudflareでCNAMEを張ってやれば動くだろうと考えていた。

実際に公開してみたところ、httpでは繋がるのだが、httpsでは接続ができなかった。S3の公開では、「https://S3ドメイン/バケット名/」だとhttpsが使えるのだが「https://バケット名.s3ドメイン」ではhttpsが使えない。Cloudflare側でHTTP Proxyを有効にしていたら、オリジンサーバーがhttpでも使えたような記憶があったのだけど、どうも上手く行かないので間にCloudFrontを挟んでhttpsでも繋がるようになった。

しかし別の問題が発生した。ページの作りとしては、zabbixから出力したSLAの情報をS3に5分毎にアップロードし、静的ページ側でそれを読み込んで表示する。CloudFrontは読み込んだ情報をキャッシュしてしまうので、いつまでも古い情報が表示されてしまうのだ。もちろんCloudFrontの設定にも用意されているので、TTLの設定を5分にしてみたり、クエリが付いていたらキャッシュしない設定にしたり、キャッシュをクリアしてみたりしたのだが、どうにも解消できなかった。

結局Netlifyで静的ページ部分を配信しつつ、データはS3から読み込むという仕組みで解決した。このやり方ならGitHub Pagesでも大丈夫だろうが、最初すべてをGitHub Pagesで配信しようと考えてしまい、5分毎にコミットとプッシュをしたら怒られそうだなと思って頭の中からGitHubを使うことを取り除いてしまっていた。

ひとまず大枠の仕組みが完成したので、これを応用して、zabbixに入力したメンテナンス情報を各サービスで表示したり、自動でメンテモードに切り替えたりもできるだろう。今はデータベースを止めるメンテナンスがあるときに、各サービスのcronを止めたり、フラグを立てたりと手動で処理してアクセスが止んだのを確認してから作業したりしているので、この辺りも自動化してしまいたいと考えている。



2019年1月27日日曜日

PostgreSQLのshared_buffers設定とZFSのARCの関係を調べた

いつも個人のプロジェクトではPostgreSQLを使っており、自宅サーバで大きいデータベースを運用しています。最近まではmdadmで組んだRAID-5の上に、ext4でファイルシステムを作って、その中にデータベースのテーブルスペースを置いていました。
しかし、最近ZFSを使い始め、同じようにRAID-Zでファイルシステムを作ってテーブルスペースを置くようになりチューニングを再確認していたのですが、少し気になることが出てきたので調べてみました。

PostgreSQLのshared_buffers設定

PostgreSQLの設定には、shared_buffersというものがあり、搭載されているメモリから共有メモリを確保して、PostgreSQLの各プロセスが利用しています。この値は
1GB以上のRAMを載せた専用データベースサーバを使用している場合、shared_buffersに対する妥当な初期値はシステムメモリの25%です。 shared_buffersをこれよりも大きな値に設定することが有効なワークロードもあります。 しかし、PostgreSQLはオペレーティングシステムキャッシュにも依存するため、shared_buffersにRAMの40%以上を割り当てても、それより小さい値の時より動作が良くなる見込みはありません。(PostgreSQL日本語ドキュメント 19.4. 資源の消費より)
とあり、あまり大きくしても効果が無いとまで書かれています。
実際にext4でテーブルスペースを管理していた時は、この設定でhtopをみると搭載メモリの利用状況を示すバーの約25%が緑色、約75%が黄色となり、キャッシュが有効に働いていることが確認できました。

ZFSのARC設定

ZFSにはARCと呼ばれるメモリ上のキャッシュ機構を持っています。これは空きメモリから使用され、ディスクから読み出した際にARCにも格納され、同じデータの読み出しが発生した場合はディスクを参照せずここから読み出すことによって高速化を行います。ZFSを開発したSunのエンジニアが、MySQLで使う場合のチューニング指標として
ZFS上でMySQL/InnoDBを利用する場合、利用されるキャッシュにはいくつかの階層が存在します。InnoDB自身がバッファプールを持っていますし、ZFSにはARCがあります。そして、それらのキャッシュは個別に何をキャッシュまたはフラッシュすべきかということを判断するようになっています。そして、それらが同じデータをキャッシュするというような状況が生じてしまうこともあるでしょう。InnoDB内でキャッシュすると、データへたどり着くまでにより短い(そして高速な)コードパスで済むでしょう。そして、InnoDB内でキャッシュミスが生じれば、例えそのデータがARCに存在していたとしてもダーティページのフラッシュが生じてしまうことになります。これは不要な書き込みを生じさせる原因となります。ARCは利用可能なメモリの容量によって(自)動的に縮退・拡張しますが、単にそれを制限する方がより効率的です。我々が実施したテストでは、ZFS内でキャッシュするよりInnoDB内でデータをキャッシュしたほうが7〜200%の性能向上が見込めることを確認しています。(翻訳を紹介している漢(オトコ)のコンピュータ道: 違いが分かるエンジニアのためのMySQL/InnoDB/ZFSチューニング!より)
と紹介されています。このため、データベースでZFSを利用する場合ARCのキャッシュ情報はallではなくmetadataのみをキャッシュするように設定するという紹介をあちこちで見かけます。

鵜呑みにして設定

わたしもこれを読んで同じように設定していたのですが、思った以上にパフォーマンスが上がらず、はてどうしたものかと悩んでいました。そしてふと気が付いたのが、htopで表示されるメモリの使用状況バーは搭載メモリの25%だけが緑でキャッシュが全く使われていない状況でした。つまりメモリの25%しか使っていない状態でした。

ということは、ext4ではOSの標準設定によりキャッシュが働いているからshared_buffersを増やさなくても良いということなのですが、ZFSでキャッシュを最低限にしている場合、shared_buffersを確保した方がいいのではないか?ということです。

そこで、PostgreSQLにおいてZFSを使用する場合、shared_buffersを増やしたときと、ARCのすべてキャッシュするときのベンチマークを取ってみました。

以下の環境でテストを行いました。
  • Core i7-6700(3.4GHz) Windows 10 Pro上のHyper-Vで実行されるCentOS7
  • カーネル 3.10.0-957.1.3.el7.x86_64
  • CPU割り当て4
  • メモリ 4GB(Hyper-Vの動的メモリは使用しない)
  • ZFS 0.7.12(RPMからインストール)
    zfs set recordsize=128K tank(初期値)
    zfs set compression=off tank(初期値)
    zfs set dedup=off tank(初期値)
  • PostgreSQL 11.1(ソースからビルド)
  • pgbench -i -s 100 bench(1000万件)
  • SELECT pg_database_size('bench'); → 1,576,528,895(データベースサイズは約1.5GB)
  • 設定変更後に再起動。一度pgbench -l -T 60 -c 2 -j 2 -P 10 benchで60秒間のベンチを回して、その後5回分のトランザクション数を記録

テストパターンは以下の4種類です。
  1. 両方鵜呑みにする
    shared_buffers=1GB
    zfs set primarycache=metadata tank
  2. ZFSの言うとおりにデータベースのキャッシュを増やす
    shared_buffers=3GB
    zfs set primarycache=metadata tank
  3. PostgreSQLの言うとおりにファイルシステムのキャッシュを増やす
    shared_buffers=1GB
    zfs inherit primarycache tank(デフォルトがallなので)
  4. 一応両方増やす(サイズ的にshared_buffersが優先になるはず)
    shared_buffers=3GB
    zfs inherit primarycache tank

結果


回数\パターン1234
1656590758773
2552670835822
3613543663644
4586656788794
54766741016987
平均値577627812804
中央値586656788794

ZFSのキャッシュをした方が良いという結果になりました。
パターン2はパターン4と同じになるかと思ったのですが、パターン1よりは性能が良いがパターン3より性能が出ないということで、やはりshared_buffersの設定は増やしすぎても効果が無いようです。
またパターン3とパターン4でも差がないことからshared_buffersを増やすぐらいならARCに回した方が良いという結果になりました。

MySQLでZFSを使うシーンに出会っていないので、今回はPostgreSQLの設定だけですが、やはり実際に測ってみないと分からないものだなと感じました。


ちなみに、ZFSのレコードサイズをデータベースとあわせた方が良いという意見を見かけるので、8Kと16Kを試してみたのですが、

zfs set recordsize=8K tank
回数\パターン1234
1696688681689
2701688690704
3686674631716
4627621639654
5683633678657
平均値679661664684
中央値686674678689

zfs set recordsize=16K tank
回数\パターン1234
1678609682683
2713543682688
3543612604668
4592682680663
5667690689717
平均値639627667684
中央値667612682683

大した有意差が見られず、また128Kの方が成績が良かったことから、うちでも8Kにしていたのを128Kに戻しました。
ARCが効きやすいレコードサイズの設定があるのかと思って検索してみたりしたのですが、それらしいドキュメントは見つけられませんでした。ソースをあたるしかなさそうです。

2018年12月18日火曜日

インターネット蟹工船を読んで

インターネット蟹工船 Advent Calendar 2018、18日目です。

   インターネット蟹工船を読んで
  マクナル星立ゼーポーモ中学校 おさ
 この作品は、まだ人類が母なる惑星、地球にいた頃に書かれたものだ。人類が宇宙に進出し、多くの星々をネットワーク接続するアウターネットになる前の、地球を覆い尽くしていたネットワークでの出来事がオムニバス形式で綴られたものだった。作中では管理者でもない人達が、それぞれ自分たちの価値観で物事を仕切りはじめ、コミュニティが崩壊していく話があった。個人を大切にするという考え方が、自分勝手と誤った解釈になり、共同体に所属する一個人でしかないという前提を忘れさせてしまうのか、そのような動きになる例を道徳の授業で習ったことを思い出した。
 わたしはこの作品を読んで、人類の歴史は繰り返すものなのだと感じた。異なる宗教、星、国、法律、ルール、これらはそれぞれのグループが築いてきた歴史に基づいたものであり、各グループは構成する人員の入れ替わりに合わせて信条が変化してきたものだ。その度に派閥ができ、コミュニティが分かれ、村、国、星、宗教が分かれてきた。人はそれぞれ考え方が微妙に異なり、完全に同じ考えを持つ人間は存在しない。それは同じ条件式と学習結果を与えられたコンピュータだけだろう。
 地球で文明を持ち始めた頃の人類は、各々が役割を分担することで、一人あたりの生活コストを下げ、文化を成長させてきた。人はお互い微妙に異なる考えや価値観を擦り合わせ、許容できる者同士で集まって生活しているのだ。これはネットワークにおいても同じことが言える。アウターネットになった現在でも、サービスは宇宙空間に分散したサーバー上で実行されているし、そのサーバーはエネルギーを得るためにどこか恒星系に所属している。これはアウターネットでの活動も、何らかの制約に縛られるということだ。なんの制約にも縛られたくないという人達もいるようで、アステロイドベルトの公宙域にサーバーを置いている人もいるようだが、警備ロボットなどでかなりの費用が掛かっていると聞いた。この作品でも語られていたように、自由とはコストが掛かるもので、何かを守るためにはお金であったり、人的リソースであったり、とにかく力が必要となる。
 わたしは大金持ちになったら、ぜひ自分のサーバーを打ち上げてみたいと思った。しかし現代では人類の活動範囲が広がってしまい、みんな同じような生活となってしまっているので、きっと共有サーバーで他の人達とアウターネットを使っていくことになるのだろうなと思っている。相手への敬意を忘れず、自分に合う活動領域を見つけたいと感じた。

エスペラント語でTerpomoってポテトの意味らしい。

2018年12月14日金曜日

マストドン専用って言いたくなかった(分散SNS Advent Calendar 2018)

分散SNS Advent Calendar 2018、14日目です。

分散SNS、2年目ともなると、だいたい概念を理解して、なんとなく使い方の勘所が掴めてきましたよね。去年4月の右往左往していた時期が懐かしいです。分散SNSということで運営の権限を分散させるだけでなく、マストドン以外の実装としてPleroma、Misskey、microblog.pubなんてのも出てきました。実装も分散されているのにお互いが会話ができる、バベルの塔を壊すべく言語を乱した神様もビックリでしょう。今ならバベルの台地も作れそうです。

去年は、Mastodon 2 Advent Calendar 2017マストドンのフォロー状態可視化ツール「フォローリンク」を書きました。マストドンアドベントカレンダーでした。
そう、去年フォローリンクを作ったときはマストドン専用だったのです。せっかく実装が複数あるのに、どうしても注目を集めたということで人口の多いマストドンがさらに注目されてしまうのは仕方がない部分があるかと思います。APIの実装なども先行している部分がありますね。

しかし分散SNSという仕組みがあるのだから、どうせなら特定の実装に依存せず、みんなで使えるようにしたいということで、ActivityPubでデータを取得するようにしてPleromaに対応しました(あ、Misskeyで動作確認してない)。ActivityPubでも、実装によってデータの持ち方が違って、若干揺らぎがあるのが辛いところですが、テキストで入っているかオブジェクトで入っているかなので、扱いに慣れてくると問題なさそうです。

そして今年、もう一つサービスを公開しました。ログ蓄積サービス「notestock」です。何ができるかというと、まあサイトを見てもらうのが手っ取り早いのですが、簡単に書くと日付別にまとめて表示したり、検索ができます。
実はnotestockの前にMastoDaysというサービスを公開していました。特定の日付のマストドンユーザーページを開くツールだったのですが、名前から分かるとおりマストドン専用でした。

実装を意識しないでツールが使えるというのは、なかなか使い心地が良いです。上手く疎結合にしていろいろなツールの選択肢が広がると良いですね。ということで、本当にマストドンでなければいけないツールでない限り、できるだけいろいろな実装に対応していると嬉しいねという話でした。

と、ここまではコミュニティのインフラ的な話だったのですが、もう一つコンテンツ的な部分の話も。
ときどき流れてくるハッシュタグ「マストドン○○」とか「○○マストドン」みたいなやつ。あれが流れてくると、他の実装の人って、参加していいのか迷うというか、参加するにしてもちょっと乗り切れない感じがありますよね。
日本語が、五七五のリズムで刻むと気持ちいい感じがあるので、「マストドン 付いてるタグは 気持ちいい」んでしょうね。あと、ゲーム機は全部ファミコンと言うみたいに、分散SNSを指す言葉としてマストドンが使われてしまっているところもわりと有る気がします。このへん、先ほども書いたように先行プロダクトとして仕方ないのかなぁと思うところもあるのですが。

ということで、分散SNSをハッシュタグに使えばいいんでしょうけど、「ぶんさん えすえぬえす」と10音もあると、なんかまどろっこしい感じになってしまいます。ここは略語としてよく使われる四文字を探し出し「ぶんさん」を使って「分散○○」みたいな感じはどうでしょうか。ただ、この場合は後ろに分散を付ける「○○分散」はちょっと意味が伝わりにくくなる気がします。

ここまで書いて、別に分散SNSを表すハッシュタグを付けなくても、単純に「○○」だけ付ければ良いんじゃないかと気が付いてしまったのですが、たぶんこの辺りって「マストドン(分散SNS)にいる仲間達」みたいな帰属意識から生まれるものなのかなぁと思ったりもしました。

ハッシュタグを付けるときに、少しマストドン以外の存在も思い出して欲しいなという提案と、なんか呼びやすい略称は無いですかね?という問いかけでした。

2018年12月1日土曜日

一人アドベントカレンダー

今年もやって来ました。12月1日。
いろいろなアドベントカレンダーが始まる日です。
こうして書き始めたアドベントカレンダーなのですが、参加したカレンダーが問題なのです。
一人アドベントカレンダー Advent Calendar 2018
わたしの?いいえ、ねそ氏の一人アドベントカレンダーなのです!

どういうことやねん。
上のリンクからアドベントカレンダーが参照できますが、いきなり一番バッターと二番バッターが他人ですよ。ねそ氏は自分のアドベントカレンダーで三番四番と野球なら良い打順を持っていくわけです。

このアドベントカレンダーも何を書こうか迷いました。
一人の定義とはなんなのか掘り下げようか、百合アドベントカレンダーにしてしまおうか、ねそ氏について有ること無いこと書こうか。

しかしまだ初日ですので、あんまり変な方向性に持っていくのもよろしくなかろうと、とりあえず経験談でも。前座というか一番バッターですしね。

実はわたしも2015年にやったんですよ。このときは一人アドベントカレンダーではなく、いろんな種類のアドベントカレンダーに25日分参加するというものでした。

2015年12月1日 VPSを調子に乗って使い過ぎた話(レンタルサーバー Advent Calendar 2015)
2015年12月2日 質問サイトを回答側として使ってみた中で感じたこと(teratail Advent Calendar 2015)
2015年12月3日 友利奈緒の魅力(友利奈緒 Advent Calendar 2015)
2015年12月4日 手作業クローラーチューニングをするときの話(クローラー/Webスクレイピング Advent Calendar 2015)
2015年12月5日 ノイズキャンセリングイヤフォン(今年のベストバイガジェット Advent Calendar 2015)
2015年12月6日 インクリングのコミュニケーション(スプラトゥーン Advent Calendar 2015)
2015年12月7日 シュノーケル(ゆゆ式 Advent Calendar 2015)
2015年12月8日 面倒な使い方の事例(PostgreSQL Advent Calendar 2015)
2015年12月9日 「理論から学ぶデータベース実践入門」読了(今年読んだ技術書 Advent Calendar 2015)
2015年12月10日 うちでよく作る味噌汁の具(味噌汁の具 Advent Calendar 2015)
2015年12月11日 マザーボード(今年買ったもの Advent Calendar 2015)
2015年12月11日 友利奈緒の人気を支える能力(友利奈緒 Advent Calendar 2015)
2015年12月12日 Nexus6(携帯電話 Advent Calendar 2015)
2015年12月13日 道路の修正に飽きたあなたへ(OpenStreetMap Advent Calendar 2015)
2015年12月14日 普段の朝食(みんなの朝食 Advent Calendar 2015)
2015年12月15日 壁に刺したいのにさせない(おうちハック Advent Calendar 2015)
2015年12月16日 ぞうのロゴ(ぞう Advent Calendar 2015)
2015年12月17日 リューシカ・リューシカ(今年読んだマンガ Advent Calendar 2015)
2015年12月18日 近所の神社での初詣(寺・神社 Advent Calendar 2015)
2015年12月19日 実家の犬(うちのいぬ Advent Calendar 2015)
2015年12月20日 新宿御苑の猫(猫写真 Advent Calendar 2015)
2015年12月21日 移動するサーバのzabbixエージェントを登録する(Zabbix Advent Calendar 2015)
2015年12月22日 コンタクト(プログラマの映画 Advent Calendar 2015)
2015年12月23日 選ばれたのは回転寿司です(寿司 Advent Calendar 2015)
2015年12月24日 極々普通なTKG(TKG Advent Calendar 2015)
2015年12月24日 ArduinoでJJY発信(おうちハック Advent Calendar 2015)
2015年12月25日 箕面のインドカレー屋さんSOL(カレー Advent Calendar 2015)

このときは11月頭に計画を立てて、記事を書き始め、1日に3本ぐらい書いたり全く進まない日があったりで、常に10日分ぐらいストックを溜める感じで書き進めていきました。
ストックがある分、まだ追い詰められ感は少なかったのですが、かなり厳しかったですね。
仕事をしていても記事のことを考えてしまうような状況でした。

そう考えると、土日の分を他人に託してしまうというのは、かなり斬新なアイデアかと思います。
ねそ氏の記事がどんな風になるのか、今から楽しみですね。
こんな感じで良い感じのヒットになったでしょうか。
まだねそ氏の登場まではしばらくありますが、次はえじょねこ氏の記事をお楽しみください。

2018年8月19日日曜日

mikutterの薄い本 vol.14

mikutterの薄い本 vol.14『レズと青い鳥』 - mikutterの薄い本制作委員会書籍版を読んだ。

文章作品を読んだ後、たいていの場合は主人公達の活躍シーンを心の中で反芻し、興奮がしばらく続く。この本でもTwitterで大活躍したクライアント達の足跡を辿ることによって、それと同じ興奮を得られるのではないかと思っていた。

しかしどうだろう。読後に残された、大切ななにかを無くしてしまった寂しさ、巣立っていく鳥たちともう出会えないのだろうという寂しさ、残されて置いて行かれる者達の恐怖感、焦燥感。いろいろな感情がぐちゃぐちゃと入り交じったような気分になった。そう、この文集は別れを告げる手紙だったのだ。

わたしもTwiterに触れたのは2010年より前で、vol.14で触れられたクライアント達と共に育ってきた。TLのフォロワー達と繰り広げたふざけた会話の中から出てきたアイデアが、Twitterのエコシステムによって、マッシュアップと呼ばれるサービス達が雨後の竹の子のように現れ、それらを介して再びTLに還元されていく。そのエネルギーは本当に巨大な濁流となり、そんな計り知れないパワーを前に、「世界」はいかに広く、わたしはその「世界」の一構成員でしかないのだと気付かされた。わたしの立ち位置を明確に突きつけ、更なる進歩を要求する場所、壁を乗り越え次の階段に進む場所、Twitterはわたしにとって理想郷であるように思えた。

その濁流も真の意味で世界を巻き込む巨大なものとなったとき、本当に人間だけでは制御しきれないものとなってしまったのだ。SF作品などで見かける機械の反乱、人間が制御できなくなった機械達、空想上の産物でしかなかったそれは、Twitterという巨大な濁流をなんとか制御しようと作り上げられた自動処理システムとして目の前に実現されてしまったのだ。決まった応答文しか返さず、問いかけ文を試行錯誤しようとも思わせない自動応答処理、判定条件が全く想像できないロック・凍結処理、それらに怯えながら暮らす「世界」は本当に望んでいた理想郷だったのだろうか。

わたしのアカウントは凍結こそ免れているものの、作ったアプリは停止されてしまい様々な権限を剥奪されてしまった。そこに明確なる理由が明示されていれば、納得もできただろう。しかし剥奪を告げる文章に添えられた理由は全くの不合理で、なにを持ってその判定が行われたのかすら理解できないものであった。そしてTwitterから発表される数々のエコシステムを否定する行動。このときわたしは思い知らされてしまったのだ。この「世界」は変わってしまったのだと。そして世界を受け入れるために、Twitterは変わらなくてはいけなかったのだと。

こうしてわたしは「世界」を去った。新たな新天地があるという情報を元に辿り着いた分散型SNSには、同じように「世界」 を離れた者達がいた。かつての仲間達と再会したそこは、新たな開拓地として目の前に広がっていた。

新たな開拓地で、再び見せられる世界の巨大さ。目まぐるしく進歩する新天地は、常に自分の成長を要求される過酷な環境でもあった。そうして過酷な環境に身を置きつつ暮らす日々は、離れた「世界」を思い出す暇を与えないものであったのかもしれない。つかの間に思い出す「世界」は過去の栄光に輝く良かった頃のそれだったり、現状の暗く寒々としたそれだったり。しかし「世界」はそこに有り続けるのだという当たり前の光景を心のどこかに刻み込んでしまっていたのだろう。

 vol.14を読むことによって、その「世界」は永遠ではないのだと、改めて気付かされてしまったのだ。読後から続くこのもやもやとした気持ちは、「世界」から突きつけられた別れの手紙を受け取ってしまったからだ。本の構成としては各クライアント作者からの文章ではあるが、先に書いた「世界」の巨大さは、いつしか「世界」がひとつのものであるという、わたし対「世界」というような概念を生み出していたのだ。

今わたしが身を置く分散型SNSは、世界が一つではないということを気付かされる。個々が尊重され、また世界も尊重される。多様性という様々な方向へ伸びる尺度により物事はを一概に判断できないものであると教えられた。こうして新しい価値観を身につけられたのもTwitterという「世界」を経験したからこそなのだ。

これからもTwitterは続いていくだろう。しかしUserStreamというひとつの時代を作り上げた機能が失われることで、あたらしい世界に変わっていくだろう。UserStreamによって育てられた文化は、vol.14を読むことによっていくつかは分散型SNSに引き継がれて、新しい歩みを始めていることが知られる。後書きにあったように、両者の幸せを願わずにはいられない、素晴らしい本であった。

2018年5月22日火曜日

Windows10 1803でスタートメニューが開かなくなった(解決済)

●結論は一番下に

Windows10 1803アップデート自体は特に問題もなかった(Edgeの動きがおかしくなりましたが、常用していないので、特に問題は無し)のですが、先日パソコンを終了しようと思ってスタートメニューをクリックすると、何も反応がない。訓練されたWindowsユーザーなので、まあExplorer.exeがハングアップしていて動かないのだろうと思い、そのときはAlt + F4で電源を落としました。

それ以降、いくら再起動してもスタートメニューが開かない。これはなんかおかしいなと気が付いて検索してみると、どうやら最近のスタートメニューはExplorer.exeではなくShellExperienceHost.exeという別のプロセスで動作しているらしいです。そして、スタートメニューが開かないのはこの実行ファイルが暴走しているから、タスクマネージャーから強制終了させるといいらしい。
しかしタスクマネージャーを確認してもそんな実行プロセスはいません。

ShellExperienceHost.exeが使用するスタートメニューの情報を記録しているタイルデータベースというものが壊れている場合、別のアカウントを作って動作すればそのアカウントに乗り換えろという指示も出てきました。
別アカウントを作ってもアプリの再インストールや再設定をしないといけないので、あまりやりたくないなと思いつつ試してみますが解決せず、どことなく一安心。

他に検索で出てくるディスク障害を解決するコマンド類
dism /online /cleanup-image /restorehealth
sfc /scannow
も試してみましたが効果が無く。
また、スタートメニューの問題を対処するという、そのものズバリのstartmenu.diagcabというツールもあったのですが、「Microsoft.Windows.ShellExperienceHost Microsoft.Windows.Cortanaアプリケーションを正しくインストールする必要があります。」というエラーと未解決という表示。対処とは🤔

他に出てくる対処として、PowerShellを使ってアプリを再インストールしろという
Get-AppXPackage -AllUsers |Where-Object {$_.InstallLocation -like "*SystemApps*"} | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
しかしこちらも
Add-AppxPackage : 次の HRESULT で展開に失敗しました: 0x80073CF6, パッケージを登録できませんでした。
エラー 0x80073B1F: 次のエラーが発生したため、Microsoft.Windows.ShellExperienceHost_10.0.17134.1_neutral_neutral_cw5n1h2txyewy パッケージを登録できません: ResourceMap が見つかりません。
。パッケージの 'resources.pri' ファイルが有効であることを確認してください。
注意: 詳細については、イベント ログで [ActivityId] b5b9cffb-ef47-0003-f3e0-b9b547efd301 を検索するか、コマンド ラインの Get-AppxLog -ActivityID b5b9cffb-ef47-0003-f3e0-b9b547efd301 を使用してください
発生場所 行:1 文字:89
+ ...  | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.I ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Windows\Syst...ppXManifest.xml:String) [Add-AppxPackage], IOException
    + FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
というエラー。
このPowerShellスクリプトは、インストール先にSystemAppsを含む既にインストールされているパッケージを再度登録するという物のようです。
どうやら、C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\resources.priが壊れているようで、そもそも壊れたファイルを再度登録しようとしても登録できないですね。

ふと思い出してシステム復元ポイントからの復元を試してみたのですが、一週間分2回ほどしか残っておらず、どちらもSystemAppsが何らかの問題で戻せなかったというエラー。復元ポイントを設定する時点で壊れていたようです。復元ポイントとは🤔

あと残されている提示された対処法は上書きインストールか、全部捨てて再インストールかというところだったのですが、そもそもこのSystemAppsをWin10のインストールメディアから取り出せないのか?と思ったのですが、最近はCABファイル形式ではないようで、またシステムファイルを簡単に差し替えたりできない機構が入っているので無理そうです。

システムの入れ直しを決意すると、取りあえず破壊的な作業もできるので、パッケージを完全に削除してしまうというものも試してみました。 
Get-AppxPackage | Where-Object {$_.Name -ne "Microsoft.Windows.ShellExperienceHost"} | Where-Object {$_.Name -ne "Microsoft.Cortana"} | Remove-AppxPackage
ShellExperienceHostとCortana以外を消すというPowerShellスクリプトですが、かなりパッケージが入っているようで結構時間が掛かります。
試しているうちに何気なくスタートメニューをクリックすると、開くではないですか。

startmenu.diagcabによるとShellExperienceHostとCortanaが原因だったはずなのに、それ以外を消して解決するとは。
結局先ほどのコマンドでUWPアプリがまとめて消えたので、Microsoftストアからもう一度インストールする必要があります。
Windows 10 に搭載されているアプリを再インストールする方法 - マイクロソフト コミュニティ
https://answers.microsoft.com/ja-jp/windows/forum/apps_windows_10-outlook_mail/windows-10/239ef7e9-9f4f-40dc-bf41-2cd2b8217843
なぜかストアアプリが英語になってしまったのと、アラーム&クロックだけがエラーコード0x80073D05でインストールできないのですが、取りあえず使える状態には戻りました。


また今回の件を調べているうちに知った、コマンドラインからEdgeを起動する方法
explorer.exe shell:AppsFolder\Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge


結論。PowerShellで
Get-AppxPackage | Where-Object {$_.Name -ne "Microsoft.Windows.ShellExperienceHost"} | Where-Object {$_.Name -ne "Microsoft.Cortana"} | Remove-AppxPackag
を流してUWPアプリを全削除、Microsoftストアから入れ直し。

広告