Баг в htb.init v0.8.5, связанный с переключением скорости по времени

Введение


При отладке правил шейпинга столкнулся с необычным поведением самого скрипта htb.init. Часть правил с параметрами TIME, где время переходит через полночь, не отрабатывались при наступлении указанного времени.

Шейпинг работает на виртуальном сервере с ОС Centos 5.7 x86_64 на борту.

Для примера возьмем описание правила для одного из классов — 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 мегабит, хотя подобные правила других классов отрабатывали.

Поиск


Так как у меня уже имеется опыт настройки шейпера, его такое поведение вызвало у меня бурю негодования. Начался процесс перечитывания документации и мануалов в поиске деталей, которых я, возможно, не учел или просто забыл. Ничего нового не обнаружив, решил покопаться в коде самого скрипта. Так как синтаксис правил был верен, сделал вывод, что нужно рассмотреть блок, где происходит обработка параметра TIME. Обработка этого параметра происходит при вызове скрипта с аргументом timecheck — выполняется изменение скорости передачи определенного класса в зависимости от периода времени. Все операции производятся в блоке switch в ветке timecheck.

Если более детально описать работу ветки: получение списка файлов с правилами для различных классов шейпинга из /etc/sysconfig/htb (путь по умолчанию). Затем в цикле просматриваем каждый файл по одному в поисках параметров TIME. Если параметр есть и текущее время попадает в указанные границы, то скорость для класса меняется. Все кажется вполне нормальным, но…

Катарсис


Заметил, что непонятное происходит, если промежуток времени проходит через полночь (как в приведенном мною выше примере): происходит модификация переменной 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 в цикл и закомментировать её вне цикла (как указано в коде выше). После внесения изменений скрипт будет отрабатывать множественные переходы через полночь как положено. Вариант без исправлений скрипта — всегда писать параметры TIME во всех классах таким образом, чтобы не было перехода через полночь.

P.S.


В Интернетах искал информацию о подобной проблеме, но ничего не нашел. Удивительно, что никто не сталкивался с этой проблемой, несмотря на широкое использование этого скрипта для шейпинга. Хотя, может, я плохо искал…
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 4

    0
    Прошу вас указать в комментариях свои замечания, дополнения к статье
      0
      Прежде чем заявлять, что /etc/sysconfig/htb является путём по умолчанию, стоит указать дистрибутив в котором всё это происходит.
        0
        Забыли — мой косяк. Путь этот по умолчанию для скрипта htb.init…
          0
          Спасибо. Так или иначе, но ОС следовало указать.

      Only users with full accounts can post comments. Log in, please.