新環境に移行していろいろ動作チェックをしていたら、jma-receview が立ち上がらないのに気付いた。x-server の関係かなといろいろ設定をいじってみたが動かない。ふと思いついて xclock を動かしたらちゃんと表示された。つまり、x-server の問題ではなく、jma-receview の問題だ。
ここで「こういうのってなんだろう、こういうのって前にもあったぞ」と、ぼやっと記憶がよみがえってきた。OpenDolphin 日記で jma-receview を検索したらヒットした。これだ。.config/user-dirs.dirs ファイルを作って、無事に立ち上がるようになった。なんでも記録しておくことは大事だなと思った。
1月中旬に Ubuntu 18.04 + xen + ownCloud で運用していた自宅サーバ (mac mini 2011) で、いつもどおりレポジトリの更新をインストールしたら、dom-u の owncloud のネットワークがつながらなくなった。（＊）
振り返ってみると、自宅サーバは debian squeeze で運用開始して、その後 ubuntu 11.04 に移行し、代々 release-upgrade を繰り返して環境を引き継いできたものであった。その間、インターフェースの名前は predictable に代わり、ネットワーク設定が netplan になり、自宅サーバは時代の変化に取り残された化石マシンになってしまっていた。
それが原因だろうと思い、predictable interface name にしてみたり、netplan にしてみたりしたが、結局つながらない。dom-u ではネットワークが up しており、dom-0 では vif1.0 が見えている、でもつながってないので、bridge のところで何かおきているらしい。web 検索で見つけた echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables というのも試してみたがつながらない。
数日あれこれ試行錯誤したがだめで、かなり悩んだが、そういえば ubuntu 18.04 はまもなくサポート終了だし、環境を一新するいい機会だと考えることにした。
当院開業の時、サーバを仮想環境で動かすに当たって、準仮想化の Xen と、コンテナ型の Linux-VServer、 OpenVZ を比較検討して、xen を採用したという経緯があった。
今の状況だと、検討するとしたら準仮想化の kvm かコンテナ型の docker ということになると思う。今回は kvm で構築することにした。機会があれば docker も試してみたい気はする。
$ sudo apt install qemu qemu-kvm libvirt-daemon libvirt-clients bridge-utils virt-manager $ lsmod | grep kvm kvm_intel 282624 0 kvm 663552 1 kvm_intel
$ sudo systemctl enable --now libvirtd
$ systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
：
# /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. br_netfilter/etc/sysctl.conf
#added net.bridge.bridge-nf-call-iptables = 0
$ cat /proc/sys/net/bridge/bridge-nf-call-iptables 0
network:
ethernets:
enp2s0f0:
dhcp4: no
bridges:
br0:
interfaces:
- enp2s0f0
dhcp4: no
addresses:
- 192.168.1.100/24
nameservers:
addresses:
- 192.168.1.1
search: []
routes:
- to: default
via: 192.168.1.1
version: 2
$ cat br0.xml <network> <name>host-bridge</name> <forward mode="bridge"/> <bridge name="br0"/> </network> $ sudo virsh net-define br0.xml Network host-bridge defined from br0.xml $ sudo cat /etc/libvirt/qemu/networks/host-bridge.xml <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh net-edit host-bridge or other application using the libvirt API. --> <network> <name>host-bridge</name> <uuid>c8b61fe1-7602-3028-15f3-2954207391fa</uuid> <forward mode='bridge'/> <bridge name='br0'/> </network> $ sudo virsh net-list --all Name State Autostart Persistent -------------------------------------------------- default active yes yes host-bridge inactive no yes
$ sudo virsh net-start host-bridge Network host-bridge started $ sudo virsh net-autostart host-bridge Network host-bridge marked as autostarted $ sudo virsh net-list --all Name State Autostart Persistent ------------------------------------------------ default active yes yes host-bridge active yes yes
以上で、xen の dom-0 にあたる部分の設定が完了。
-----Hibernate 6 でデフォルトのプライマリキー採番方法が変更になって、hibernate_sequence からではなく、テーブル名_seq から採番するようになった。これまでの採番方式を維持するためには、persistent.xml に以下のように記載しなくてはならない。
<property name="hibernate.id.db_structure_naming_strategy" value="single" />
今回、これに気付かずに運用開始してやらかしてしまった。Hibernate 5 の時はテスト段階で警告が出てくれたので、hibernate.model.generator_name_as_sequence_name=false をセットして事なきを得たが、今回は警告も出ないし、テストでエラーも出なかったので、完全に油断していた。
木曜日から運用開始して、金曜日まで問題なし。そして土曜日、診療開始してしばらくしてからエラーが出るようになった。
2023-01-28 09:04:22,093 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-80) SQL Error: 0, SQLState: 23505 2023-01-28 09:04:22,093 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-80) ERROR: duplicate key value violates unique constraint "d_module_pkey" 詳細: Key (id)=(1070) already exists.
土曜日は患者さん多く、すぐに対応するのは不可能。全身から血の気が引いたが、何回か再送すると動くので、頑張って運用を続けた。再送2−3回で送らさったのが多かったが、最高10回再送でやっと通ったのもあった。そして、幸運にも何とか外来終了することができて、最後のカルテが保存できた時は、本当にほっとして力が抜けた。
トラブルの原因となったプライマリーキーの件は、土曜外来終了後に web 検索して判明した。多分、プライマリーキーの若い番号は ModuleModel には割当たってなかったので、最初の1000番くらいは空きがあったのだろう。それを食い尽くして、何とか隙間にねじ込むしかなくなったのが土曜日だったのだと思われる。次回はちゃんとマイグレーションマニュアル読もうと誓った週末であった。
ちなみに、Hibernate 6 の新しいデフォルトの採番は、テーブルごとにインクリメントしていくので、効率的に採番できてよい方法だと思う。当院のように hibernate_sequence を single で使ってしまっていると、bigint なので最大
土曜日の orca パッチ後のトラブルであるが，原因は api のアップデートであった。
□対応範囲：ＡＰＩ □管理番号：request20181010-001 □問い合わせ（不具合）及び改善内容 ORCA APIを使い受付一覧を取得する機能がありますが，ORCA上で受付順変更を行っても， APIで返されるXMLには新しい順番の情報は無く， [Acceptlst_Information_child]の出力順も，もともとの順番と変わりがありません． 受付変更の結果をなんらかの形で取得できるようにして下さい． □対応内容 API受付一覧（/api01rv2/acceptlstv2)にて受付順変更を反映するようにしました。 ──────────────────────────────────── □対応範囲：ＡＰＩ □管理番号：request20181121-001 request20190115-001 □問い合わせ（不具合）及び改善内容 ・「患者基本情報の取得(patientgetv2)」で取得できる割引、状態、入金 方法等について、「API患者登録(patientmodv2)」で登録できるようにしてほしい ・「API患者登録(patientmodv2)」で登録できる保険の資格取得日を 「患者基本情報の取得(patientgetv2)」で取得できるようにしてほしい 患者基本情報API（/api01rv2/patientgetv2）で、公費単独の保険確認日 を取得できるようにしてほしい。 □対応内容 API患者情報取得（/api01rv2/patientgetv2）の返却に保険の資格取得日、公費の確認日を追加しました。 API患者保険組合せ取得（/api01rv2/patientlst6v2）の返却に公費の確認日を追加しました。 API患者情報一括取得（/orca51/patientbasisallv3）の返却に公費の確認日を追加しました。 API患者登録（/orca12/patientmodev2）に減免事由、割引率、入金方法を追加しました。
公費がある場合，api で返ってくる json property に追加があったため，dolphin 側で受付時に公費情報を取りに行ったタイミングで，jackson がデシリアライズに失敗して exception を吐いていた。
dolphin サーバの open.dolphin.orca パッケージを修正して，さらに，unknown property があっても jackson が無視するように設定した。これで今後知らないうちに property が追加されることがあったとしても止まらないで済むはず。
mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);
ちなみに，/orca51/patientbasisallv3 というのは現状非公開の拡張 api とのこと (by サポート)。また，patientmodev2 は patientmodv2 の間違いと考えられる。
土曜日の朝，いつものように orca を立ち上げたところ，「2019-06-25 パッチ提供(第46回)◆日医標準レセプトソフト ver 5.0.0 全17件」というのが目に付いたので，何気なくプログラム更新した。診療もいつも通り始まり，普通に6人目まで診療終了。しかしその後，7人目と8人目の受付で，orca で受付しても dolphin のリストに出ないとの連絡あり。確認してみると，サーバーログに以下のような exception が出ていた。
ERROR [stderr] (XNIO-1 task-5) com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "Certificate_CheckDate" (class open.dolphin.orca.orcaapi.bean.PublicinsuranceInformation), not marked as ignorable
すぐに何とかなるエラーではなさそうだったので，バックアップマシンに切り替えて対応することにした。当院のサーバは xen の dom-U で構築しており，毎日診療終了後にメインからバックアップに丸ごとコピーされるようになっている。つまり，メインの dom-U をシャットダウンしてバックアップの dom-U を立ち上げると，今朝の診療開始前 (orca にパッチを当てる前) の状態でサーバが立ち上がる。バックアップに切り替えて，既に診療済みだった 6人のデータは失われたが，その後の診療は無事終了した。
トラブルシューティングは後に回すとして，バックアップに切り替える前に診療終了している6人分のカルテをどうするか。ここで，以前作っておいた Autosave が使えるのではないかと思いついた。
バックアップマシンの dom-U をシャットダウンして，メインの dom-U を立ち上げると，トラブル発生前に診療終了していた 6人分のカルテが現れた。これらを全てエディタで開いて，開いたまま OpenDolphin を kill した。 しかる後に，メインの dom-U をシャットダウンしてバックアップの dom-U を立ち上げ，6人分の受付をしてカルテを開けると「保存されていない編集中のカルテが見つかりました」のダイアログが出て，カルテを復活させることができた。
診療中にバックアップに切り替えるのは初めての経験であったが，データロスなく乗り切ることができた。Autosave がこんな形で役に立つとは思わなかった。
どうも最近サーバのデータバックアップに以前より時間がかかっているように感じていた。こんなもんだったかなー，とそのままにしていたが，ふとハブのサーバとのリンクがオレンジ (100Mb/s) に光っているのが目にとまった。ethtool でリンク速度をチェックしてみると，やはり 100Mb/s になってしまっていた。
Speed: 100Mb/s Duplex: Full Port: Twisted Pair
新サーバの ether ドライバを標準的でない方法でインストールしていたことが頭をよぎったが，まずは，バックアップ機につながっている LAN ケーブルに差し替えて調べてみた。
Speed: 1000Mb/s Duplex: Full Port: Twisted Pair
すると 1000Mb/s でリンクし，ハブの LED はグリーンに光った。さらに，元々サーバにつながっていたケーブルをバックアップ機につないでみたところ 100Mb/s に落ちてしまった。つまり，原因はドライバではなく LAN ケーブルであった。サーバをいじったときに無理な力をかけて断線させてしまったのかもしれない。
受付から，コピー機として使っている複合機のあたりからすごい音がして，蓋が開きにくくなったとの連絡あり。確認したところ，プラスチックの蝶番が折れていた。こういう力のかかるところにプラスチックの部品は無理なんじゃないんだろうか。というわけで，板金加工で修理した。
9月6日午前3時7分，北海道胆振東部地震が発生し，当院のある札幌市東区は震度6弱に見舞われた。 停電のため地下鉄が動かず，信号機も消えてしまって道路も混乱，夜が明けてから歩いて医院に状況確認に行ったところ，iMac が全部画面を下に倒れてしまっており，1台 (iMac Late 2015) でディスプレーのガラスが割れてしまっていた。
|
|
|
停電のため診療どころか掃除機すら使えない状態であったが，7日午後までには電気が回復，バックアップマシン (iMac Mid 2010) を立ち上げ，卸さんに電話して冷蔵の薬品を注文，8日から診療を再開した。停電の影響で物流は大混乱，食料の入手にも一苦労の状態だったが，薬品はちゃんと8日朝に届いた。ありがたいことである。
当初，壊れた iMac はガラスが割れただけに見えたので，ガラスだけ買って交換すればいいと考えていた。しかし，調べてみると，最近の iMac は薄くするために表面のガラスと LCD が一体化しているらしく，ガラスだけ交換というわけにはいかないようだった。おとなしくアップルに修理に出すことにした。
|
|
アップルの修理サポートはチャットでアクセスできるようになっていて便利だった。チャットで見積と配送の手配をしてくれて，14日にヤマトさんが回収，20日には修理完了して戻ってきた。痛い出費ではあったが，3年使った LCD が新品になったと考えて納得することにする。
今回のことに懲りて，耐震ジェルを iMac に装着したので，次は大丈夫と思われる。
NetBeans のリファクタリングで Class の名前変更をしようとしたところ，「名前変更クラスxxx」のダイアログが出た時点でレインボーカーソルになってフリーズするようになった。設定ファイル (~/Library/Application Support/NetBeans/8.2/) を削除したり，キャッシュ (~/Library/Caches/NetBeans/8.2/) を消去したりしてみたが改善しなかった。
ふと思いついて，java の古いバージョンで立ち上げてみたところ症状が消失した。最新の java 1.8.0_152 ではなく，java 1.8.0_151 の方で試してみたら，これも大丈夫だった。
調べてみたら，奇数番号のアップデートは Critical Patch Update (CPU)，偶数は Patch Set Update (PSU) と呼ばれるアップデートで，PSU は CPU の変更＋次バージョン用のバグフィックスが含まれているようだ。今回は，PSU のバグフィックスの副作用で NetBeans に影響が出たと考えられる。
今月から突然事務で使っている Windows 10 マシンが勝手に再起動するようになった。事務からの報告によると，しばらく問題なく動いていても，突然入力を受け付けなくなって，その後画面が乱れて再起動してしまうとのことであった。Windows 10 マシン３台が同じ症状であったことから，ソフトウェアの問題と考えられた。
まずは，何が起きているかを確認するために，再起動時にエラーメッセージを残すように設定し，問題が起きたときに見せてもらうことにした。「起動と回復」の「自動的に再起動する」のチェックを外すと，再起動の前にエラーメッセージを表示して止まるようになる。
VIDEO_TDR_FAILURE (igdkmd64.sys)
当院の Windows マシンはオンボードグラフィック (インテル) を使っている。システムアップデートの時点で，インテルチップセットのビデオドライバがコンフリクトするようになったようだ。 ドライバのアップデートを捜してみたが，古いマシンなので，既にドライバは古いまま放置状態。仕方がないので，Microsoft 基本ドライバを使うことにした。
これにて症状は再現しなくなった。ビデオパフォーマンスについても，業務用に使うのであれば，基本ドライバで十分なようだ
