トラブル

2023年2月 7日 (火)

自宅サーバのアップデート (1)

1月中旬に Ubuntu 18.04 + xen + ownCloud で運用していた自宅サーバ (mac mini 2011) で、いつもどおりレポジトリの更新をインストールしたら、dom-u の owncloud のネットワークがつながらなくなった。orz

振り返ってみると、自宅サーバは 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-VServerOpenVZ を比較検討して、xen を採用したという経緯があった。

今の状況だと、検討するとしたら準仮想化の kvm かコンテナ型の docker ということになると思う。今回は kvm で構築することにした。機会があれば docker も試してみたい気はする。

kvm のインストール

  1. kvm はカーネルに組み込まれているので、xen の様に hypervisor を新たにインストールする必要はない。開業当時、kvm が linux カーネルに組み込まれることが決定してニュースになっていたのを思い出す。
    $ 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
    
  2. 仮想マシンの管理には xl ではなく、libvirt (コマンドは virsh) を使う
    $ sudo systemctl enable --now libvirtd
    $ systemctl status libvirtd
    ● libvirtd.service - Virtualization daemon
         Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
               :
    
  3. br_netfilter を組み込んで無効にする。これをしておかないと、仮想マシンが外に出られない。(元々 xen の dom-u がつながらなくなった件もこれが原因かと思ったのだが、この設定をしてもつながらなかった)
    /etc/modules-load.d/modules.conf
    # /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
    
  4. netplan でブリッジ br0 を作る
    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
    
  5. その br0 を使う network を定義する br0.xml を作って、virsh で kvm 用のネットワーク設定を作る。できた kvm 用のネットワーク設定は /etc/libvirt/qemu/networks/ に入る。
    $ 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
    
  6. ブリッジの起動と、自動起動の設定
    $ 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 にあたる部分の設定が完了。

2023年2月 3日 (金)

Java 17 への移行(6) - Hibernate 6 でやらかす

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 なので最大 9,223,372,036,854,775,807 までしか使えない。当院の hibernate_sequence は 15年で既に 2,725,392 に達しており、このままのペースで行くと 50,763,552,748,661年後には使い果たしてしまうことになる。

2019年7月 2日 (火)

orca パッチ後の受付トラブル〜原因

土曜日の orca パッチ後のトラブルであるが,原因は api のアップデートであった。

□対応範囲:API
□管理番号:request20181010-001
□問い合わせ(不具合)及び改善内容
 ORCA APIを使い受付一覧を取得する機能がありますが,ORCA上で受付順変更を行っても,
 APIで返されるXMLには新しい順番の情報は無く,
 [Acceptlst_Information_child]の出力順も,もともとの順番と変わりがありません.
 受付変更の結果をなんらかの形で取得できるようにして下さい.
□対応内容
 API受付一覧(/api01rv2/acceptlstv2)にて受付順変更を反映するようにしました。
 ────────────────────────────────────
□対応範囲:API
□管理番号: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 の間違いと考えられる。

2019年7月 1日 (月)

orca パッチ後の受付トラブル

土曜日の朝,いつものように 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 がこんな形で役に立つとは思わなかった。

2019年6月17日 (月)

ネットワークが遅くなる

どうも最近サーバのデータバックアップに以前より時間がかかっているように感じていた。こんなもんだったかなー,とそのままにしていたが,ふとハブのサーバとのリンクがオレンジ (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 ケーブルであった。サーバをいじったときに無理な力をかけて断線させてしまったのかもしれない。

2019年3月16日 (土)

複合機の蝶番修理

受付から,コピー機として使っている複合機のあたりからすごい音がして,蓋が開きにくくなったとの連絡あり。確認したところ,プラスチックの蝶番が折れていた。こういう力のかかるところにプラスチックの部品は無理なんじゃないんだろうか。というわけで,板金加工で修理した。

22 2

2018年9月23日 (日)

地震で iMac のディスプレー割れる

9月6日午前3時7分,北海道胆振東部地震が発生し,当院のある札幌市東区は震度6弱に見舞われた。 停電のため地下鉄が動かず,信号機も消えてしまって道路も混乱,夜が明けてから歩いて医院に状況確認に行ったところ,iMac が全部画面を下に倒れてしまっており,1台 (iMac Late 2015) でディスプレーのガラスが割れてしまっていた。

Inchoroom Img_7893 Img_7891

停電のため診療どころか掃除機すら使えない状態であったが,7日午後までには電気が回復,バックアップマシン (iMac Mid 2010) を立ち上げ,卸さんに電話して冷蔵の薬品を注文,8日から診療を再開した。停電の影響で物流は大混乱,食料の入手にも一苦労の状態だったが,薬品はちゃんと8日朝に届いた。ありがたいことである。

当初,壊れた iMac はガラスが割れただけに見えたので,ガラスだけ買って交換すればいいと考えていた。しかし,調べてみると,最近の iMac は薄くするために表面のガラスと LCD が一体化しているらしく,ガラスだけ交換というわけにはいかないようだった。おとなしくアップルに修理に出すことにした。

Chat1 Chat2

アップルの修理サポートはチャットでアクセスできるようになっていて便利だった。チャットで見積と配送の手配をしてくれて,14日にヤマトさんが回収,20日には修理完了して戻ってきた。痛い出費ではあったが,3年使った LCD が新品になったと考えて納得することにする。

今回のことに懲りて,耐震ジェルを iMac に装着したので,次は大丈夫と思われる。

2017年12月 8日 (金)

java 1.8.0_152 で NetBeans フリーズ

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 に影響が出たと考えられる。


1.8.0_161, 1.8.0_162 でも直っていなかった。bugzilla に報告されていた

2017年6月19日 (月)

Windows 10 マシンが突然再起動する

今月から突然事務で使っている Windows 10 マシンが勝手に再起動するようになった。事務からの報告によると,しばらく問題なく動いていても,突然入力を受け付けなくなって,その後画面が乱れて再起動してしまうとのことであった。Windows 10 マシン3台が同じ症状であったことから,ソフトウェアの問題と考えられた。

まずは,何が起きているかを確認するために,再起動時にエラーメッセージを残すように設定し,問題が起きたときに見せてもらうことにした。「起動と回復」の「自動的に再起動する」のチェックを外すと,再起動の前にエラーメッセージを表示して止まるようになる。

Reboot

その結果,ブルースクリーンで以下のエラーが確認できた。
VIDEO_TDR_FAILURE (igdkmd64.sys)

当院の Windows マシンはオンボードグラフィック (インテル) を使っている。システムアップデートの時点で,インテルチップセットのビデオドライバがコンフリクトするようになったようだ。 ドライバのアップデートを捜してみたが,古いマシンなので,既にドライバは古いまま放置状態。仕方がないので,Microsoft 基本ドライバを使うことにした。

  • ドライバを外すと画面が真っ黒になるので,あらかじめ電源スイッチで電源オフできるようにしておく。
  • ビデオドライバを外す。

    0003

  • 画面が真っ黒になるので,少し待ってからスイッチオフ,その後スイッチオン。
  • 再起動後,自動的に元のドライバに更新されてしまうが,「ドライバーを元に戻す」が選択できるようになる。

    0004

  • ドライバーを元に戻すと,Microsoft 基本ディスプレイアダプターがインストールされる。

    0006

これにて症状は再現しなくなった。ビデオパフォーマンスについても,業務用に使うのであれば,基本ドライバで十分なようだ

2017年4月28日 (金)

ATOK29 関連フリーズ

診察室の iMac が,4月初めの 10.12.14 アップデートの後くらいから,1日に1回〜数日に1回程度,レインボーカーソルを出してフリーズするようになった。再現頻度が低いので,なかなか原因がつかめなかったが,top コマンドの監視でついに ATOK29 が CPU を食い尽くしている現場をつかまえた。

Atok29freeze

うすうす予想はついていたが,やっぱりまたおまえかー!という感じである。その後は,とりあえず cputhrottle で ATOK の動きを制御して対応していた。

$ sudo ./cputhrottle ${atokのpid} 10

いろいろ Web を検索してみたところ,「ATOKインサイト」のトラブルが結構報告されていたため,試しに切ってみた。環境設定の「変換補助>一時文書学習候補を表示する」を外すことでATOKインサイトが常駐しなくなる。

Atokenviron

その後10日くらい運用してみたが,フリーズは再現しなかった。試しに ATOKインサイトを再び ON にしてみたところ,その日の夕方にフリーズが再現したため,どうやら ATOK インサイトが関係している可能性が高い。ATOKインサイトは切って運用することにした。


追記) その後 ATOK30 にアップデートして,ATOKインサイトを入れても全く問題なく使えている。