VPN falas kiam la ekrano malheliĝas: ŝloso, malplenigo aŭ paŭzo?

Kiam iu diras ke la VPN mortis kiam la ekrano malheliĝis, la unua utila demando estas kiu el tri eventoj vere okazis: la seanco ŝlosiĝis, la panelo malŝaltiĝis, aŭ la tuta maŝino endormiĝis. Tiuj estas apartaj mekanismoj sur apartaj tempigiloj, kaj nur unu el ili povas tute haltigi la planadon de procezo. Trairu la kontrolojn sube laŭorde. Haltu ĉe la unua, kiu respondas la demandon, ĉar ĉiu sekva kontrolo respondas al io alia.

Kontrolo unu: apartigu la ŝloson de la malplenigo kaj de la dormo

Ŝloso ŝanĝas la uzrajton de la seanco; la kompostilo daŭre desegnas, la reta stako daŭre funkcias, kaj la VPN-kliento tute ne rimarkas. Malplenigo de la ekrano malŝaltas la panelon post senaktiva intervalo kaj lasas la maŝinon plene veka. Paŭzo haltigas la procesorojn, kio signifas ke neniu procezo en uzantspaco estas planata, do neniu vivtena signalo povas ekagi, kiom ajn mallongan intervalon vi agordos.

Tiu tabelo estas la kialo, ke «la ekrano malheliĝis» ne estas diagnozo. Labortabla komputilo agordita malplenigi post kvin minutoj kaj paŭzi post tridek montros malhelan ekranon en la sesa minuto kun tute sana tunelo. La fiasko en la trideka minuto estas alia evento kun alia solvo, kaj ambaŭ aspektas idente de la alia flanko de la ĉambro.

Kontrolo du: metu potencajn kaj retajn eventojn sur unu tempan linion

Legu la ĵurnalon por limigita fenestro anstataŭ la tuta starto, kaj inkluzivu kaj la ensalutilan administrilon kaj la posedanton de la konekto:

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

La unua komando montras dormpetojn, revigliĝon kaj la retajn transirojn, kiuj sekvis ilin. La dua montras kio nun tenas inhibician ŝloson, kio diras al vi ĉu io intence blokas dormon kaj kiu programo ĝi estas. Alĝustigu la unuajn nomojn se la posedanto de via konekto ne estas NetworkManager, kaj memoru ke legado de unuo de alia uzanto aŭ de la sistema ĵurnalo dependas de loka politiko.

Mankanta linio ne estas negativa rezulto. Se la ĵurnalo de la elektita unuo ne estas videbla por via konto, la foresto de dormregistro pruvas nenion, kaj konkludi «ĝi neniam dormis» el malplena filtrilo estas la maniero, kiel homoj pasigas semajnon agordante vivtenajn signalojn.

Kontrolo tri: se ĝi paŭzis, decidu ĉu tio estis intenca

Unufoje kiam dormtransiro estas sur la tempa linio, la demando ŝanĝiĝas de kial la VPN rompiĝis al ĉu la maŝino entute devintus dormi. Sur tekkomputilo la respondo ofte estas jes, kaj la tunela interrompo estas atendata konduto, de kiu la kliento devus resaniĝi ĉe revigliĝo. Sur laborejo, kiu devus resti atingebla, la dormpolitiko estas tio, kion oni devas ŝanĝi. Decidi, kiun el tiuj du maŝinoj vi rigardas, postulas unu demandon, kaj tio ne estas demando, kiun la ĵurnalo povas respondi por vi.

Ŝanĝu ĝin per la regiloj, kiuj apartenas al la ensalutinta seanco, aŭ per administranto-subtenata mekanismo se la postulo estas por la tuta maŝino. Redakti agordon de la ekrana administrilo dum vi estas ensalutinta kiel alia konto ne estas la sama ago kaj aspektos, kvazaŭ ĝi funkciis, ĝis la sekva seanco komenciĝos. Tute malŝalti la potencadministradon estas larĝa unua reago, kiu kostas baterian vivon kaj kaŝas la veran politikan demandon.

Kontrolo kvar: se ĝi restis veka, rigardu la reton kaj la klienton

Veka maŝino, kiu perdis sian tunelon, havas unu el tri rakontoj: la alirreta reto falis, la VPN-kliento haltis aŭ restartis, aŭ la servila flanko lasis la asociiĝon eksvalidiĝi dum la kliento daŭre kredis, ke ĝi estas konektita. Komparu la tempindikojn de la suba ligila evento kun la tunela evento, kaj estu preciza pri tio, kiu venis unue.

Poste testu la resaniĝan vojon aparte de la origina seanco. Nova peto tra la resanigita tunelo povas sukcesi dum la longdaŭra aplikaĵa seanco malfermita antaŭ la interrompo restas rompita, ĉar la aplikaĵo tenas malaktualan ingon aŭ kaŝmemorigitan adreson. Tio estas aplikaĵa problemo, ne pruvo ke la tunelo malsukcesis reveni.

Kion enhavas utila raporto

Skribu la sekvencon kun tempindikoj kaj posedantoj: kiam la seanco ŝlosiĝis, kiam la ekrano malpleniĝis, ĉu dormpeto estis registrita, kiam la ligilo falis kaj revenis, kiam la tunelo ŝanĝis staton, kaj kion la aplikaĵo efektive faris. Ĉiu ero havas posedanton, do ĉiu ero povas esti transdonita al la ĝusta persono anstataŭ iĝi ĝenerala plendo pri Linux.

Se iu el tiuj linioj mankas, tio estas la sekva afero mezurenda, ne la sekva afero ŝanĝenda. Tempa linio kun breĉo estas pli informa ol agorda ŝanĝo farita surbaze de supozo.