systemctl ამბობს, რომ systemd PID 1 არ არის: აბა, რა შემდეგ?

თუ systemctl start openvpn-client@office გაშვებისას მიიღებთ შეტყობინებას, რომ სისტემა systemd-ით არ ჩატვირთულა, ეს სერვისის ჩავარდნას ჰგავს. ეს საერთოდ არ არის სერვისის ჩავარდნა: systemctl, რომელიც გამოიძახეთ, ვერ პოულობს მუშა მმართველს სასაუბროდ, ამიტომ OpenVPN-ის შესახებ არაფერი შემოწმებულა. sudo მმართველს არ ქმნის, და unit ფაილის დაყენებაც მას არ ქმნის. ბრძანება და მანქანა ორი სხვადასხვა სამყაროდან მოდის, და შეცდომა ერთადერთი ადგილია, სადაც ეს გამოვლინდა.

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

შეცდომა გარემოს ასახელებს, არა OpenVPN-ს

systemctl კლიენტია, არა მმართველი. ის სისტემის მმართველს socket-ის მეშვეობით უკავშირდება, და როცა მეორე ბოლოში მმართველი არ არის, ბეჭდავს იმ შეტყობინებას, რომელსაც ხალხი ფორუმებზე აკრავს. ps -p 1 -o pid=,comm= აჩვენებს, რა მუშაობს სინამდვილეში PID 1-ად, და პასუხი ხშირად shell-ია, init-ის გარსი ან თავად კონტეინერის შესვლის წერტილი. ასეთ სიტუაციაში unit ფაილი შეიძლება სრულიად ვალიდური იყოს და მაინც არასდროს წაიკითხოს. ბრძანების root-ად გამეორება მხოლოდ კლიენტის სერთიფიკატებს ცვლის.

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

WSL: systemd-ის ჩართვა კონფიგურაციის ცვლილებაა

WSL-მა systemd-ის მხარდაჭერა მოგვიანო გამოშვებებში მიიღო, მაგრამ ფუნქცია თითოეული დისტრიბუციისთვის ცალკე ირთვება და მხოლოდ იქ, სადაც დაყენებული WSL-ის ვერსია მხარს უჭერს მას. wsl --version Windows-ის მხარეს გიჩვენებთ, რა გაქვთ, და დისტრიბუციის /etc/wsl.conf ფაილი შეიცავს [boot] სექციას systemd=true-ით. დაარედაქტირეთ ეს ფაილი უკვე არსებული სექციების წაშლის გარეშე, შემდეგ გადატვირთეთ WSL-ის ეგზემპლარი, რათა ცვლილება ძალაში შევიდეს. wsl --shutdown აჩერებს ყველა მუშა დისტრიბუციას, ამიტომ ჯერ შეინახეთ სამუშაო.

ხელახლა გახსნის შემდეგ, სანამ OpenVPN-ის unit-ს შეეხებით, დაადასტურეთ მმართველი: ps -p 1 -o comm= უნდა აჩვენებდეს systemd-ს. systemd-ის ჩართვა არ იძლევა პროფილს, სერთიფიკატებს ან ეგზემპლარის სახელს, ამიტომ შემდეგი შეცდომა ერთ-ერთ მათგანს შეეხება და არა PID 1-ს.

კონტეინერები თავიანთ შესვლის წერტილს უშვებენ, და არა unit-ებს

ჩვეულებრივი კონტეინერი უშვებს იმას, რასაც მისი შესვლის წერტილი ან ბრძანება განსაზღვრავს, და ის systemd-ით ჩატვირთული მანქანა არ არის, რა პაკეტებიც არ უნდა დააყენოთ. გამოსახულებაში systemctl-ის დამატება მოგცემთ კლიენტს, რომელსაც დასაკავშირებელი არაფერი აქვს. Community OpenVPN-ისთვის მხარდაჭერილი ნიმუში ჩვეულებრივ წინა პლანზე მომუშავე პროცესია, openvpn --config /path/to/client.conf, რომელსაც შესვლის წერტილი უშვებს და გარედან ზედამხედველობს. ის მფლობელი უმკლავდება გაშვებას, სიგნალებს და გამორთვას, და სწორედ ის უნდა იყოს ერთადერთი, ვინც გვირაბს მართავს.

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

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

წაიკითხეთ შემდეგი შეცდომა, როცა მმართველი არსებობს

როგორც კი ნამდვილი მმართველი გაუშვებს სერვისს, სასარგებლო შეცდომები იწყება. მოწყობილობის ნებართვის ჩავარდნა, კონფიგურაციის ანალიზის შეცდომა, დაკარგული სერთიფიკატები და მიუწვდომელი პარტნიორი ოთხი სხვადასხვა პრობლემაა, რომლებიც PID 1-ის შეტყობინებას არასდროს გამოუცდია. წაიკითხეთ ისინი იმ რიგით, რომლითაც unit-მა შექმნა, გამოყენებით journalctl -u openvpn-client@office -n 50 systemd ჰოსტზე, ან კლიენტის წინა პლანზე გაშვებით იქ, სადაც მმართველი არ არის. წინა პლანზე გაშვება ასევე ყველაზე სწრაფი გზაა იმის დასადასტურებლად, რომ თავად პროფილი მუშაობს.

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