კურდღლის ხვრელში დაცემა: ლაქის გადატვირთვის ერთი შეცდომის ისტორია - ნაწილი 1

ღოსტინუშანკაღილაკებს ბოლო 20 წუთის განმავლობაში ურტყამდა, თითქოს მისი ცხოვრება მასზე იყო დამოკიდებული, თვალებში ნახევრად ველური მზერით და ეშმაკური ღიმილით მიბრუნდა - „მეგობარო, მგონი მივხვდი“.

”აი აქ,” ამბობს ის და მიუთითებს ეკრანზე ერთ-ერთ სიმბოლოზე, ”მე დავდებ ჩემს წითელ ქუდს, რომ თუ აქ დავამატებთ იმას, რაც ახლა გამოგიგზავნეთ”, მიუთითებს კოდის სხვა განყოფილებაზე, ”შეცდომა აღარ იქნება. ნაჩვენები იქნება“.

ცოტა საგონებელში ჩავარდნილი და დაღლილი, ვაცვლი sed გამონათქვამს, რომელზეც ცოტა ხანი ვმუშაობდით, შეინახე ფაილი და გაუშვით systemctl varnish reload. შეცდომის შეტყობინება გაქრა...

”ელ.წერილი, რომელიც გავცვალე კანდიდატთან,” განაგრძო ჩემმა კოლეგამ, როდესაც მისი ღიმილი გადაიზარდა სიხარულის გულწრფელ ღიმილში, ”უცებ მივხვდი, რომ ეს არის ზუსტად იგივე პრობლემა!”

როგორ დაიწყო ეს ყველაფერი

სტატია ითვალისწინებს იმის გაგებას, თუ როგორ მუშაობს bash, awk, sed და systemd. ლაქის ცოდნა სასურველია, მაგრამ არა სავალდებულო.
დროითი ანაბეჭდები სნიპეტებში შეიცვალა.
დაწერილი ერთად ღოსტინუშანკა.
ეს ტექსტი არის ორი კვირის წინ ინგლისურ ენაზე გამოცემული ორიგინალის თარგმანი; თარგმანი ბოიკოდენი.

მზე ანათებს პანორამული ფანჯრებიდან შემოდგომის კიდევ ერთ თბილ დილას, ახლად მომზადებული კოფეინით მდიდარი სასმელი კლავიატურას მოშორებით ეყრდნობა, ყურსასმენებში ჟღერს თქვენი საყვარელი ბგერების სიმფონია, ახშობს მექანიკური კლავიატურების შრიალს და პირველი ჩანაწერი ჩამორჩენილი ბილეთების სიაში კანბანის დაფაზე მხიარულად ანათებს საბედისწერო სათაურით „Investigate varnishreload“ sh: echo: I/O error in staging“ (გამოიკვლიეთ „varnishreload sh: echo: I/O შეცდომა“ დადგმაში). რაც შეეხება ლაქს, შეცდომებისთვის არის და არ შეიძლება იყოს ადგილი, მაშინაც კი, თუ ისინი არ წარმოქმნიან რაიმე პრობლემას, როგორც ამ შემთხვევაში.

მათთვის, ვინც არ იცნობს ლაქის დატვირთვა, ეს არის მარტივი ჭურვის სკრიპტი, რომელიც გამოიყენება კონფიგურაციის გადატვირთვისთვის ლაქი - ასევე მოუწოდა VCL.

როგორც ბილეთის სათაურიდან ჩანს, შეცდომა მოხდა სცენაზე მდებარე ერთ-ერთ სერვერზე და რადგან დარწმუნებული ვიყავი, რომ სცენაზე ლაქის მარშრუტი გამართულად მუშაობდა, ჩავთვალე, რომ ეს იქნებოდა უმნიშვნელო შეცდომა. ასე რომ, მხოლოდ შეტყობინება, რომელიც დასრულდა უკვე დახურულ გამომავალ ნაკადში. ბილეთს ვიღებ ჩემთვის, სრული დარწმუნებით, რომ 30 წუთზე ნაკლებ დროში მოვნიშნავ მზადყოფნას, ზურგზე ვეფერები, რომ დაფა კიდევ ერთი ნაგვისგან გავწმინდო და უფრო მნიშვნელოვან საკითხებს ვუბრუნდები.

კედელს დაეჯახა 200 კმ/სთ სიჩქარით

ფაილის გახსნა varnishreload, ერთ-ერთ სერვერზე, რომელიც მუშაობს Debian Stretch-ზე, ვნახე shell სკრიპტი 200 სტრიქონზე ნაკლები სიგრძით.

სკრიპტის გავლის შემდეგ, მე ვერ შევამჩნიე ისეთი რამ, რამაც შეიძლება გამოიწვიოს პრობლემები, რამდენჯერმე პირდაპირ ტერმინალიდან გაშვებისას.

ეს ხომ სცენაა, რომც გატყდეს, არავინ წუწუნებს, კარგი... არც ისე ბევრი. სკრიპტს ვუშვებ და ვნახავ რა ჩაიწერება ტერმინალში, მაგრამ შეცდომები აღარ ჩანს.

კიდევ რამდენიმე გაშვება, რათა დავრწმუნდე, რომ შეცდომის რეპროდუცირება არ შემიძლია დამატებითი ძალისხმევის გარეშე და ვიწყებ იმის გარკვევას, თუ როგორ შევცვალო ეს სკრიპტი და ის მაინც გამოვიდეს შეცდომაში.

შეუძლია თუ არა სკრიპტს გადალახოს STDOUT (გამოყენებით > &-)? ან STDERR? ბოლოს არცერთმა არ იმუშავა.

როგორც ჩანს, systemd რატომღაც ცვლის სტარტაპ გარემოს, მაგრამ როგორ და რატომ?
ვხსნი vim-ს და ვასწორებ varnishreload, დასძინა set -x ზუსტად shebang-ის ქვეშ, იმ იმედით, რომ სკრიპტის გამართვის შედეგი გარკვეულ შუქს მოჰფენს.

ფაილი გასწორებულია, ასე რომ გადავტვირთავ ლაქს და ვხედავ, რომ ცვლილებამ მთლიანად დაარღვია ყველაფერი... გამონაბოლქვი არის სრული არეულობა, რომელშიც არის ტონა C-ის მსგავსი კოდი. ტერმინალში გადახვევაც კი არ არის საკმარისი იმისთვის, რომ იპოვოთ ის, საიდან იწყება. სრულიად დაბნეული ვარ. შეუძლია თუ არა გამართვის რეჟიმს გავლენა მოახდინოს სკრიპტში გაშვებული პროგრამების მუშაობაზე? არა, სისულელეა. ხარვეზი ჭურვიში? რამდენიმე შესაძლო სცენარი ტარაკნებივით მიტრიალებს თავში სხვადასხვა მიმართულებით. კოფეინის შემცველი სასმელის ჭიქა მყისიერად იცლება, სწრაფი გამგზავრება სამზარეულოში მარაგის შესავსებად და... წავედით. მე ვხსნი სკრიპტს და უფრო ახლოს ვათვალიერებ შებანგს: #!/bin/sh.

/bin/sh - ეს მხოლოდ ბაშის სიმბოლური ბმულია, ასე რომ, სკრიპტის ინტერპრეტაცია ხდება POSIX-თან თავსებად რეჟიმში, არა? Ასე არა! Debian-ზე ნაგულისხმევი გარსი არის dash და ზუსტად ასე გამოიყურება. ეხება /bin/sh.

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

ტესტად შევცვალე შებანგი #!/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}, STDAUT-მდე.

მიმდინარე აქტიური VCL კონფიგურაციის, ისევე როგორც ლაქის მარშრუტის კონფიგურაციის რამდენიმე წინა ვერსიის საჩვენებლად, რომლებიც ჯერ კიდევ მეხსიერებაშია, შეგიძლიათ გამოიყენოთ ბრძანება 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-ის სრული კონფიგურაცია ხშირად შეიძლება რამდენიმე ფაილიდან იყოს მოპირკეთებული. C სტილის კომენტარები გამოიყენება იმის დასადგენად, თუ სად არის შეტანილი გარკვეული კონფიგურაციის ფაილები სხვებში და სწორედ ეს არის კოდის ფრაგმენტის შემდეგი ხაზი.
ჩართული ფაილების აღწერის კომენტარების სინტაქსი შემდეგი ფორმატით არის:

// 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 მიუთითებს ფაილებს შორის ინტერვალით მათ სახელებში.

მე დავაკომენტარე ორიგინალური დამუშავების ლოგიკა ${VCL_FILE} და ცდილობდა ბრძანების თანმიმდევრობის შეცვლას, მაგრამ ამან ვერაფერი გამოიწვია. ყველაფერი კარგად მუშაობდა, მაგრამ როცა სერვისი დავიწყე, შეცდომა დაუშვა.

როგორც ჩანს, სკრიპტის ხელით გაშვებისას შეცდომა უბრალოდ არ იწარმოება, მაშინ როცა სავარაუდო 30 წუთი უკვე ექვსჯერ ამოიწურა და, გარდა ამისა, გაჩნდა უფრო პრიორიტეტული დავალება, რომელიც სხვა საკითხებს განზე აყენებს. კვირის დანარჩენი პერიოდი სავსე იყო სხვადასხვა ამოცანებით და მხოლოდ ოდნავ განზავებული იყო სედზე მოხსენებით და კანდიდატთან გასაუბრებით. პრობლემა შეცდომით varnishreload შეუქცევად დაიკარგა დროის ქვიშაში.

შენი ეგრეთწოდებული სედ-ფუ... სინამდვილეში... ნაგავია

მომდევნო კვირას ერთი საკმაოდ თავისუფალი დღე მქონდა, ამიტომ გადავწყვიტე ამ ბილეთის ხელახლა დაძლევა. იმედი მქონდა, რომ ჩემს ტვინში რაღაც ფონური პროცესი მთელი ამ ხნის განმავლობაში ეძებდა ამ პრობლემის გადაწყვეტას და ამჯერად აუცილებლად გავიგებდი რა ხდებოდა.

ვინაიდან კოდის უბრალოდ შეცვლა არ დამეხმარა ბოლო ჯერზე, მე უბრალოდ გადავწყვიტე მისი გადაწერა 116-ე სტრიქონიდან დაწყებული. ყოველ შემთხვევაში, არსებული კოდი სულელური იყო. და აბსოლუტურად არ არის საჭირო მისი გამოყენება read.

კიდევ ერთხელ ვუყურებ შეცდომას:
sh: echo: broken pipe - ამ ბრძანებაში ექო ორ ადგილას ჩნდება, მაგრამ მე ეჭვი მაქვს, რომ პირველი უფრო სავარაუდო დამნაშავეა (ან თუნდაც თანამონაწილე). Awk არც ნდობას შთააგონებს. და თუ მართლა ასეა awk | {read; echo} დიზაინი იწვევს ყველა ამ პრობლემას, რატომ არ უნდა შეცვალოთ იგი? ეს ერთსტრიქონიანი ბრძანება არ იყენებს awk-ის ყველა მახასიათებელს და თუნდაც ამ დამატებით read გარდა ამისა.

გასულ კვირას იყო მოხსენება sed, მინდოდა გამომეცადა ახლად შეძენილი უნარები და გამემარტივებინა echo | awk | { read; echo} უფრო გასაგებად echo | sed. მიუხედავად იმისა, რომ ეს ნამდვილად არ არის საუკეთესო მიდგომა ხარვეზის იდენტიფიცირებისთვის, მე ვიფიქრე, რომ სულ ცოტა ჩემი sed-fu გამომეცადა და იქნებ რაიმე ახალი ვისწავლო პრობლემის შესახებ. გზაში ჩემს კოლეგას, სედ განხილვის ავტორს ვთხოვე, დამეხმარა უფრო ეფექტური სედ სცენარის შემუშავებაში.

შიგთავსი ჩამოვყარე varnishadm vcl.show -v "$VCL_NAME" ფაილზე, ასე რომ მე შემეძლო ფოკუსირება sed სკრიპტის დაწერაზე სერვისის გადატვირთვის გარეშე.

მოკლე აღწერა იმის შესახებ, თუ როგორ ამუშავებს sed შეყვანას, შეგიძლიათ ნახოთ მისი GNU სახელმძღვანელო. სედ წყაროებში სიმბოლო 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 სკრიპტით და იმით, რომ მან შეცვალა ყველა ორიგინალური კოდი. ჩემმა ყველა ტესტმა სასურველ შედეგს აძლევდა, ამიტომ შევცვალე სერვერზე „varnishreload“ და ისევ გავუშვი. systemctl reload varnish. ცუდი შეცდომა echo: write error: Broken pipe ისევ ჩაგვეცინა სახეებში. თვალისმომჭრელი კურსორი ელოდა ტერმინალის ბნელ სიცარიელეში შეყვანის ახალ ბრძანებას...

წყარო: www.habr.com