Katero stanje NetworkManager je vaš obveščevalec dejansko prejel?

Stanje štiri sproži obvestilo na enem API in pomeni nekaj drugega na drugem, koda pa ne kaže nobene razlike. Vsaka vrednost stanja v NetworkManagerju pripada poimenovanemu naštevanju, naštevanja pa se ne strinjajo, kaj pomeni določeno število. Kopiranje celega števila iz delujočega izseka v drug povratni klic torej ni prenos vedenja; je naključje, ki čaka, da se zlomi. Najprej poiščite vrsto in število postane berljivo.

Število brez vrste je le govorica

Tu sta pomembna dva naštevanja. Eno opisuje aktivno povezavo na splošno: neznano, aktivirajoče, aktivno, deaktivirajoče, deaktivirano. Drugo opisuje posebej povezavo VPN in ima na poti več postankov, vključno s pripravo, nastavitvijo povezave, konfiguracijo IP in zahtevo za preverjanje pristnosti, preden se karkoli aktivira. Njihovo številčenje se v obeh primerih začne pri nič in se nato razhaja, zato vrednost, ki v splošnem naštevanju pomeni deaktivirano, pristane nekje na sredini zaporedja VPN. Nobena glava ni napačna; odgovarjata na različni vprašanji.

Uporabite simbolno konstanto iz nameščene glave ali vezave namesto literala. Ime preživi preštevilčenje; celo število ne.

Opazujte eno povezavo, ne stroja

Začnite pri UUID profila, ki vas zanima, in pri predmetu aktivne povezave, ki ga je ustvarila ta aktivacija. Stanje naprave ali stanje drugega tunela ni nadomestilo, tudi ko se oba spremenita v istem trenutku. Ohranite identiteto predmeta skupaj z opazovanjem, da lahko poznejše poročilo pove, kateri profil ga je ustvaril. Stroj ima veliko stanj; obvestilo se nanaša na eno od njih.

Nato se odločite, kaj naj obvestilo pomeni. Povezava, ki ni nikoli dosegla aktivacije, je napaka pri nastavitvi, seja, ki je bila aktivna in nato izginila, pa je izguba. Ti si zaslužita različne besede.

Povejte, kateri prehod poročate

Shranite prejšnje stanje in ga primerjajte z novim, namesto da bi novo vrednost preizkušali ločeno. Prehod v neuspešno stanje in prehod iz aktivnega stanja sta različna dogodka, tudi ko se oba končata brez česar koli povezanega. Zraven zapišite niz razloga, ker je pogosto edini del, na katerega lahko uporabnik ukrepa.

Namenoma prekinjena povezava ni okvara. Če obvestilo ne more ločiti, bo ljudi naučilo, da ga ignorirajo.

Ohranite opazovalca pri življenju

Ponavljajoče poizvedovanje ne sme sprožiti še enega opozorila za stanje, ki se ni spremenilo. To eno pravilo odstrani večino hrupa, ki ga ustvarjajo ti obveščevalci.

Obvladajte tudi primer, ko se upravitelj znova zažene ali se opazovani predmet zamenja. Opazovalec, vezan na zastarelo identiteto, utihne točno v trenutku, ko se zgodi kaj zanimivega, in tišina je videti kot zdravje. Znova odkrijte trenutni predmet po spremembi prisotnosti upravitelja in zabeležite, kdaj se je ponovno odkritje zgodilo. Sicer dnevnik pokaže tunel, ki je preprosto prenehal poročati.

Dostavite obvestilo tja, kjer je uporabnik

Privilegirani sistemski povratni klic ne podeduje obvestilne storitve seje namizja. Sporočilo, poslano iz upravljalnika na ravni root, lahko izgine brez napake, kar ustvari obveščevalca, ki deluje pri ročnem preizkušanju in nikoli v praksi. Dostavite v sejo, ki ima namizje, ali pustite, da obvestilo sproži lastni odjemalec namizja.

Prednost dajte obstoječemu obvestilu odjemalca, če že pokriva primer, ker sta dva obveščevalca za en dogodek problem podpore in ne odvečnost. V zapisu podpore ohranite čas dogodka, profil in razlog, gesla in celotne profile pa pustite zunaj njega. Zapomnite si, kaj obvestilo je: poročilo o opazovanem stanju, ne mehanizem izvrševanja, ker je blokiranje prometa ob odsotnem tunelu ločena politika z lastno izvedbo.