PID ფაილი არსებობს, გვირაბი არა: მუშაობდა OpenVPN ოდესმე?

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

დაიწყეთ სერვისით და არა ფაილით

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

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

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

შეამოწმეთ, ეკუთვნის თუ არა ეს იდენტიფიკატორი თქვენს ინსტანციას

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

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

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

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

რა აღუთქვა გამშვებმა ფაილთან დაკავშირებით

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

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

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

სუფთა გამორთვა შეწყვეტილი გასვლის წინააღმდეგ

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

შეადარეთ ფაილის დროის ნიშანი ბოლო ჩატვირთვას და ერთეულის ბოლო გაჩერებას.

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

შეწყვიტეთ ფაილის წაშლა ჩვევად

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

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

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