Wanneer iemand sê die VPN het gesterf toe die skerm donker geword het, is die eerste nuttige vraag watter van drie gebeurtenisse werklik plaasgevind het: die sessie het gesluit, die paneel het afgeskakel, of die hele masjien het gaan slaap. Dit is afsonderlike meganismes op afsonderlike timers, en net een van hulle kan verhoed dat ’n proses hoegenaamd geskeduleer word. Werk die kontroles hieronder in volgorde deur. Stop by die eerste een wat die vraag beantwoord, want elke kontrole daarna beantwoord iets anders.

Kontrole een: skei die slot van die skermdoof van die slaap

’n Slot verander wie die sessie mag gebruik; die kompositor hou aan teken, die netwerkstapel hou aan werk en die VPN-kliënt merk niks. Skermdoof maak die paneel ná ’n onaktiewe tydperk af en laat die masjien heeltemal wakker. Slaap stop die verwerkingseenhede, wat beteken geen gebruikersproses word hoegenaamd geskeduleer nie, so geen lewendighou kan afvuur nie, maak nie saak hoe kort jy die interval stel nie.

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

Daardie tabel is waarom “die skerm het donker geword” nie ’n diagnose is nie. ’n Lessenaar wat op vyf minute doof en op dertig slaap, sal op minuut ses ’n donker skerm wys met ’n heeltemal gesonde tonnel. Die fout op minuut dertig is ’n ander gebeurtenis met ’n ander oplossing, en albei lyk identies van oor die kamer.

Kontrole twee: plaas krag- en netwerkgebeurtenisse op een tydlyn

Lees die joernaal vir ’n begrensde venster eerder as die hele opstart, en sluit beide die aanmeldbestuurder en die eienaar van die verbinding in:

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

Die eerste opdrag wys slaapversoeke, hervatting en die netwerkoorgange wat daarop gevolg het. Die tweede wys wat tans ’n inhibeerder-slot hou, wat jou vertel of iets doelbewus slaap blokkeer en watter program dit is. Pas die eenheidname aan as jou verbindingseienaar nie NetworkManager is nie, en onthou dat die lees van ’n ander gebruiker se eenheid of die stelseljoernaal van plaaslike beleid afhang.

’n Ontbrekende reël is nie ’n negatiewe resultaat nie. As die joernaal vir die gekose eenheid nie vir jou rekening sigbaar is nie, bewys die afwesigheid van ’n slaaprekord niks, en om “dit het nooit geslaap nie” uit ’n leë filter af te lei, is hoe mense ’n week lank lewendighou verstel.

Kontrole drie: as dit geslaap het, besluit of dit bedoel was

Sodra ’n slaapoorgang op die tydlyn is, verander die vraag van waarom die VPN gebreek het na of die masjien hoegenaamd moes slaap. Op ’n skootrekenaar is die antwoord dikwels ja, en die tonnelonderbreking is verwagte gedrag wat die kliënt by hervatting behoort te herstel. Op ’n werkstasie wat bereikbaar moet bly, is die slaapbeleid die ding om te verander. Om te besluit na watter van daardie twee masjiene jy kyk, neem een vraag, en dit is nie ’n vraag wat die joernaal vir jou kan antwoord nie.

Verander dit deur die kontroles wat aan die aangemelde sessie behoort, of deur ’n meganisme wat deur die administrateur ondersteun word as die vereiste masjienwyd is. Om ’n instelling van die skermbestuurder te redigeer terwyl jy as ’n ander rekening aangemeld is, is nie dieselfde aksie nie en sal lyk of dit gewerk het tot die volgende sessie begin. Om kragbestuur heeltemal af te skakel, is ’n breë eerste reaksie wat batterylewe kos en die werklike beleidsvraag verberg.

Kontrole vier: as dit wakker gebly het, kyk na die netwerk en die kliënt

’n Wakker masjien wat sy tonnel verloor het, het een van drie verhale: die toegangsnetwerk het geval, die VPN-kliënt het gestop of herbegin, of die bedienerkant het die assosiasie laat verval terwyl die kliënt bly glo het dat hy verbind is. Vergelyk die tydstempels van die onderliggende skakelgebeurtenis met die tonnelgebeurtenis, en wees presies oor watter eerste gekom het.

Toets dan die herstelpad afsonderlik van die oorspronklike sessie. ’n Vars versoek deur die herstelde tonnel kan slaag terwyl die langdurige toepassingsessie wat voor die onderbreking oopgemaak is, steeds stukkend bly, omdat die toepassing ’n verouderde sok of ’n gekaste adres vashou. Dit is ’n toepassingsprobleem, nie bewys dat die tonnel nagelaat het om terug te kom nie.

Wat ’n nuttige verslag bevat

Skryf die volgorde met tydstempels en eienaars: wanneer die sessie gesluit het, wanneer die skerm gedoof het, of ’n slaapversoek aangeteken is, wanneer die skakel geval en teruggekom het, wanneer die tonnel van toestand verander het, en wat die toepassing werklik gedoen het. Elke item het ’n eienaar, so elke item kan aan die regte persoon gegee word in plaas daarvan om ’n algemene klag oor Linux te word.

As enige van daardie rye ontbreek, is dit die volgende ding om te meet eerder as die volgende ding om te verander. ’n Tydlyn met ’n gaping is meer insiggewend as ’n instellingsverandering wat op ’n vermoede gemaak is.

Verwante artikels