OpenVPN Bermula tetapi Tidak Mencetak Apa-apa: Semak log-append Dahulu

Anda memulakan OpenVPN dari shell dengan fail konfigurasi, dan terminal terus berdiri tanpa sebarang output. Tiada sepanduk, tiada ralat, tiada gesaan. Naluri mengatakan pelancaran gagal, jadi anda memulakan satu lagi salinan, kemudian satu lagi, dan mesin berakhir dengan beberapa contoh yang separuh dikonfigurasi. Sebelum semua itu, semak profil untuk arahan yang sudah mengubah hala log ke tempat lain. Senyap ialah sifat konsol, bukan sifat proses.

Senyap mempunyai dua penjelasan yang sangat berbeza

Yang pertama ialah proses berjalan dengan baik dan menulis ke fail yang anda tidak perhatikan. Yang kedua ialah ia keluar serta-merta dengan ralat direkodkan dalam fail yang sama.

Kedua-duanya meninggalkan terminal kosong, dan satu soalan memisahkannya: adakah proses wujud sekarang, dan apa yang ada dalam fail yang disuruh ditulisnya. Jawab itu sebelum menyentuh konfigurasi lagi. Melancarkan semula untuk mendapatkan output ialah cara dua contoh mula berebut satu peranti terowong dan port yang sama, yang menghasilkan ralat tanpa kaitan dengan masalah asal.

Cari arahan itu, kemudian cari proses itu.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Cari destinasi yang digunakan oleh proses yang sedang berjalan

Baca profil yang sebenarnya digunakan untuk memulakan proses, bukan yang anda sunting. Contoh yang dikendalikan perkhidmatan biasanya memuatkan laluan berbeza dan berjalan dalam direktori kerja berbeza, jadi nama fail relatif diselesaikan di tempat yang tidak anda jangkakan.

Arahan cd yang jelas menjadikan perbezaan itu lebih tajam, kerana laluan relatif bergerak bersama perubahan direktori. Jika anda mewarisi konfigurasi ini, fail mungkin terletak di tempat yang tiada siapa akan cari sekarang.

Bandingkan masa ubah suai fail dengan saat anda melancarkannya. Log minggu lepas ialah bukti tentang minggu lepas. Kemudian baca baris terakhir fail yang berubah, dan anggap apa sahaja di situ sebagai mesej permulaan yang anda terlepas.

log berbanding log-append: bukti dan pemadaman

log-append menambah kepada apa yang sudah ada dalam fail. log membuka fail untuk ditulis dan memotongnya, jadi bertukar antara keduanya boleh memadamkan larian yang anda hendak baca.

Jika seseorang mengubah arahan semasa menyahpepijat, bukti terdahulu sudah hilang dan saiz fail akan kelihatan mencurigakan kecil. Itu wajar diketahui sebelum anda membandingkan dua larian dan menyimpulkan sesuatu telah berubah. Padam log dengan sengaja atau kekalkannya, tetapi ketahui mana yang anda lakukan. Bukti yang anda buang dengan sengaja lebih mudah difikirkan daripada bukti yang hilang secara tidak sengaja.

Kedua-dua pilihan tidak mencipta direktori induk yang hilang, dan tidak memberi akses melalui kebenaran sistem fail atau kotak pasir perkhidmatan. Laluan yang kelihatan betul dalam konfigurasi masih boleh tidak boleh ditulis oleh akaun yang menjalankan daemon, dan dalam keadaan itu daemon mungkin gagal sebelum dapat melaporkan apa-apa. Semak kewujudan direktori dan pemiliknya sebelum menganggap nama fail ialah masalahnya.

Apabila pembalut perkhidmatan menangkap output

Di bawah systemd, output standard dan ralat pergi ke jurnal melainkan arahan fail yang jelas diutamakan, dan pembalut vendor mungkin menangkapnya di tempat lain sama sekali.

Itulah sebabnya profil yang sama berkelakuan berbeza daripada shell dan daripada unit. Persekitaran unit, direktori kerjanya dan aliran standardnya semuanya berbeza daripada shell interaktif anda. Laluan relatif boleh diselesaikan dalam satu konteks dan tidak sampai ke mana-mana dalam konteks yang lain. Baca definisi unit apabila kedua-duanya tidak sependapat, bukan profil.

Bandingkan kedua-dua susunan pelancaran dan bukannya menyimpulkan salah satunya rosak. Baca baris arahan unit dan persekitarannya, kemudian baca jurnal untuk tetingkap masa yang sama. Jika pembalut mengubah hala output ke failnya sendiri, fail itu kini log anda, dan arahan OpenVPN tidak lagi relevan tentang ke mana mesej pergi.

Naikkan tahap perincian hanya selepas anda boleh membacanya

Menaikkan tahap perincian sebelum menemui destinasi hanya menghasilkan lebih banyak teks di tempat yang anda tidak lihat.

Sebaik sahaja anda tahu ke mana output pergi, tahap sederhana menunjukkan profil dihuraikan dan sambungan dicuba. Dua atau tiga sudah cukup untuk masalah permulaan. Tahap lebih tinggi berbaloi apabila kegagalan ialah butiran rundingan, dan ia juga membuat fail membesar dengan cepat.

Kemudian baca ralat sebenar. Terminal yang senyap tidak membuktikan apa-apa tentang sama ada terowong naik, dan kegagalan yang direkodkan dalam fail itulah yang wajar dibaiki.