Apabila seseorang berkata VPN mati apabila skrin menjadi gelap, soalan berguna pertama ialah peristiwa mana antara tiga yang benar-benar berlaku: sesi dikunci, panel dimatikan, atau seluruh mesin masuk tidur. Itu mekanisme berasingan pada pemasa berasingan, dan hanya satu daripadanya boleh menghalang proses daripada dijadualkan sama sekali. Lalui pemeriksaan di bawah mengikut urutan. Berhenti pada yang pertama yang menjawab soalan, kerana setiap pemeriksaan selepasnya menjawab sesuatu yang lain.

Pemeriksaan satu: asingkan kunci daripada kosong dan daripada tidur

Kunci mengubah siapa yang dibenarkan menggunakan sesi; kompositor terus melukis, tindanan rangkaian terus berjalan dan klien VPN tidak menyedari apa-apa. Pengosongan skrin mematikan panel selepas selang melahu dan membiarkan mesin kekal sepenuhnya jaga. Gantung menghentikan CPU, bermakna tiada proses ruang pengguna dijadualkan, jadi tiada kekal sambungan boleh tercetus, sesingkat mana pun selang yang anda tetapkan.

EventWhat it stopsCan it kill the tunnel?
Session lockInput to your sessionNo
Display blankThe panelNo
Suspend to RAMCPU scheduling, hence every processYes, and silently
HibernateEverything, with state written to diskYes

Jadual itulah sebabnya «skrin menjadi gelap» bukan diagnosis. Desktop yang ditetapkan untuk kosong pada lima minit dan gantung pada tiga puluh akan menunjukkan skrin gelap pada minit keenam dengan terowong yang sepenuhnya sihat. Kegagalan pada minit ketiga puluh ialah peristiwa lain dengan pembaikan lain, dan kedua-duanya kelihatan sama dari seberang bilik.

Pemeriksaan dua: letakkan peristiwa kuasa dan rangkaian pada satu garis masa

Baca jurnal untuk tetingkap terhad dan bukan keseluruhan but, dan sertakan kedua-dua pengurus log masuk dan pemilik sambungan:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

Perintah pertama menunjukkan permintaan tidur, bangun semula dan peralihan rangkaian yang menyusul. Yang kedua menunjukkan apa yang sedang memegang kunci perencat, yang memberitahu anda sama ada sesuatu sengaja menyekat tidur dan program mana. Laraskan nama unit jika pemilik sambungan anda bukan NetworkManager, dan ingat bahawa membaca unit pengguna lain atau jurnal sistem bergantung pada dasar setempat.

Baris yang hilang bukan hasil negatif. Jika jurnal unit yang dipilih tidak kelihatan kepada akaun anda, ketiadaan rekod tidur tidak membuktikan apa-apa, dan membuat kesimpulan «ia tidak pernah tidur» daripada penapis kosong ialah cara orang menghabiskan seminggu melaras kekal sambungan.

Pemeriksaan tiga: jika ia tidur, tentukan sama ada itu memang disengajakan

Sebaik sahaja peralihan tidur muncul pada garis masa, soalan berubah daripada mengapa VPN rosak kepada sama ada mesin sepatutnya tidur sama sekali. Pada komputer riba jawapannya selalunya ya, dan terputusnya terowong ialah tingkah laku yang dijangka yang perlu dipulihkan oleh klien apabila bangun. Pada stesen kerja yang sepatutnya kekal boleh dicapai, dasar tidur ialah perkara yang perlu diubah. Menentukan mesin mana antara dua ini yang anda hadapi memerlukan satu soalan, dan itu bukan soalan yang jurnal boleh jawab untuk anda.

Ubahnya melalui kawalan yang dimiliki sesi yang dilog masuk, atau melalui mekanisme yang disokong pentadbir jika keperluan itu untuk seluruh mesin. Mengedit tetapan pengurus paparan semasa anda dilog masuk sebagai akaun lain bukan tindakan yang sama dan akan kelihatan berjaya sehingga sesi seterusnya bermula. Mematikan pengurusan kuasa sepenuhnya ialah tindak balas pertama yang luas yang menelan hayat bateri dan menyembunyikan soalan dasar yang sebenar.

Pemeriksaan empat: jika ia kekal jaga, lihat rangkaian dan klien

Mesin jaga yang kehilangan terowongnya mempunyai salah satu daripada tiga cerita: rangkaian capaian jatuh, klien VPN berhenti atau dimulakan semula, atau pihak pelayan membiarkan persekutuan tamat tempoh sementara klien terus percaya ia bersambung. Bandingkan cap masa peristiwa pautan asas dengan peristiwa terowong, dan tepat tentang mana yang datang dahulu.

Kemudian uji laluan pemulihan secara berasingan daripada sesi asal. Permintaan baharu melalui terowong yang pulih boleh berjaya sementara sesi aplikasi jangka panjang yang dibuka sebelum terputus kekal rosak, kerana aplikasi memegang soket lapuk atau alamat yang dicache. Itu masalah aplikasi, bukan bukti bahawa terowong gagal kembali.

Apa yang terkandung dalam laporan berguna

Tuliskan urutan dengan cap masa dan pemilik: bila sesi dikunci, bila skrin menjadi gelap, sama ada permintaan tidur direkodkan, bila pautan jatuh dan kembali, bila terowong menukar keadaan dan apa yang sebenarnya dilakukan aplikasi. Setiap item mempunyai pemilik, jadi setiap item boleh diserahkan kepada orang yang betul dan bukannya menjadi aduan umum tentang Linux.

Jika mana-mana baris itu hilang, itulah perkara seterusnya yang perlu diukur dan bukan perkara seterusnya yang perlu diubah. Garis masa dengan jurang lebih bermaklumat daripada perubahan tetapan yang dibuat atas agakan.

Artikel berkaitan