
今日のランチは、赤坂の堂間のトロサバ定食。パリッと香ばしく焼けたトロサバが美味しかった。

今日のランチは、赤坂の堂間のトロサバ定食。パリッと香ばしく焼けたトロサバが美味しかった。
今回のアップグレードは、Gitlab 17.0.1-ce から Gitlab 17.1.0-ce 。アップグレードパスとしては、問題はないはずだったのだが、下記のエラーが出た。
Running handlers:
[2024-06-25T18:47:40+09:00] ERROR: Running exception handlers
There was an error running gitlab-ctl reconfigure:
redis_service[redis] (redis::enable line 19) had an error: RuntimeError: ruby_block[warn pending redis restart] (redis::enable line 88) had an error: RuntimeError: Execution of the command `/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket INFO` failed with a non-zero exit code (1)
stdout:
stderr: Could not connect to Redis at /var/opt/gitlab/redis/redis.socket: No such file or directory
Running handlers complete
[2024-06-25T18:47:40+09:00] ERROR: Exception handlers complete
Infra Phase failed. 11 resources updated in 37 seconds
[2024-06-25T18:47:40+09:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/cinc-stacktrace.out
[2024-06-25T18:47:40+09:00] FATAL: ---------------------------------------------------------------------------------------
[2024-06-25T18:47:40+09:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2024-06-25T18:47:40+09:00] FATAL: ---------------------------------------------------------------------------------------
[2024-06-25T18:47:40+09:00] FATAL: RuntimeError: redis_service[redis] (redis::enable line 19) had an error: RuntimeError: ruby_block[warn pending redis restart] (redis::enable line 88) had an error: RuntimeError: Execution of the command `/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket INFO` failed with a non-zero exit code (1)
stdout:
stderr: Could not connect to Redis at /var/opt/gitlab/redis/redis.socket: No such file or directory
===
There was an error running gitlab-ctl reconfigure. Please check the output above for more
details.
===
dpkg: パッケージ gitlab-ce の処理中にエラーが発生しました (--configure):
installed gitlab-ce package post-installation script subprocess returned error exit status 1
xxd (2:8.1.2269-1ubuntu5.23) を設定しています ...
vim-common (2:8.1.2269-1ubuntu5.23) を設定しています ...
vim-tiny (2:8.1.2269-1ubuntu5.23) を設定しています ...
dbus (1.12.16-2ubuntu2.3) のトリガを処理しています ...
desktop-file-utils (0.24-1ubuntu3) のトリガを処理しています ...
mime-support (3.64ubuntu1) のトリガを処理しています ...
hicolor-icon-theme (0.17-2) のトリガを処理しています ...
gnome-menus (3.36.0-1ubuntu1) のトリガを処理しています ...
man-db (2.9.1-1) のトリガを処理しています ...
処理中にエラーが発生しました:
gitlab-ce
E: Sub-process /usr/bin/dpkg returned an error code (1)
zen@LAB:~$
もう一度、sudo apt upgrade を実行したところ、正常に終了した。
sudo gitlab-ctl restart を実行するように出ていたので、実行した。
GitLabのウェブ画面上からも確認したが、最新(17.1.0)にアップグレードができており、問題はなかった。

今日はまったりランチで、木都里亭で麻婆丼。きっと、健康的。

タマノイの「推しの子」コラボの「すしのこ」が売っていたので買ってきた。普段使いするので、何個か買ってくればよかったかも。
このパッケージの違和感のなさがいい。
vSphere8.0でESXiの起動時(電源ON時)にVMも起動させる設定がされているVMを調べる方法のメモ
1. vCenter Server にログインする。
2. 「ホストおよびクラスタ」のメニューを開く。
3. 自動起動させたいホストを選択する。
4. 「構成」タブを選択する。
5. 「仮想マシンの起動およびシャットダウン」を選択する。
6. 「仮想マシンの起動およびシャットダウン」のメニューに「自動順位付け」「自動」の選択項目があるので、それぞれを選択する。
7. 起動の部分が「有効」になっているVMが自動起動するVM。起動遅延時間や起動順番を確認すると、どの順番でVMが起動してくるのかがわかる。
ちょっと検索で探しにくかったので、メモ。
.NET8.0(.NET9.0も同じだった)が対応しているWindows OSは以下。
参考:
https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md
https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md
いつもどおり、1ヶ月遅れで読了した。Bunの特集が読めてよかった。
Bunの特徴的な部分は特集でわかった。Node.jsとの比較もわかった。読んだけれど、なんだかんだでわからない部分が多い。振り返ってみると、今のNode.jsがどういうものか解っていない、だからBunのことが解らない。というか、JavaScriptランタイムが解っていない。そして、JavaScriptのランタイムが解っていないということがわかったら、なんか見えてきた。禅問答みたいだけど。
結局、書いたJavaScriptやTypescriptを実行するための土台。クライアントサイドだと、ブラウザ的な部分。サーバサイドで動かすときの実行環境でしかなくて、Node.jsが担っていた部分を代替できるかもしれないのがBunということか。Webサーバ機能として、動作させれば、WebAPIとしての機能を作れる。単純にBun環境を作ったのならば、コマンドラインからJavaScriptで、プログラムを動作させられる。開発のところのパッケージ操作やプロジェクトパッケージに目がいってしまって混乱した。動作環境と開発のためのプロジェクト環境がごちゃっとなっているのに慣れないからだろう。
JavaScriptまわりのわかりにくさというか、ごちゃっとなっている感じは落ち着かないのだろうか。ES6、TypeSpcrit、CoffeeScriptとか、それに加えてフロントとバックエンド(サーバサイド)のフレームワークに環境があるのがなぁ。流行り廃りも早いし。そんななことを読み終わったあとに考えていた。

今日のランチは、サブウェイで生ハム&マスカルポーネのサンドイッチ。野菜は増量でボリュームアップ。
久しぶりに食べた。美味しかった。
vSphere8.0でESXiの起動時(電源ON時)にVMも起動させる設定のメモ。
自動起動は、「ホストがvSphere HAクラスタの一部である場合、仮想マシンの自動起動とシャットダウンが無効になります。」という仕様があるので注意すること。
vSphere8でのホスト起動時の自動VM起動設定
1. vCenter Server にログインする。
2. 「ホストおよびクラスタ」のメニューを開く。
3. 自動起動させたいホストを選択する。
4. 「構成」タブを選択する。
5. 「仮想マシンの起動およびシャットダウン」を選択する。
6. 「仮想マシンの起動およびシャットダウン」のメニューに「自動順位付け」「自動」「手動での起動」の選択項目があるので、「手動での起動」を選択する。ここで表示されている仮想マシンは自動起動設定がされていないVMである。
7. 「編集」をクリックする。
8. 画面内のポップアップで「仮想マシンの起動/シャットダウン設定の編集」が開く。
9. 「手動での起動」を選択し、一覧から自動起動させる仮想マシンを選択する。
10. 「移動先」をクリックし、「自動」または「自動順位付け」を選択する。(移動先の場所はわかりにくいので注意)
11. 上記で選択した「自動」/「自動順位付け」を選択し、選択した仮想マシンが表示されていることを確認する。
12. 確認後、「OK」をクリックする。(クリック前の起動の表示は無効になっているが、これでよい)
13. ポップアップが閉じるので、「仮想マシンの起動およびシャットダウン」で、「自動」/「自動順位付け」を選択し、選択した仮想マシンの起動が有効になっていることを確認する。
もし、自動起動やシャットダウンのタイミングを変更する場合は、編集画面で、起動時間とシャットダウンの時間の秒数を変更する。
vCenter Serverから、VM(Windows Server)のVMware Toolsのバージョンアップをおこなったところ、「vixエラーコード=21009」でVMware Tools のインストールが失敗した。その後、vCenter Serverの画面では、その仮想マシンは「VMware Toolsはインストールされていません」にかわった。
アンインストールは成功しているようで、仮想マシン上もVMware Toolsは無くなっていた。
対処方法
1. 念のため、VM(Windows Server)のVMware Toolsのインストールで利用されていたフォルダを削除。下記のフォルダを中身ごと削除する。アクセス権がないと言われるはずなので、アクセス権を取得してから削除する。
C:\Windows\Temp\vmware-SYSTEM
2. vCenter Serverから、VMware Toolsのインストールを実行する(仮想サーバ上に、VMware Toolsのインストーラーをマウントする)。
3. VMにログインして、VMware Toolsをインストールする。