はじめに
シェーピングルールをデバッグするときに、 htb.initスクリプト自体の異常な動作に遭遇しました。 午前0時以降に時間が経過するTIMEパラメーターを使用したルールの一部は、指定された時刻に到達したときに解決されませんでした。
シェーピングは、Centos 5.7 x86_64 OSが搭載された仮想サーバーで実行されます。
たとえば、クラス-eth0-2：6：19.unlimのいずれかのルールの説明を見てみましょう。
TIME=08:00-19:00;2Kbit,50Mbit TIME=19:00-08:00;2Kbit,70Mbit RATE=2Kbit CEIL=50Mbit LEAF=sfq PRIO=2 MARK=0x19
19時間で、クラスの速度は50メガビットから70メガビットに切り替わりませんでしたが、他のクラスでも同様のルールが有効でした。
検索する
シェイパーのセットアップの経験がすでにあるので、この振る舞いはinりの嵐を引き起こしました。 ドキュメントとマニュアルを読み直すプロセスは、私が考慮していなかった、または単に忘れていたかもしれない部品を探して始まりました。 新しいものは何も見つからなかったため、彼はスクリプト自体のコードを詳しく調べることにしました。 ルールの構文が正しいため、 TIMEパラメーターが処理されるブロックを考慮する必要があると結論付けました。 このパラメーターの処理は、引数timecheckを使用してスクリプトが呼び出されたときに発生します。特定のクラスの伝送速度は、期間に応じて変更されます。 すべての操作は、 timecheckブランチのswitchブロックで実行されます。
/ etc / sysconfig / htb （デフォルトパス）からさまざまなシェーピングクラスのルールを含むファイルのリストを取得することで、ブランチの操作をさらに詳しく説明します。 次に、ループで、 TIMEパラメーターを検索して各ファイルを1つずつ調べます。 パラメーターがあり、現在の時間が指定された制限内に収まる場合、クラスの速度が変わります。 すべてが非常に正常なようですが、...
カタルシス
時間間隔が真夜中を過ぎると（上記の例のように）理解できないことが起こることに気付きました：現在の時間の値を含むTIME_ABS変数が変更されます。 この変数がループ内のみにある場合、これは正常です。 その変更は、他のクラスのルールの処理には影響しません。 そして、真夜中以降に遷移するルールを処理する場合、この変数への変更が発生しました。 しかし、ループの外側で宣言されたため、前の反復の値を累積しました。 ここで犬は埋葬されました-真夜中を通過するルールの一部は解決され、一部はそうではありませんでした。 「現在の」時間は次第に「逃げ出し」、ルールのTIMEパラメーターで定義された境界に収まりません。
スクリプトの一部は次のとおりです。
timecheck) TIME_TMP=`date +%w/%k:%M` TIME_DOW=${TIME_TMP%%/*} TIME_NOW=${TIME_TMP##*/} #TIME_ABS=`htb_time2abs $TIME_NOW` ### Check all classes (if configured) for classfile in `htb_class_list`; do TIME_ABS=`htb_time2abs $TIME_NOW` ........ htb_message "$TIME_NOW: change on $DEVICE:$CLASS ($RATE_NOW/$CEIL_NOW -> $NEW_RATE/$NEW_CEIL)" done ### class file ;;
修正方法
TIME_ABS変数の宣言をループに転送し、ループからコメントアウトする必要があります（上記のコードに示されているように）。 変更を行った後、スクリプトは午前0時以降の複数の遷移を予想どおりに実行します。 スクリプトを修正しないオプションは、すべてのクラスにTIMEパラメーターを常に書き込むことで、午前0時以降は遷移しません。
PS
同様の問題に関する情報をインターネットで検索しましたが、何も見つかりませんでした。 驚くべきことに、このスクリプトをシェーピングに広く使用しているにもかかわらず、誰もこの問題に遭遇していません。 でも、たぶん私はひどく見ていました...