2023/11/12(日)Python 一部モジュール・ライブラリが更新できない

FreeBSD12 → FreeBSD13 に更新後、アプリケーションのライブラリ等が旧OSバージョンにて構築したものだったりすると、それが原因で謎の動作不具合起こしたりする場合が稀にあるため、「安定動作」を目的として、全てのアプリケーションを再構築します。

通常、OSバージョンアップの場合、前バージョンまでの動作互換性は保証しているので、必ずしも必要ではないはずなのですが、それでも不可解な挙動が生じる場合があり、それを未然に防ぐために「全てのアプリケーション再構築」という作業を行うことにしているのです。

多くのマトモな方々には信じられないかもしれないですが、この事業を始めたばかりの頃、
『たった1回のアプリケーション障害で、しかもたった1日で一方的なサーバホスティング解消』をされたことがあり、これは純粋にアプリケーションの不具合で、OSアップデートが問題ということでもなく、運用側でどうすることも出来ない不可抗力な原因の事象でした。

当然、「一方的」だったので、説明責任のかけらも果たすことが出来ませんでした。
まぁ、そんなに信用できないなら「最初から易々と近づくな」と言いたいし、何より舐められまくってますね。
そんな態度の「上から目線なクライアント」は、相手にしないことは言うまでもないです。
きっと、他所でも毛嫌いされていることだろうと思われます。
20年以上やっていますが、この類の不具合は、この件含めて2回。
2回目は説明責任果たせたので、理解してもらえました。過去20年に限れば安定稼働しています。

前置きが長くなり過ぎたのですが、ここから本題。
FreeBSD12 → FreeBSD13 にOSアップデートして、アプリケーション再構築をすると、一部の Python アプリケーションが再構築出来ずに、以下のようなエラーを吐いてしまう。
  File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 972, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 850, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/usr/local/lib/python3.9/site-packages/setuptools/__init__.py", line 18, in 
    from setuptools.dist import Distribution
  File "/usr/local/lib/python3.9/site-packages/setuptools/dist.py", line 34, in 
    from ._importlib import metadata
  File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 39, in 
    disable_importlib_metadata_finder(metadata)
  File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 28, in disable_importlib_metadata_finder
    to_remove = [
  File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 31, in 
    if isinstance(ob, importlib_metadata.MetadataPathFinder)
AttributeError: module 'importlib_metadata' has no attribute 'MetadataPathFinder'

ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel
*** Error code 1
この現象は、時々起きるらしく、外国のメンテナンス作業者の解決策として、どうやら
# cd /usr/local/lib
# rm -rf python3.*
としてから、
# portupgrade -rf python.3.9.18
(インストールされている Python バージョンに合わせる)
とすると、解消する模様。やや強引かつ豪快な解決手段だが、これが確実なのだとか。
これをやったら、確かに問題は解消しました。

2023/04/15(土)整流回路の平滑コンデンサは容量が大きければいいというものではないらしい

自作の安定化電源装置にて、再びパワートランジスタが破損したので、その原因を調査している途上で設計を色々見直しているのだが・・・
10年近く前に、PC-9801 のBASIC で組んで公開されていた整流回路シミュレーションがあったので、手元のMZ-2500 BASIC-M25 に移植して使っています。最低限機能させるための移植なので、色々変な部分はあるんですが。。orz

引用元の書籍を紹介しようとして、手持ちの書籍を漁ったのですが、何故か見つからない。
ということで、「原作者の方、申し訳ないです・・・」ということで、、、
いずれにしても、MZ-2500だったから移植出来たのです。他の機器だったら、かなり苦しい。

ここから本題なのですが、当初は、こんなふうにしていました ↓
20230415_6800uF.png


そして、おもむろにこのシミュレーションを動作させてみると・・・
20230415_6800uF.jpg


負荷電流1Aという、意図的に悪い動作条件を与えたんですが、こんな感じになりました。
黄色の線は電流を示しますが、正確ではないし、描画がおかしいので、とりあえず無視。
注目すべきは赤っぽい実線。
このあとに5V出力の3端子レギュレータが繋がるのですが、安定動作には7.5V以上の電圧が必要なので、14ms あたりまでは何かしらの不具合が出る可能性がある。
静電容量が大きすぎて、電圧が上がり切りません。

ということで、平滑コンデンサ C01 を下記のようにしてみました ↓
20230415_2200uF.png


静電容量だけ変えて、他は同じ条件です。
20230415_2200uF.jpg


ここまでは、安定化電源装置を動作させるための補助電源部の話で、
本当の本題は、PT2-D3-C05 で構成する、この平滑回路です ↓
20230415_22000uF.png


22mF(22,000μF)というオーディオアンプの電源に使うような大容量電解コンデンサを当初使っていました。
安定化電源装置の最高出力電圧は24V、最高出力電流は3Aの設計です。
24Vの安定化出力を出すためには、平滑回路の電圧は27Vは欲しい。
これを安定化電源装置の設計最大電流である3Aでシミュレーションさせると・・・
20230415_22000uF.jpg


40ms あたりまで、所要の電圧にはならないことが判りました。
試行錯誤で、落ち着いたのがこれ ↓
20230415_4700uF.png


シミュレーション結果は以下。
20230415_4700uF.jpg

ギリギリ大丈夫か? みたいな感じです。今までは経験と勘だけで適当に決めていたところだったが。。orz

Rs というのは、変圧トランスやコンデンサを結線する配線抵抗等ですが、これを正確に決めるのは難しく、代表的な値として0.5Ωと見做すことが多い模様。
恐らく、殆どのケースでは0.5Ωよりも小さく、このシミュレーションで得られる電圧よりは若干高めになると思います。

シミュレーション上の紫の実線の山と赤っぽい実線の山の間隔が広いと、それだけ電力損失が増え、整流ダイオードあたりが発熱しやすくなるのではないかと思われます。
ですが、このことがパワートランジスタの破損に直結するとは思えないです。

2023/02/26(日)perl で子プロセスで su を実行させると、親プロセスも道づれで消える

ごく単純と思われる、サーバプログラムで、
     《起 動》
       ↓
  ┌─→《接続要求待ち》 ← LAN・WANからの接続要求
  │    ↓
  │  《接続応答》
  │    ↓
  │  《子プロセスをfork()》→────┐
  │    ↓(親プロセス)      │(子プロセス)
  │    │             ↓
  │    │           《実処理》
  │    │             │
  |  《子プロセス終了待ち》←──《処理終了》
  │    ↓
  └←《次の接続を待つ》
のような概略構造で、 root 権限で稼働させる代物だが、この構造で、子プロセス内で、perl にて

$status = system (/usr/bin/su username -c "exec comannd ... ") ;

または

$result = `/usr/bin/su username -c "exec comannd ... "`

みたいなことをやらせると、当該処理は実行するものの、実行後、親プロセスまでも終了してしまう。
どちらも更に子プロセスを起こし、 username 権限で実行するというところまでは各所に記載があるため判るが、処理終了時の動作については記載が見当たらず、これ以上の調査に時間を費やせないという現実。

結局、su をやめ、root 権限で動作させ、実行後、このプログラムで生成された必要なファイルを chown するという策で回避。
バグなのかもしれないが、何かやらかしてなるべきしてこうなっているかも知れずで、よく判らないところですね。