Ekran qaralanda VPN düşür: kilid, boş ekran, yoxsa yuxu?
Kilidlənmiş sessiya, qaralmış ekran və yuxuya getmiş maşın üç fərqli hadisədir. VPN-in canlı saxlama mexanizmini günahlandırmazdan əvvəl onları journalctl ilə əlaqələndirin.
Kimsə ekran qaralanda VPN-in öldüyünü deyəndə ilk faydalı sual budur: üç hadisədən hansı həqiqətən baş verdi — sessiya kilidləndi, panel söndü, yoxsa bütün maşın yuxuya getdi. Bunlar ayrı taymerlər üzərində işləyən ayrı mexanizmlərdir və yalnız biri prosesin ümumiyyətlə planlaşdırılmasını dayandıra bilər. Aşağıdakı yoxlamaları ardıcıllıqla keçin. Suala cavab verən ilk yoxlamada dayanın, çünki ondan sonrakı hər yoxlama başqa bir şeyə cavab verir.
Birinci yoxlama: kilidi boş ekrandan və yuxudan ayırın
Kilid sessiyadan kimin istifadə edə biləcəyini dəyişir; kompozitor rəsm çəkməyə davam edir, şəbəkə yığını işləməyə davam edir və VPN müştərisi heç nə hiss etmir. Ekranın qaralması boşdayanma müddətindən sonra paneli söndürür və maşını tam oyaq saxlayır. Yuxu rejimi prosessorları dayandırır, yəni istifadəçi məkanında heç bir proses planlaşdırılmır, ona görə intervalı nə qədər qısa etsəniz də heç bir canlı saxlama işə düşə bilməz.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
Bu cədvəl «ekran qaraldı» ifadəsinin diaqnoz olmadığının səbəbidir. Beş dəqiqədə qaralmağa və otuz dəqiqədə yuxuya qurulmuş masaüstü altıncı dəqiqədə qaranlıq ekran göstərəcək, halbuki tunel tam sağlamdır. Otuzuncu dəqiqədəki nasazlıq başqa bir hadisə və başqa bir həlldir, amma ikisi də otağın o biri tərəfindən eyni görünür.
İkinci yoxlama: enerji və şəbəkə hadisələrini bir zaman xəttinə qoyun
Jurnalı bütün açılış yerinə məhdud bir pəncərə üçün oxuyun və həm giriş menecerini, həm də bağlantı sahibini daxil edin:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list
Birinci əmr yuxu sorğularını, oyanmanı və onlardan sonra gələn şəbəkə keçidlerini göstərir. İkincisi hazırda hansı inhibitor kilidini tutduğunu göstərir, bu da sizə nəyinsə yuxunu qəsdən bloklayıb-bloklamadığını və hansı proqram olduğunu deyir. Bağlantı sahibiniz NetworkManager deyilsə, vahid adlarını düzəldin və başqa istifadəçinin vahidini və ya sistem jurnalını oxumağın yerli siyasətdən asılı olduğunu unutmayın.
Çatışmayan sətir mənfi nəticə deyil. Seçilmiş vahidin jurnalı hesabınıza görünmürsə, yuxu qeydinin olmaması heç nə sübut etmir və boş filtrdən «o heç vaxt yatmayıb» nəticəsini çıxarmaq insanların bir həftə canlı saxlama ayarlaması ilə məşğul olmasının yoludur.
Üçüncü yoxlama: yuxuya gedibsə, bunun qəsdən olub-olmadığına qərar verin
Zaman xəttində yuxu keçidi görünən kimi sual VPN-in niyə qırıldığından maşının ümumiyyətlə yatmalı olub-olmadığına çevrilir. Noutbukda cavab çox vaxt bəlidir və tunelin kəsilməsi gözlənilən davranışdır, müştəri oyananda ondan bərpa olunmalıdır. Əlçatan qalmalı olan iş stansiyasında dəyişdirilməli olan şey yuxu siyasətidir. Bu iki maşından hansına baxdığınızı müəyyən etmək bir sual çəkir və bu, jurnalın sizin üçün cavablandıra bilməyəcəyi bir sualdır.
Onu daxil olmuş sessiyaya aid idarəetmə vasitələri ilə, ya da tələb bütün maşına aiddirsə, administratorun dəstəklədiyi mexanizmlə dəyişin. Başqa hesabla daxil olmuş halda ekran menecerinin ayarını redaktə etmək eyni hərəkət deyil və növbəti sessiya başlayana qədər işləmiş kimi görünəcək. Enerji idarəetməsini tamamilə söndürmək batareya ömrünə başa gələn və əsl siyasət sualını gizlədən geniş ilk cavabdır.
Dördüncü yoxlama: oyaq qalıbsa, şəbəkəyə və müştəriyə baxın
Tunelini itirmiş oyaq maşının üç hekayəsindən biri var: giriş şəbəkəsi düşdü, VPN müştərisi dayandı və ya yenidən başladı, ya da server tərəfi assosiasiyanı bitirdi, müştəri isə hələ də qoşulduğuna inanırdı. Əsas keçid hadisəsinin vaxt damğalarını tunel hadisəsi ilə müqayisə edin və hansının birinci gəldiyini dəqiqləşdirin.
Sonra bərpa yolunu ilkin sessiyadan ayrıca sınayın. Bərpa olunmuş tuneldən yeni sorğu uğurlu ola bilər, halbuki kəsintidən əvvəl açılmış uzunömürlü tətbiq sessiyası xarab qalır, çünki tətbiq köhnəlmiş soket və ya keşlənmiş ünvan saxlayır. Bu tətbiq problemidir, tunelin geri qayıtmadığına dair sübut deyil.
Faydalı hesabatın içində nə olur
Ardıcıllığı vaxt damğaları və sahiblərlə yazın: sessiya nə vaxt kilidləndi, ekran nə vaxt qaraldı, yuxu sorğusu qeydə alındımı, keçid nə vaxt düşdü və geri qayıtdı, tunel nə vaxt vəziyyətini dəyişdi və tətbiq həqiqətən nə etdi. Hər bəndin sahibi var, ona görə hər bənd Linux haqqında ümumi şikayətə çevrilmək yerinə düzgün adama verilə bilər.
Bu sətirlərdən hər hansı biri yoxdursa, dəyişdirilməli növbəti şey deyil, ölçülməli növbəti şey odur. Boşluğu olan zaman xətti təxminə əsaslanan ayar dəyişikliyindən daha çox məlumat verir.