VPN კლიენტის segfault Pi-ზე? ჯერ პროცესი დააფიქსირეთ

კლიენტს რთავთ, ტერმინალი ბეჭდავს Segmentation fault (core dumped)-ს და მომდევნო საათი ბარათის ხელახლა ჩაწერას მიდის. ეს შეტყობინება აღწერს, როგორ მოკვდა ერთი პროცესი ერთ მომენტში. ის არ ამბობს, რომ დაფა დაზიანებულია, და არც კვებას, საცავს ან გამოსახულებას ათავისუფლებს ეჭვისგან.

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

დაიწყეთ shell-ის დაბეჭდილი ხაზიდან

თქვენი ბრძანების სახელი ხშირად გარსი ან გამშვებია, რომელიც სხვა ბინარულ ფაილს უშვებს, ამიტომ დაადასტურეთ, რომელი შესრულებადი ფაილი შეწყვიტა kernel-მა სინამდვილეში. ჩაწერეთ სრული ბილიკი, პაკეტისა და აპლიკაციის ვერსია, არქიტექტურა, OS-ისა და kernel-ის გამოშვება, ანგარიში, რომელმაც გაუშვა, და ზუსტი დრო. VPN-ის სახელის მქონე shell-ის ბრძანებას ადვილად შეუძლია დამხმარე პროცესის გაშვება, და ჩანაწერი სწორედ ამ დამხმარეს დაასახელებს. გასულ თვეში დაყენებული პაკეტის ვერსიის სტრიქონის კოპირება არაფერს ამბობს იმაზე, რაც გაშუქდა.

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

გაარკვიეთ, არსებობს თუ არა მეხსიერების გამოსახულება

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

systemd-ის შემგროვებლის მქონე სისტემაში მხარდაჭერილი ხედი შენახულ ჩანაწერს შესრულებად ფაილთან და დროსთან აკავშირებს. ჟურნალის ჩანაწერი და წაკითხვადი მეხსიერების გამოსახულება ორი სხვადასხვა არტეფაქტია: შენახვის პოლიტიკამ და ნებართვებმა შეიძლება ერთი დაგიტოვონ მეორის გარეშე. ჰკითხეთ დისტრიბუციას ან აპლიკაციის მომვლელს მათ მიერ მხარდაჭერილ დიაგნოსტიკურ სამუშაო პროცესზე, რადგან სხვა build-იდან ან სხვა ბიბლიოთეკების ნაკრებიდან მიღებული trace ჩვეულებრივ მათ დროს ხარჯავს.

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

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

მოეპყარით dump-ს როგორც საიდუმლოებების მატარებელ მასალას

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

თუ მომვლელი trace-ს ითხოვს, ჰკითხეთ, რომელი შესრულებადი ფაილიდან და რომელი ბიბლიოთეკებიდან სურს ის. backtrace, რომლის ჩარჩოები არ ემთხვევა მოხსენებულ build-ს, ძნელია ენდო და ადვილია არასწორად წაიკითხო.

შეამოწმეთ წარმომავლობა, სანამ რამეს შეცვლით

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

თუ დაუკავშირებელი პროგრამებიც წარუმატდება, ან სისტემა ჟურნალში წერს საცავის, კვების ან kernel-ის შეცდომებს, შეინახეთ ეს დაკვირვებები პლატფორმის გამოძიებისთვის. ისინი აფართოებენ არეალს; არ ამტკიცებენ, რომ ყოველი segfault გამოწვეულია გაფუჭებული RAM-ით ან დაზიანებული გამოსახულებით.

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