Bug in htb.init v0.8.5, associated with the switching speed in time

Introduction

When debugging the rules of shaping, I encountered the unusual behavior of the htb.init script itself . Part of the rules with the TIME parameters, where time goes over midnight, was not practiced when the specified time arrived.

Shaping works on a virtual server with Centos 5.7 x86_64 OS on board.

For example, take the description of the rule for one of the classes - 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 

At 19 o'clock, the speed for the class did not switch from 50 to 70 megabits, although similar rules of other classes were worked out.

Search

Since I already have experience in setting up the shaper, his behavior caused a storm of indignation in me. The process of re-reading documentation and manuals in search of details, which I could not have learned or just forgot, began. Having found nothing new, I decided to delve into the code of the script itself. Since the syntax of the rules was correct, he concluded that it is necessary to consider the block where the TIME parameter is processed. Processing of this parameter occurs when the script is called with the timecheck argument — the transfer rate of a certain class is changed depending on the time period. All operations are performed in the switch block in the timecheck branch.
')
To describe the branch in more detail: getting a list of files with rules for various shaping classes from / etc / sysconfig / htb (the default path). Then loop through each file, one at a time, looking for TIME parameters. If the parameter is present and the current time falls within the specified limits, then the speed for the class changes. Everything seems quite normal, but ...

Catharsis

I noticed that the incomprehensible happens if the time interval passes through midnight (as in the example I have given above): the TIME_ABS variable containing the current time value is modified. It would be normal if this variable was only inside the loop. Then its changes will not affect the processing of the rules of other classes. And changes to this variable occurred in the case of processing rules that have a transition through midnight. But it was declared out of cycle, therefore it accumulated the values ​​of previous iterations. This is where the dog was buried - some of the rules were passed through midnight and some were not. The “current” time gradually “ran away” and no longer fell into any boundaries defined by the TIME parameters in the rules.

Here is the part of the script:

 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 ;; 

How to fix it

It is necessary to transfer the declaration of the TIME_ABS variable to the loop and comment it out of the loop (as indicated in the code above). After making changes, the script will work through multiple transitions through midnight as expected. Option without script corrections - always write TIME parameters in all classes in such a way that there is no transition through midnight.

PS

I searched the Internet for information about a similar problem, but found nothing. It is surprising that no one has encountered this problem, despite the widespread use of this script for shaping. Although, maybe I was looking bad ...