फॉलिंग डाउन द रॅबिट होल: वन वार्निश रीलोड अयशस्वीची कहाणी - भाग १

भूतिनूशंका, मागील 20 मिनिटांपासून बटनांवर हातोडा मारत आहे जणू काही त्याचे आयुष्य त्यावर अवलंबून आहे, त्याच्या डोळ्यात अर्ध-जंगली नजरेने आणि धूर्त हसत माझ्याकडे वळला - "यार, मला वाटते मला ते समजले आहे."

“इकडे पाहा,” स्क्रीनवरील एका चिन्हाकडे निर्देश करून तो म्हणतो, “मी माझी लाल टोपी घालतो की मी तुम्हाला नुकतेच जे पाठवले आहे ते येथे जोडले तर,” कोडच्या दुसर्‍या विभागाकडे निर्देश करून, “त्रुटी यापुढे राहणार नाही. प्रदर्शित केले जाईल."

थोडे गोंधळलेले आणि थकलेलो, आम्ही काही काळ काम करत असलेल्या sed एक्स्प्रेशनमध्ये सुधारणा करतो, फाईल सेव्ह करतो आणि रन करतो systemctl varnish reload. त्रुटी संदेश गायब झाला आहे...

"मी उमेदवारासोबत ईमेल्सची देवाणघेवाण केली," माझा सहकारी पुढे म्हणाला, त्याचे हसणे आनंदाच्या अस्सल हास्यात वाढले, "अचानक माझ्या लक्षात आले की हीच समस्या आहे!"

हे सर्व कसे सुरू झाले

लेखात bash, awk, sed आणि systemd कसे कार्य करतात हे समजते. वार्निशचे ज्ञान प्राधान्य दिले जाते, परंतु आवश्यक नाही.
स्निपेट्समधील टाइमस्टॅम्प बदलले आहेत.
सह लिहिले भूतिनूशंका.
हा मजकूर दोन आठवड्यांपूर्वी इंग्रजीत प्रकाशित झालेल्या मूळचा अनुवाद आहे; भाषांतर boikoden.

आणखी एका उबदार शरद ऋतूतील सकाळी पॅनोरामिक खिडक्यांमधून सूर्य चमकतो, ताजे तयार केलेले कॅफीन युक्त पेय एक कप कीबोर्डपासून दूर होते, तुमच्या हेडफोन्समधील ध्वनी आवाजांची तुमची आवडती सिम्फनी, यांत्रिक कीबोर्डच्या गजबजून बाहेर पडते आणि पहिली एंट्री. कानबन बोर्डवरील बॅकलॉग तिकिटांच्या यादीमध्ये “इन्व्हेस्टिगेट वार्निशरलोड” sh: echo: I/O error in staging” (स्टेजिंगमध्ये “varnishreload sh: echo: I/O error” ची चौकशी करा) या भयंकर शीर्षकासह खेळकरपणे चमकते. जेव्हा वार्निशचा विचार केला जातो, तेव्हा त्रुटींसाठी जागा आहे आणि असू शकत नाही, जरी या प्रकरणात कोणत्याही समस्या उद्भवल्या नाहीत.

जे परिचित नाहीत त्यांच्यासाठी varnishreload, ही एक साधी शेल स्क्रिप्ट आहे जी कॉन्फिगरेशन रीलोड करण्यासाठी वापरली जाते वार्निश - VCL देखील म्हणतात.

तिकिटाच्या शीर्षकानुसार, स्टेजवरील एका सर्व्हरवर त्रुटी आली आणि स्टेजवरील वार्निश राउटिंग योग्यरित्या कार्य करत असल्याची मला खात्री असल्याने, मी गृहीत धरले की ही एक छोटी त्रुटी असेल. तर, फक्त एक संदेश जो आधीच बंद केलेल्या आउटपुट प्रवाहात संपला. मी तिकीट स्वतःसाठी घेतो, ३० मिनिटांपेक्षा कमी वेळात मी ते तयार असल्याचे पूर्ण आत्मविश्वासाने घेतो, आणखी एक कचरा साफ करण्यासाठी स्वतःच्या पाठीवर थाप देतो आणि आणखी महत्त्वाच्या गोष्टींकडे परत जातो.

200 किमी/तास वेगाने भिंतीवर आदळणे

फाइल उघडत आहे varnishreload, डेबियन स्ट्रेच चालवणाऱ्या एका सर्व्हरवर, मला 200 ओळींपेक्षा कमी लांबीची शेल स्क्रिप्ट दिसली.

स्क्रिप्टचा अभ्यास केल्यावर, मला असे काहीही लक्षात आले नाही ज्यामुळे ते थेट टर्मिनलवरून अनेक वेळा चालवताना समस्या उद्भवू शकतात.

शेवटी, हा एक टप्पा आहे, जरी तो तुटला तरी कोणीही तक्रार करणार नाही, बरं... जास्त नाही. मी स्क्रिप्ट चालवतो आणि टर्मिनलवर काय लिहिले जाईल ते पाहतो, परंतु त्रुटी यापुढे दिसत नाहीत.

मी कोणत्याही अतिरिक्त प्रयत्नाशिवाय त्रुटीचे पुनरुत्पादन करू शकत नाही याची खात्री करण्यासाठी आणखी काही धावा केल्या आणि मी ही स्क्रिप्ट कशी बदलायची आणि तरीही त्रुटी कशी टाकायची हे शोधण्यास सुरवात करत आहे.

स्क्रिप्ट STDOUT ओव्हरराइड करू शकते (वापरून > &-)? किंवा STDERR? यापैकी काहीही शेवटी कामी आले नाही.

वरवर पाहता systemd कसे तरी स्टार्टअप वातावरण सुधारते, पण कसे, आणि का?
मी vim उघडतो आणि संपादित करतो varnishreload, जोडून set -x स्क्रिप्टचे डीबग आउटपुट काही प्रकाश टाकेल या आशेने शेबांगच्या खाली.

फाइल दुरुस्त केली आहे, म्हणून मी वार्निश रीलोड केले आणि पाहतो की बदलाने सर्वकाही पूर्णपणे तोडले आहे... एक्झॉस्ट हा एक संपूर्ण गोंधळ आहे, ज्यामध्ये C-सारखे कोड आहेत. ते कुठे सुरू होते हे शोधण्यासाठी टर्मिनलमध्ये स्क्रोल करणे देखील पुरेसे नाही. मी पूर्णपणे गोंधळलो आहे. डिबगिंग मोड स्क्रिप्टमध्ये लॉन्च केलेल्या प्रोग्रामच्या ऑपरेशनवर परिणाम करू शकतो? नाही, हा मूर्खपणा आहे. शेल मध्ये बग? अनेक संभाव्य परिस्थिती माझ्या डोक्यात झुरळांप्रमाणे वेगवेगळ्या दिशेने धावत आहेत. कॅफिनयुक्त पेयाचा कप ताबडतोब रिकामा केला जातो, साठा पुन्हा भरण्यासाठी स्वयंपाकघरात एक द्रुत सहल आणि... आम्ही निघतो. मी स्क्रिप्ट उघडतो आणि शेबांग जवळून पाहतो: #!/bin/sh.

/bin/sh - ही बॅश करण्यासाठी फक्त एक सिमलिंक आहे, म्हणून स्क्रिप्टचा अर्थ POSIX-सुसंगत मोडमध्ये केला जातो, बरोबर? तसे नाही! डेबियनवरील डीफॉल्ट शेल डॅश आहे आणि ते असे दिसते. संदर्भ देते /bin/sh.

# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 24  2017 /bin/sh -> dash

एक चाचणी म्हणून, मी shebang बदलले #!/bin/bash, हटवले set -x आणि पुन्हा प्रयत्न केला. शेवटी, वार्निशच्या त्यानंतरच्या रीबूटवर, आउटपुटमध्ये एक सहन करण्यायोग्य त्रुटी दिसून आली:

Jan 01 12:00:00 hostname varnishreload[32604]: /usr/sbin/varnishreload: line 124: echo: write error: Broken pipe
Jan 01 12:00:00 hostname varnishreload[32604]: VCL 'reload_20190101_120000_32604' compiled

ओळ 124, येथे आहे!

114 find_vcl_file() {
115         VCL_SHOW=$(varnishadm vcl.show -v "$VCL_NAME" 2>&1) || :
116         VCL_FILE=$(
117                 echo "$VCL_SHOW" |
118                 awk '$1 == "//" && $2 == "VCL.SHOW" {print; exit}' | {
119                         # all this ceremony to handle blanks in FILE
120                         read -r DELIM VCL_SHOW INDEX SIZE FILE
121                         echo "$FILE"
122                 }
123         ) || :
124
125         if [ -z "$VCL_FILE" ]
126         then
127                 echo "$VCL_SHOW" >&2
128                 fail "failed to get the VCL file name"
129         fi
130
131         echo "$VCL_FILE"
132 }

परंतु हे दिसून आले की, 124 ओळ अगदी रिकामी आहे आणि त्यात रस नाही. मी फक्त असे गृहीत धरू शकतो की त्रुटी 116 वरून सुरू होणाऱ्या मल्टीलाइन स्ट्रिंगचा भाग म्हणून आली आहे.
व्हेरिएबलला शेवटी काय लिहिले जाते? VCL_FILE वरील उप-शेल कार्यान्वित केल्यामुळे?

सुरुवातीला, ते व्हेरिएबलची सामग्री पाठवते VLC_SHOW, पाईपद्वारे कमांडचे अनुसरण करून, 115 ओळीवर तयार केले. आणि मग तिथे काय होते?

प्रथम, ते तेथे वापरले जाते varnishadm, जो वार्निश इंस्टॉलेशन पॅकेजचा भाग आहे, रीस्टार्ट न करता वार्निश सेट करण्यासाठी.

उप-संघ vcl.show -v मध्ये निर्दिष्ट केलेले संपूर्ण VCL कॉन्फिगरेशन आउटपुट करण्यासाठी वापरले जाते ${VCL_NAME}, STDOUT ला.

वर्तमान सक्रिय व्हीसीएल कॉन्फिगरेशन प्रदर्शित करण्यासाठी, तसेच वार्निश राउटिंग कॉन्फिगरेशनच्या अनेक मागील आवृत्त्या ज्या अजूनही मेमरीमध्ये आहेत, तुम्ही कमांड वापरू शकता varnishadm vcl.list, ज्याचे आउटपुट खालील प्रमाणे असेल:

discarded   cold/busy       1 reload_20190101_120000_11903
discarded   cold/busy       2 reload_20190101_120000_12068
discarded   cold/busy       16 reload_20190101_120000_12259
discarded   cold/busy       16 reload_20190101_120000_12299
discarded   cold/busy       28 reload_20190101_120000_12357
active      auto/warm       32 reload_20190101_120000_12397
available   auto/warm       0 reload_20190101_120000_12587

परिवर्तनीय मूल्य ${VCL_NAME} स्क्रिप्टच्या दुसर्या भागात स्थापित केले आहे varnishreload सध्या सक्रिय VCL च्या नावावर, जर एखादे असेल. या प्रकरणात ते "reload_20190101_120000_12397" असेल.

उत्तम, परिवर्तनशील ${VCL_SHOW} वार्निशसाठी संपूर्ण कॉन्फिगरेशन समाविष्ट आहे, आत्तासाठी स्पष्ट. आता मला शेवटी समजले की डॅश आउटपुट का आहे set -x इतके तुटलेले असल्याचे दिसून आले - त्यात परिणामी कॉन्फिगरेशनची सामग्री समाविष्ट आहे.

हे समजून घेणे महत्त्वाचे आहे की संपूर्ण VCL कॉन्फिगरेशन अनेकदा अनेक फाइल्समधून एकत्र केले जाऊ शकते. सी-शैलीतील टिप्पण्या इतरांमध्ये कोठे समाविष्ट केल्या गेल्या आहेत हे ओळखण्यासाठी वापरल्या जातात आणि कोड स्निपेटची खालील ओळ त्याबद्दल आहे.
समाविष्ट केलेल्या फायलींचे वर्णन करणार्‍या टिप्पण्यांसाठी वाक्यरचना खालील स्वरूपात आहे:

// VCL.SHOW <NUM> <NUM> <FILENAME>

या संदर्भात क्रमांक महत्त्वाचे नाहीत, आम्हाला फाइल नावात रस आहे.

116 ओळीपासून सुरू होणाऱ्या कमांड्सच्या दलदलीत शेवटी काय होते?
चला ते बाहेर काढूया.
संघात चार भाग आहेत:

1. साधे echo, जे व्हेरिएबलचे मूल्य मुद्रित करते ${VCL_SHOW}

   echo "$VCL_SHOW"

2. awk, जी एक ओळ (रेकॉर्ड) शोधते जिथे मजकूर तोडल्यानंतर पहिले फील्ड “//” आहे आणि दुसरे “VCL.SHOW” आहे.
   Awk या पॅटर्नशी जुळणारी पहिली ओळ लिहेल आणि नंतर लगेच प्रक्रिया थांबवेल.

   awk '$1 == "//" && $2 == "VCL.SHOW" {print; exit}'

3. कोडचा एक ब्लॉक जो फील्ड व्हॅल्यूज पाच व्हेरिएबल्समध्ये स्टोअर करतो, स्पेसद्वारे विभक्त करतो. पाचव्या FILE व्हेरिएबलला उर्वरित ओळ प्राप्त होते. शेवटी, शेवटचा इको व्हेरिएबलची सामग्री लिहितो ${FILE}.

   { read -r DELIM VCL_SHOW INDEX SIZE FILE; echo "$FILE" }

4. सर्व पायऱ्या 1 ते 3 सबशेलमध्ये बंद केल्यामुळे, मूल्य आउटपुट करत आहे $FILE व्हेरिएबलवर लिहिले जाईल VCL_FILE.

ओळी 119 वरील टिप्पणी सुचविते, व्हीसीएल त्यांच्या नावातील मोकळी जागा असलेल्या फायली संदर्भित करेल अशा प्रकरणांची विश्वसनीयरित्या हाताळणी करण्याचा हा एकमेव उद्देश आहे.

मी मूळ प्रक्रियेच्या तर्कावर टिप्पणी केली आहे ${VCL_FILE} आणि आदेश क्रम बदलण्याचा प्रयत्न केला, परंतु यामुळे काहीही झाले नाही. माझ्यासाठी सर्व काही ठीक आहे, परंतु जेव्हा मी सेवा सुरू केली तेव्हा त्यात एक त्रुटी आली.

असे दिसते की स्क्रिप्ट मॅन्युअली चालवताना त्रुटी केवळ पुनरुत्पादित होत नाही, तर अपेक्षित 30 मिनिटे आधीच सहा वेळा कालबाह्य झाली आहेत आणि त्याव्यतिरिक्त, इतर बाबी बाजूला सारून उच्च प्राधान्य कार्य दिसू लागले आहे. उरलेला आठवडा विविध कामांनी भरलेला होता आणि sed वरील अहवाल आणि उमेदवाराच्या मुलाखतीमुळे तो थोडासा कमी झाला होता. मध्ये त्रुटीसह समस्या varnishreload काळाच्या वाळूत अपरिवर्तनीयपणे हरवले होते.

तुमचा तथाकथित सेड-फू... खरं तर... कचरा आहे

पुढच्या आठवड्यात माझ्याकडे एक मोकळा दिवस होता, म्हणून मी हे तिकीट पुन्हा हाताळण्याचा निर्णय घेतला. मला आशा होती की माझ्या मेंदूत, काही पार्श्वभूमी प्रक्रिया या सर्व वेळेस या समस्येवर उपाय शोधत होती आणि यावेळी मला नक्की काय चालले आहे ते समजेल.

गेल्या वेळी फक्त कोड बदलल्याने मदत झाली नाही, मी फक्त 116 ओळीपासून पुन्हा लिहिण्याचा निर्णय घेतला. कोणत्याही परिस्थितीत, विद्यमान कोड मूर्ख होता. आणि ते वापरण्याची अजिबात गरज नाही read.

त्रुटी पुन्हा पहा:
sh: echo: broken pipe — या आदेशात दोन ठिकाणी प्रतिध्वनी दिसते, परंतु मला शंका आहे की पहिला बहुधा गुन्हेगार आहे (किंवा किमान एक साथीदार). Awk आत्मविश्वास देखील प्रेरित करत नाही. आणि जर ते खरोखरच असेल तर awk | {read; echo} डिझाइनमुळे या सर्व समस्या उद्भवतात, ते का बदलू नये? ही एक-लाइन कमांड awk ची सर्व वैशिष्ट्ये वापरत नाही आणि ही अतिरिक्त एक देखील read याव्यतिरिक्त

गेल्या आठवड्यापासून एक अहवाल होता sed, मला माझी नवीन आत्मसात केलेली कौशल्ये वापरून पहायची होती आणि सोपे बनवायचे होते echo | awk | { read; echo} अधिक समजण्यायोग्य मध्ये echo | sed. बग ओळखण्यासाठी हा नक्कीच सर्वोत्तम मार्ग नसला तरी, मला वाटले की मी किमान माझे sed-fu वापरून पहावे आणि कदाचित समस्येबद्दल काहीतरी नवीन शिकावे. वाटेत, मी माझ्या सहकाऱ्याला, सेड टॉकचे लेखक, मला अधिक कार्यक्षम sed स्क्रिप्ट तयार करण्यात मदत करण्यास सांगितले.

मी सामग्री टाकली varnishadm vcl.show -v "$VCL_NAME" फाइलवर, जेणेकरून मी सेवा रीबूटच्या कोणत्याही अडचणीशिवाय sed स्क्रिप्ट लिहिण्यावर लक्ष केंद्रित करू शकेन.

sed प्रक्रिया इनपुटमध्ये नेमके कसे शोधले जाऊ शकते याचे थोडक्यात वर्णन त्याचे GNU मॅन्युअल. sed स्त्रोतांमध्ये चिन्ह आहे n रेषा विभाजक म्हणून स्पष्टपणे निर्दिष्ट केले आहे.

अनेक पासांमध्ये आणि माझ्या सहकाऱ्याच्या शिफारशींनुसार, आम्ही एक sed स्क्रिप्ट लिहिली ज्याने संपूर्ण मूळ ओळ 116 प्रमाणेच परिणाम दिला.

खाली इनपुट डेटासह नमुना फाइल आहे:

> cat vcl-example.vcl
Text
// VCL.SHOW 0 1578 file with 3 spaces.vcl
More text
// VCL.SHOW 0 1578 file.vcl
Even more text
// VCL.SHOW 0 1578 file with TWOspaces.vcl
Final text

वरील वर्णनावरून हे कदाचित स्पष्ट होणार नाही, परंतु आम्हाला फक्त पहिल्या टिप्पणीमध्ये रस आहे // VCL.SHOW, आणि इनपुट डेटामध्ये त्यापैकी अनेक असू शकतात. त्यामुळे पहिल्या सामन्यानंतर मूळ ओक संपतो.

# шаг первый, вывести только строки с комментариями
# используя возможности sed, определяется символ-разделитель с помощью конструкции '#' вместо обычно используемого '/', за счёт этого не придётся экранировать косые в искомом комментарии
# определяется регулярное выражение “// VCL.SHOW”, для поиска строк с определенным шаблоном
# флаг -n позаботится о том, чтобы sed не выводил все входные данные, как он это делает по умолчанию (см. ссылку выше)
# -E позволяет использовать расширенные регулярные выражения
> cat vcl-processor-1.sed
#// VCL.SHOW#p
> sed -En -f vcl-processor-1.sed vcl-example.vcl
// VCL.SHOW 0 1578 file with 3 spaces.vcl
// VCL.SHOW 0 1578 file.vcl
// VCL.SHOW 0 1578 file with TWOspaces.vcl

# шаг второй, вывести только имя файла
# используя команду “substitute”, с группами внутри регулярных выражений, отображается только нужная группa
# и это делается только для совпадений, ранее описанного поиска
> cat vcl-processor-2.sed
#// VCL.SHOW# {
    s#.* [0-9]+ [0-9]+ (.*)$#1#
    p
}
> sed -En -f vcl-processor-2.sed vcl-example.vcl
file with 3 spaces.vcl
file.vcl
file with TWOspaces.vcl

# шаг третий, получить только первый из результатов
# как и в случае с awk, добавляется немедленное завершения после печати первого найденного совпадения
> cat vcl-processor-3.sed
#// VCL.SHOW# {
    s#.* [0-9]+ [0-9]+ (.*)$#1#
    p
    q
}
> sed -En -f vcl-processor-3.sed vcl-example.vcl
file with 3 spaces.vcl

# шаг четвертый, схлопнуть всё в однострочник, используя двоеточия для разделения команд
> sed -En -e '#// VCL.SHOW#{s#.* [0-9]+ [0-9]+ (.*)$#1#p;q;}' vcl-example.vcl
file with 3 spaces.vcl

तर, varnishreload स्क्रिप्टची सामग्री यासारखे काहीतरी दिसेल:

VCL_FILE="$(echo "$VCL_SHOW" | sed -En '#// VCL.SHOW#{s#.*[0-9]+ [0-9]+ (.*)$#1#p;q;};')"

वरील तर्क थोडक्यात खालीलप्रमाणे व्यक्त करता येईल.
जर स्ट्रिंग नियमित अभिव्यक्तीशी जुळत असेल // VCL.SHOW, नंतर या ओळीतील दोन्ही संख्यांचा समावेश असलेला मजकूर लोभसपणे खाऊन टाका आणि या ऑपरेशननंतर उरलेल्या सर्व गोष्टी जतन करा. संग्रहित मूल्य उत्सर्जित करा आणि प्रोग्राम समाप्त करा.

साधे, नाही का?

आम्ही sed स्क्रिप्ट आणि सर्व मूळ कोड बदलल्याच्या वस्तुस्थितीबद्दल आनंदी होतो. माझ्या सर्व चाचण्यांनी इच्छित परिणाम दिले, म्हणून मी सर्व्हरवरील "वार्निशरलोड" बदलले आणि ते पुन्हा चालवले systemctl reload varnish. वाईट चूक echo: write error: Broken pipe आमच्या चेहऱ्यावर पुन्हा हसले. डोळे मिचकावणारा कर्सर टर्मिनलच्या गडद रिकामपणात नवीन कमांड एंटर होण्याची वाट पाहत होता...

स्त्रोत: www.habr.com