Berkas PID ada, tidak ada terowongan: pernahkah OpenVPN berjalan?
Berkas PID yang tertinggal tidak menjelaskan apakah terowongan aktif. Periksa layanan, waktu mulai proses, dan kontrak peluncur sebelum menghapusnya.
Ketika peluncur menolak menjalankan OpenVPN karena berkas PID sudah ada, bacaan alaminya adalah ada terowongan yang berjalan di suatu tempat. Bacaan itu cukup sering salah sehingga layak diperiksa sebelum apa pun dihapus. Berkas di direktori runtime adalah pembukuan, dan pembukuan bertahan dari crash, reboot, dan penghentian terputus yang tidak menyisakan proses. Dua pertanyaan menentukan kasus ini: apakah ada proses hidup, dan apakah proses itu milik instans ini.
Mulailah dari layanan, bukan dari berkas
Penolakan biasanya datang dari peluncur, bukan dari OpenVPN itu sendiri. Ia membaca sebuah jalur, menemukan sesuatu di sana, dan berhenti sebelum mengurai konfigurasi. Pertanyaan pertama karena itu tentang kontrak peluncur, bukan tentang terowongan.
Baca unit atau skrip yang mencetak pesan itu dan catat tiga hal: jalur yang diperiksa, jenis layanan yang dideklarasikan, dan apakah ia bertanggung jawab menulis berkas itu. Unit modern dapat memakai pengawasan sederhana atau notify dan tidak pernah menyentuh berkas PID, sedangkan skrip init lama dapat membuatnya sendiri. Menyalin pemeriksaan dari satu model ke model lain menghasilkan persis jenis penolakan ini. Cari tahu model mana yang dipakai sebelum menafsirkan apa pun.
Baru setelah itu pertanyaannya menjadi apakah suatu instans benar-benar berjalan.
Periksa apakah pengenal itu milik instans Anda
Angka di dalam berkas membuktikan bahwa sebuah angka ditulis. Itu tidak membuktikan ada proses dengan pengenal tersebut sekarang, dan jelas tidak membuktikan prosesnya milik Anda, karena pengenal dipakai ulang setelah reboot.
Bandingkan waktu mulai proses dengan stempel waktu berkas, berkas yang dapat dieksekusi dengan perintah unit, dan keanggotaan layanan dengan nama unit. Ketidakcocokan pada salah satu dari ketiganya berarti Anda sedang melihat pembukuan, bukan terowongan.
Pada host yang menjalankan kontainer atau beberapa ruang nama, pengenal bisa bermakna dalam satu tampilan dan tidak ada dalam tampilan lain. Tidak melihat suatu proses juga bukan bukti bahwa proses itu tidak ada, jika akun Anda tidak dapat memeriksanya. Periksa dari konteks yang dipakai peluncur sebelum menarik kesimpulan.
systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"Apa yang dijanjikan peluncur untuk dilakukan dengan berkas itu
PIDFile= memberi tahu pengelola layanan dari mana membaca pengenal proses utama. Pengelola tidak menulis berkas itu, tetapi ia menghapus berkas yang bertahan setelah penghentian, dan itulah sebabnya keluaran yang terputus dapat meninggalkan berkas.
Pembagian tanggung jawab itu menjelaskan dua gejala yang dilaporkan orang sebagai bug. Berkas yang tidak pernah muncul berarti daemon atau skripnya gagal menulisnya, bukan bahwa pengawasan salah dikonfigurasi. Berkas yang bertahan setelah penghentian berarti jalur penghentian tidak pernah selesai.
Ini juga menjelaskan mengapa panduan saat ini menyarankan menghindari konvensi itu ketika pengawasan dapat melacak proses utama secara langsung. Panduan itu bukan izin untuk mengubah jenis unit terpaket, karena perilaku daemon di latar depan, saat bercabang, atau saat memberi notifikasi harus cocok dengan apa yang dideklarasikan unit. Ubah jenisnya tanpa mengubah daemon dan Anda mendapat unit yang melaporkan kegagalan saat terowongan berjalan, atau sebaliknya. Cocokkan pasangannya, atau biarkan keduanya. Referensi layanan systemd menjelaskan pembagian kepemilikan itu.
Penghentian bersih versus keluaran terputus
Penghentian bersih meminta daemon keluar, menunggunya, dan membiarkan pengelola merapikan pembukuannya sendiri. Keluaran terputus, proses yang dibunuh, atau reboot di tengah penghentian melewati bagian dari urutan itu, dan berkas adalah yang tersisa. Menemukannya setelah crash memberi tahu Anda bahwa penghentian tidak selesai, bukan bahwa ada sesuatu yang mendengarkan.
Bandingkan stempel waktu berkas dengan boot terakhir dan dengan penghentian terakhir unit.
Lalu periksa bukti hidup secara langsung. Socket yang terikat ke porta VPN dan antarmuka terowongan yang memiliki alamat adalah bukti bahwa ada sesuatu yang berjalan, dengan cara yang tidak pernah dimiliki berkas teks di direktori runtime. Jika keduanya tidak ada, tidak ada yang berjalan, apa pun yang diklaim berkas itu.
Berhentilah menghapus berkas sebagai kebiasaan
Menghapusnya adalah langkah pemulihan yang sah setelah Anda memastikan tidak ada instans yang memilikinya dan peluncur mendokumentasikan perilaku ini.
Sebagai kebiasaan tetap sebelum mulai, itu menggagalkan pemeriksaan yang sedang Anda akali. Jika berkas basi kembali setelah setiap penghentian bersih, penulis dan siklus hidup penghentian tidak sepakat tentang siapa yang memiliki jalur itu, dan ketidaksepakatan itulah bug yang layak diperbaiki.
Pertahankan jalur masuk yang independen ke host, jalankan satu instans melalui pengelola normalnya, dan baca hasil pertama. Orang berikutnya mendapat unit yang entah bekerja atau menjelaskan dirinya.