Htb.init v0.8.5 में एक बग समय के साथ स्विचिंग गति से संबंधित है

परिचय

शेपिंग नियमों को डिबग करते समय, मुझे स्वयं htb.init स्क्रिप्ट के असामान्य व्यवहार का सामना करना पड़ा। 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 मेगाबिट्स पर स्विच नहीं हुई, हालांकि अन्य वर्गों के लिए भी इसी तरह के नियमों ने काम किया।

खोज

चूंकि मेरे पास पहले से ही एक शेपर स्थापित करने का अनुभव है, इस व्यवहार ने मुझे आक्रोश का तूफान पैदा कर दिया। प्रलेखन और नियमावली को फिर से पढ़ने की प्रक्रिया उन हिस्सों की तलाश में शुरू हुई, जिन्हें शायद मैंने ध्यान में नहीं रखा या भूल नहीं गया। कुछ भी नया नहीं मिलने पर, उन्होंने स्क्रिप्ट के कोड में ही बदलाव करने का फैसला किया। चूंकि नियमों का सिंटैक्स सही था, इसलिए मैंने निष्कर्ष निकाला कि हमें उस ब्लॉक पर विचार करने की आवश्यकता है जहां टाइम पैरामीटर संसाधित किया जाता है। इस पैरामीटर का प्रसंस्करण तब होता है जब स्क्रिप्ट को तर्क टाइमचेक के साथ कहा जाता है - समय अवधि के आधार पर एक निश्चित वर्ग की ट्रांसमिशन गति को बदल दिया जाता है। सभी ऑपरेशन टाइमचेक शाखा में स्विच ब्लॉक में किए जाते हैं ।

यदि आप शाखा के संचालन का अधिक विस्तार से वर्णन करते हैं: / etc / sysconfig / htb (डिफ़ॉल्ट पथ) से विभिन्न आकार देने वाली कक्षाओं के नियमों वाली फ़ाइलों की सूची प्राप्त करें। फिर एक लूप में हम TIME पैरामीटर्स की खोज में एक-एक करके हर फाइल को देखते हैं। यदि कोई पैरामीटर है और वर्तमान समय निर्दिष्ट सीमाओं के भीतर आता है, तो वर्ग की गति बदल जाती है। सब कुछ काफी सामान्य लग रहा है, लेकिन ...

साफ़ हो जाना

मैंने देखा कि यदि समय अंतराल आधी रात से गुजरता है (जैसा मैंने ऊपर दिया उदाहरण में): वर्तमान समय के मूल्य वाले TIME_ABS चर को संशोधित किया गया है, तो समझ में नहीं आता है। यह सामान्य होगा यदि यह चर केवल लूप के अंदर था। तब इसके परिवर्तन अन्य वर्गों के नियमों के प्रसंस्करण को प्रभावित नहीं करेंगे। और इस चर में परिवर्तन प्रसंस्करण नियमों के मामले में हुआ है जिनके मध्यरात्रि के बाद संक्रमण होता है। लेकिन यह लूप के बाहर घोषित किया गया था, इसलिए इसने पिछले पुनरावृत्तियों के मूल्यों को संचित किया। यहां कुत्ते को दफनाया गया था - आधी रात के माध्यम से पारित होने के साथ नियमों का हिस्सा काम किया गया था, और भाग - नहीं। "वर्तमान" समय धीरे-धीरे "भाग गया" और अब नियमों में टाइम पैरामीटर द्वारा परिभाषित किसी भी सीमा में नहीं गिरा।

यहाँ स्क्रिप्ट का हिस्सा है:

 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 चर की घोषणा को लूप में स्थानांतरित करना और इसे लूप से बाहर टिप्पणी करना आवश्यक है (जैसा कि ऊपर दिए गए कोड में दर्शाया गया है)। बदलाव करने के बाद, स्क्रिप्ट उम्मीद के मुताबिक आधी रात के बाद कई बदलाव करेगी। स्क्रिप्ट सुधार के बिना विकल्प हमेशा सभी वर्गों में टाइम पैरामीटर लिखना है ताकि आधी रात के बाद कोई संक्रमण न हो।

पुनश्च

मैंने इसी तरह की समस्या के बारे में जानकारी के लिए इंटरनेट पर खोज की, लेकिन कुछ भी नहीं मिला। आश्चर्यजनक रूप से, आकार देने के लिए इस लिपि के व्यापक उपयोग के बावजूद किसी को भी इस समस्या का सामना नहीं करना पड़ा है। हालांकि, शायद मैं बुरी तरह से देख रहा था ...