2023/11/12(日)Python 一部モジュール・ライブラリが更新できない
2023/11/13 1:03
通常、ＯＳバージョンアップの場合、前バージョンまでの動作互換性は保証しているので、必ずしも必要ではないはずなのですが、それでも不可解な挙動が生じる場合があり、それを未然に防ぐために「全てのアプリケーション再構築」という作業を行うことにしているのです。
多くのマトモな方々には信じられないかもしれないですが、この事業を始めたばかりの頃、
『たった１回のアプリケーション障害で、しかもたった１日で一方的なサーバホスティング解消』をされたことがあり、これは純粋にアプリケーションの不具合で、ＯＳアップデートが問題ということでもなく、運用側でどうすることも出来ない不可抗力な原因の事象でした。
当然、「一方的」だったので、説明責任のかけらも果たすことが出来ませんでした。
まぁ、そんなに信用できないなら「最初から易々と近づくな」と言いたいし、何より舐められまくってますね。
そんな態度の「上から目線なクライアント」は、相手にしないことは言うまでもないです。
きっと、他所でも毛嫌いされていることだろうと思われます。
２０年以上やっていますが、この類の不具合は、この件含めて２回。
２回目は説明責任果たせたので、理解してもらえました。過去２０年に限れば安定稼働しています。
前置きが長くなり過ぎたのですが、ここから本題。
FreeBSD12 → FreeBSD13 にＯＳアップデートして、アプリケーション再構築をすると、一部の 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(土)整流回路の平滑コンデンサは容量が大きければいいというものではないらしい
2023/04/15 6:09
１０年近く前に、PC-9801 のBASIC で組んで公開されていた整流回路シミュレーションがあったので、手元のMZ-2500 BASIC-M25 に移植して使っています。最低限機能させるための移植なので、色々変な部分はあるんですが。。orz
引用元の書籍を紹介しようとして、手持ちの書籍を漁ったのですが、何故か見つからない。
ということで、「原作者の方、申し訳ないです・・・」ということで、、、
いずれにしても、MZ-2500だったから移植出来たのです。他の機器だったら、かなり苦しい。
ここから本題なのですが、当初は、こんなふうにしていました ↓
そして、おもむろにこのシミュレーションを動作させてみると・・・
負荷電流１Ａという、意図的に悪い動作条件を与えたんですが、こんな感じになりました。
黄色の線は電流を示しますが、正確ではないし、描画がおかしいので、とりあえず無視。
注目すべきは赤っぽい実線。
このあとに５Ｖ出力の３端子レギュレータが繋がるのですが、安定動作には7.5Ｖ以上の電圧が必要なので、14ms あたりまでは何かしらの不具合が出る可能性がある。
静電容量が大きすぎて、電圧が上がり切りません。
ということで、平滑コンデンサ C01 を下記のようにしてみました ↓
静電容量だけ変えて、他は同じ条件です。
ここまでは、安定化電源装置を動作させるための補助電源部の話で、
本当の本題は、PT2-D3-C05 で構成する、この平滑回路です ↓
22mF(22,000μF)というオーディオアンプの電源に使うような大容量電解コンデンサを当初使っていました。
安定化電源装置の最高出力電圧は２４Ｖ、最高出力電流は３Ａの設計です。
２４Ｖの安定化出力を出すためには、平滑回路の電圧は２７Ｖは欲しい。
これを安定化電源装置の設計最大電流である３Ａでシミュレーションさせると・・・
40ms あたりまで、所要の電圧にはならないことが判りました。
試行錯誤で、落ち着いたのがこれ ↓
シミュレーション結果は以下。
ギリギリ大丈夫か？ みたいな感じです。今までは経験と勘だけで適当に決めていたところだったが。。orz
Rs というのは、変圧トランスやコンデンサを結線する配線抵抗等ですが、これを正確に決めるのは難しく、代表的な値として0.5Ωと見做すことが多い模様。
恐らく、殆どのケースでは0.5Ωよりも小さく、このシミュレーションで得られる電圧よりは若干高めになると思います。
シミュレーション上の紫の実線の山と赤っぽい実線の山の間隔が広いと、それだけ電力損失が増え、整流ダイオードあたりが発熱しやすくなるのではないかと思われます。
ですが、このことがパワートランジスタの破損に直結するとは思えないです。
2023/02/26(日)perl で子プロセスで su を実行させると、親プロセスも道づれで消える
2023/02/26 18:32
《起 動》 ↓ ┌─→《接続要求待ち》 ← ＬＡＮ・ＷＡＮからの接続要求 │ ↓ │ 《接続応答》 │ ↓ │ 《子プロセスをfork()》→────┐ │ ↓（親プロセス） │（子プロセス） │ │ ↓ │ │ 《実処理》 │ │ │ ｜ 《子プロセス終了待ち》←──《処理終了》 │ ↓ └←《次の接続を待つ》のような概略構造で、 root 権限で稼働させる代物だが、この構造で、子プロセス内で、perl にて
$status = system (/usr/bin/su username -c "exec comannd ... ") ;
または
$result = `/usr/bin/su username -c "exec comannd ... "`
みたいなことをやらせると、当該処理は実行するものの、実行後、親プロセスまでも終了してしまう。
どちらも更に子プロセスを起こし、 username 権限で実行するというところまでは各所に記載があるため判るが、処理終了時の動作については記載が見当たらず、これ以上の調査に時間を費やせないという現実。
結局、su をやめ、root 権限で動作させ、実行後、このプログラムで生成された必要なファイルを chown するという策で回避。
バグなのかもしれないが、何かやらかしてなるべきしてこうなっているかも知れずで、よく判らないところですね。