開発マシン上WSL2/Alpine/docker-composeでkafkaを動かそうとしたら手間取ったので、備忘録。

• WSL2で動かすLinuxのIPアドレスはホストWindowsによってプライベートアドレスを与えられ、Windows起動の度に変わる(おそらくセキュリティ向上のため)
• DHCPはLinux起動時にWSL2で特別な処理が行われているようで、/etc/network/interfaceに記載してもおそらく無視される
• /etc/network/interfaceに書かれた内容はLinux起動後ifdown/ifupコマンドでstaticは反映されるが、DHCPはサーバーが見つからない理由でエラーになる
• 上記DHCPが失敗した状態では、WSL2ホストマシン外と通信できない(Hyper-Vの仮想スイッチ設定をいじればできる？)
• 一方dockerコンテナ上のkafkaは、ADVERTISED_HOST設定のため毎回変わるアドレスでは運用しづらい

Hyper-Vの仮想スイッチをいじると他のLinuxディストリビューションと併用する時に副作用が出そうなので、対象Linuxにプライベート固定アドレスを追加する方法を採る。アドレス例として

• 192.168.99.1: WSL2ホスト側のアドレス(=Windows)
• 192.168.99.100: Windowsから見たLinux側のアドレス

Windows側

仮想スイッチ'vEthernet (WSL)'はWSL2起動時に作成されるようなので、先にLinuxディストリビューションを起動しておく。このスイッチにホストWindowsのアドレスを追加。要管理者権限。Windows再起動ごとに行う。

 netsh interface ip add address "vEthernet (WSL)" 192.168.99.1 255.255.255.0

Linux側(dockerホスト on WSL2)

Linuxに固定アドレスを与える。要root。こちらもLinux起動ごとに必要。

ip addr add 192.168.99.100/24 dev eth0

Linux側(docker-compose)

wurstmeister/kafka-docker を使用。docker-compose.yml変更点は

• kafkaのportsを9092:9092に
• KAFKA_ADVERTISED_HOST_NAMEを書き換え

docker-compose後はホストWindowsからはbootstrap-server=192.168.99.100:9092でkafkaにアクセス可能。

version: '2'
services:
  zookeeper:
    image: wurstmeister/zookeeper
    ports:
      - "2181:2181"
    restart: unless-stopped

  kafka:
    build: .
    ports:
      - "9092:9092"
    environment:
      DOCKER_API_VERSION: 1.22
      KAFKA_ADVERTISED_HOST_NAME: 192.168.99.100
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    restart: unless-stopped

[参考]

• vm/wsl2に固定IPでssh-server
• Docker in WSL2 Alpine without Docker Desktop (stackoverflow)

YOLO リポジトリに含まれるdarknet_images.pyに複数画像一括処理を行うbatch_detectionという関数があるのですが、2枚以上の画像を処理させようとするとC側関数実行中にOSError/access violation例外が発生。1枚(要素数1の配列を渡す)は正常に処理されることから、ポインタの渡し間違いという類ではなさそう。

結論

import numpy as np
from ctypes import *

def makeArray():
    arr = numpyの配列を作る
    return arr.ctypes.data_as(ctypes.POINTER(ctypes.c_float))


c_func(makeArray())

みたいに関数でnumpy配列作ってctypesのポインタだけを返している場合、arrのサイスが大きいと関数抜けた時点でarrがガベージコレクションされてしまい、data_as()で得たアドレスはc_funcが呼ばれる前に無効になる可能性がある。

今回のYOLOの件は画像1枚だとたまたまガベコレされなかっただけで、本質的には危険なのでしょう。具体的にはdarknet_images.pyのprepare_batch()関数でbatch_arrayがガベコレされてしまいます。手っ取り早い解決としては、同ファイル内で

• prepare_batch()の返値にbatch_arrayを含めるようにし、呼び出す側のbatch_detection()はC関数darknet.network_predict_batch()を呼び終えるまでbatch_arrayを保持する
• prepare_batch()とbatch_detection()を一つの関数にまとめ、batch_arrayがガベコレされないようにする

でしょうか。前者はコード的にあまり美しくなさそうですが。

私と同じ問題にあたる人は稀でしょうが、本質的な理由はWindows/Linux関係なく起こりそう。ctypesのいい勉強になりました。

[参考]

• Can ctypes.data_as always be relied upon to keep references to temporaries? (stackoverflow)

JupyterLabを起動するとIndexError: pop from an empty dequeというエラーが出て落ちてしまう現象が私の環境でも発生。GitHubの掲示板 の内容と私の環境(WinPython 3.10.4.amd64)での現象を総合すると、

• JupyterLab起動と連動してブラウザが立ち上がり(これが既定の動作)、複数のタブ(Python Kernel)が開くようになっていると発生
• Windowsでより起きやすいが、Linuxでも起きる

回避策としては以下のどれかを実行。

• JupyterLabを--no-browserオプションをつけて起動、コマンドラインに表示されるURLを別途ブラウザで開く(起動時後短時間で複数Kernelを立ち上げることの回避)[2022/7/20] これでも落ちました
• JupyterLab終了時に開いているタブを1つ以下にする。ただしこの問題が出ているということはJupyterLabはすぐに落ちてしまうので
• 前述と同じ--no-browserで起動してタブを閉じる。一番着実。
• 起動-ブラウザが自動的に開く-JupyterLabが落ちる間に不要なタブを閉じる。短時間なので一つずつ、がんば。
• めげずにJupyterLabの起動を繰り返す。運が良ければ落ちないときがある。
• .ipynb_checkpointsを消すとか、__pycache__を消す。ただし再発する報告あり。

[参考]

Failure to start jupyter lab --- IndexError: pop from an empty deque #11934 (GitHub)

オンラインライセンス認証で使用しているVisual Studio 2013のライセンス更新をしようとしたところ、更新できないとの表示。一度サインアウトして入りなおすなどするうちに'Sorry, we ran into a problem' (英語版使ってるので、日本語表記は不明。「申し訳ございません。問題が発生しました」くらい？)という表示が出る。

どうやらサーバーの方がTLS1.2暗号化を必要とする変更が入ったとのことで、以下のレジストリを追加・Visual Studio再起動後改めてライセンス更新をすると成功しました。

VSが余りに古くてついにMSから使用停止食らったかと焦った…

[HKEY_LOCAL_MACHINE¥SOFTWARE¥WOW6432Node¥Microsoft¥.NETFramework¥v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

レジストリファイル添付しておきますが、ご利用は自己責任で。

[参考]

• 'The Online Service is not available' Issue in Visual Studio Professional 2013 with Update 5 (stack overflow)

失敗談。

Windowsで運用中のMercurialのリポジトリバックアップにrobocopyコマンドを/MOTオプションを付けて実行してました。はい、定期的に変更点を見つけて宛先を最新にし続けるというあのオプションです。そんな運用する奴いねぇよというツッコミはスルーの方向で。

はじめは短期間の運用だったはずなのですが、あれよあれよと数カ月経過。robocopyを終了し複製の方のリポジトリを使おうとすると、コミットが終わらない!?

原因はMercurialが排他制御に使う.hg/store/lockファイル。リポジトリが更新中の時だけ作成されその後消えるのですが、たまたまrobocopyがそれを見つけて宛先にコピー。宛先にはそれが残り続けたため、複製にコミットしようとしたMercurialはlockファイルが消えるのを延々待っていたと。

robocopyには/PURGEオプションを付けましょう。これでも短時間複製リポジトリにlockファイルが存在する可能性はありますが、激減するはず。