[過去ﾛｸﾞ] Docker Part4 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
823(1): 2020/11/12(木)08:44 ID:tXLSOFMO(4/7) AAS
>>822
iaxmodemだけなら小さい消費だが、
それらをfaxgettyさせてhylafaxに接続すると、
5倍くらいに膨れ上がった。
825: 2020/11/12(木)14:22 ID:tXLSOFMO(5/7) AAS
>>824
参考になります。
iaxmodemが始動されると、プロセスが生成されます。
その後、hylafaxを始動させて、
さらに別途faxgettyによって、両者を連結させるイメージです。（3者登場します。そのうち、iaxmodemと、faxgettyはたくさん。hylafaxとは、多対１の関係になっています。）
>>823のように、iaxmodemだけでは専有容量は僅かなんですが、
faxgettyさせると、膨れ上がります。
faxgettyは、hylafaxの関係者なので、
hylafaxがガーベージコレクトするようです。
以前テストした結果は、hylafaxの再起動時には、直ちにfaxgettyプロセスは消滅しました。
しかし、今回の環境ではそういう風にならなかったようです。
前回の環境はCentOS6でネイティブ、今回はCentOS7でコンテナです。
iaxmodemや、hylafaxのバージョンも上がっています。
いずれにしても、デーモンの再起動が特殊です。
逆に考えて、ネイティブ環境でも他の要因で同じ問題を引き起こすなら、
コンテナ環境であってよかったと思います。
docker restart faxContainerをcrontabでコンテナの外側ホストでスケジュールすれば良いのですから。
コンテナ内部でそういうデーモンの消滅のスケジュールを組むと、イメージ化されていることからタイミングの変更が困難になるので、
せっかくの利便性を損なうと思いました。
docker restart faxContainer は素晴らしいです。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.035s