Mengapa unit VPN bermula sebelum rangkaian lalu mati
Unit yang bermula sebelum pautan mempunyai alamat gagal dengan cara yang kelihatan rawak. Buktikan urutannya daripada jurnal, kemudian tambah penantian dan cubaan semula.
Butkan mesin, log masuk, dan ketahui bahawa terowong naik lalu mati beberapa saat kemudian. Profil itu baik, sijil itu baik, dan satu-satunya jejak yang tinggal ialah jurnal daripada but itu. Apa yang biasa berlaku ialah perlumbaan: unit bermula sebelum mesin mempunyai alamat, dan urutan yang diisytiharkannya tidak bermaksud seperti yang kelihatan. Semua di bawah adalah tentang membuktikan perlumbaan itu daripada bukti dan menutupnya dengan betul.
Sasaran ialah titik pertemuan, bukan pengurus
network-online.target tidak tahu apa itu rangkaian. Ia ialah titik penyelarasan yang mengumpul perkhidmatan yang sepatutnya melambatkan permulaan sehingga pautan boleh digunakan, dan ia mewakilkan takrifan itu kepada pengurus rangkaian yang mana pun memiliki mesin itu. Pada kebanyakan desktop dan pelayan itu bermaksud perkhidmatan tunggu yang dibekalkan oleh NetworkManager atau systemd-networkd. Jika tiada satu pun diaktifkan, sasaran tiada apa-apa untuk ditunggu, jadi ia selesai pada saat sesuatu menariknya masuk, yang boleh berlaku jauh sebelum DHCP menjawab. Baris urutan dalam unit anda jujur dan tetap tidak berguna.
Jadi soalan pertama bukanlah apa yang diisytiharkan unit anda. Tetapi sama ada sesuatu pada mesin ini benar-benar melakukan penantian itu.
Baca but terakhir dan bukan fail unit
Fail unit menerangkan niat, dan jurnal menerangkan apa yang berlaku. Minta hanya but itu, dengan cap masa monotonik supaya setiap mesej duduk pada satu jam. Kemudian cari dua baris: saat unit terowong mula bermula, dan saat alamat muncul atau perkhidmatan tunggu selesai. Susun kedua-dua nombor itu dan perlumbaan sama ada disahkan atau dikecualikan.
Paparan kebergantungan mengesahkannya. Jika rangkaian kritikal untuk unit terowong tidak mengandungi perkhidmatan tunggu, tiada apa-apa pada laluan itu melambatkan permulaan, dan sasaran tidak melakukan kerja yang anda anggap. Dua paparan, satu kesimpulan.
systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office
Tambah penantian, kemudian cubaan semula
Gunakan drop-in dan bukannya menyunting unit yang dibungkus, supaya kemas kini pakej tidak membuang perubahan itu secara senyap. Dua arahan penting: unit mesti disusun selepas sasaran, dan ia mesti menarik sasaran ke dalam transaksi yang sama. Urutan sahaja tidak memanggil sasaran; keinginan yang melakukannya.
Unit klien OpenVPN yang dibungkus sudah membawa kedua-duanya. Unit yang ditulis tangan biasanya membawa satu atau tidak sama sekali, yang wajar diperiksa sebelum anda menambah apa-apa.
[Service]
Restart=on-failure
RestartSec=15
Mengapa tidur tetap ialah perangkap
Tidur dalam ExecStartPre terasa seperti pembetulan urutan dan berkelakuan seperti kelewatan dengan langkah tambahan. Ia melambatkan setiap but, termasuk yang sihat, dan masih kalah apabila pautan mengambil masa lebih lama daripada nombor yang anda pilih.
Lebih teruk, ia menyembunyikan sama ada perkhidmatan tunggu berfungsi, jadi kegagalan seterusnya muncul sebagai masalah yang benar-benar baharu dan bukannya yang sama dengan masa berbeza. Kelewatan mula semula yang singkat ialah instrumen yang lebih baik: ia tidak berbelanja apa-apa pada but yang sihat dan menukar perlumbaan yang kalah menjadi satu lagi cubaan. Kekalkan selang itu sederhana dan biarkan unit berjaya. Jika ia mula semula selama-lamanya, profil itu rosak dan berapa banyak cubaan semula pun tidak akan mengubahnya, jadi baca log dan bukannya menaikkan selang.
Apabila urutan betul dan nama masih gagal
Unit aktif dengan laluan terowong bermakna urutan telah melakukan tugasnya dan kesalahan yang tinggal berada satu lapisan lebih tinggi. Bentuk biasa ialah tetapan penyelesai yang digunakan oleh skrip up terowong sebelum pautan atau penyelesai bersedia untuk menyimpannya. Bandingkan keadaan penyelesai semasa kegagalan dengan keadaan selepas unit terowong dimulakan semula.
Jika mula semula membaiki carian, anda mempunyai kecacatan urutan permulaan dan bukan pelayan DNS yang salah, dan kedua-duanya memerlukan pembaikan berbeza. Kemudian buktikan semuanya dengan but sejuk dan bukannya mula semula perkhidmatan, kerana mula semula berjalan terhadap rangkaian yang sudah naik dan akan menyembunyikan tepat kecacatan yang anda kejar. Ulangi dengan pautan sengaja diperlahankan, dan anggap unit yang hanya berfungsi apabila rangkaian pantas sebagai masih rosak.