Hvilken NetworkManager-tilstand fikk varsleren din egentlig?

Tilstand fire utløser et varsel på én API og betyr noe annet på en annen, og koden viser ingen forskjell i det hele tatt. Hver tilstandsverdi i NetworkManager tilhører en navngitt oppregning, og oppregningene er ikke enige om hva et gitt tall betyr. Å kopiere et heltall fra en fungerende snutt til en annen tilbakeringing er derfor ikke en overføring av atferd; det er en tilfeldighet som venter på å bryte sammen. Finn typen først, så blir tallet lesbart.

Et tall uten type er bare et rykte

To oppregninger betyr noe her. Den ene beskriver en aktiv tilkobling generelt: ukjent, aktiverende, aktivert, deaktiverende, deaktivert. Den andre beskriver spesifikt en VPN-tilkobling, og den har flere stopp underveis, blant annet forberedelse, oppsett av tilkoblingen, IP-konfigurasjon og en autentiseringsforespørsel før noe aktiveres. Nummereringen deres starter på null i begge tilfeller og går deretter fra hverandre, så verdien som betyr deaktivert i den generelle oppregningen havner et sted midt i VPN-sekvensen. Ingen av overskriftene er feil; de svarer på forskjellige spørsmål.

Bruk den symbolske konstanten fra den installerte overskriften eller bindingen i stedet for et literalt tall. Navnet overlever en omnummerering; heltallet gjør det ikke.

Følg med på én tilkobling, ikke maskinen

Start fra profil-UUID-en du bryr deg om, og det aktive tilkoblingsobjektet som den aktiveringen opprettet. En enhetstilstand, eller tilstanden til en annen tunnel, er ikke en erstatning, selv når begge endres i samme øyeblikk. Behold objektets identitet sammen med observasjonen, slik at en senere rapport kan si hvilken profil som produserte den. Maskinen har mange tilstander; varselet handler om én av dem.

Bestem deretter hva varselet skal bety. En tilkobling som aldri nådde aktivering, er en oppsettsfeil, og en økt som var aktiv og deretter forsvant, er et tap. Disse fortjener forskjellige ord.

Si hvilken overgang du rapporterer

Lagre den forrige tilstanden og sammenlign den med den nye, i stedet for å teste den nye verdien isolert. En overgang til en feilet tilstand og en overgang ut av en aktivert tilstand er forskjellige hendelser selv når begge ender med ingenting tilkoblet. Noter årsaksstrengen ved siden av, fordi den ofte er den eneste delen en bruker kan handle på.

En bevisst frakobling er ikke en feil. Hvis varselet ikke kan se forskjellen, vil det lære folk å ignorere det.

Hold observatøren i live

Gjentatt avstemming må ikke reise nok en advarsel for en tilstand som ikke er endret. Den ene regelen fjerner det meste av støyen disse varslerne lager.

Håndter også tilfellet der behandleren starter på nytt eller det observerte objektet blir erstattet. En overvåker bundet til en utdatert identitet blir stille nøyaktig i det øyeblikket noe interessant skjer, og stillhet ser ut som helse. Gjenoppdag det gjeldende objektet etter en endring i behandlerens tilstedeværelse, og noter når gjenoppdagelsen skjedde. Ellers viser loggen en tunnel som bare sluttet å rapportere.

Lever varselet der brukeren er

En privilegert systemtilbakeringing arver ikke en skrivebordsøktes varseltjeneste. En melding sendt fra en behandler på root-nivå kan forsvinne uten feil, noe som gir en varsler som fungerer når den testes for hånd og aldri i praksis. Lever i økten som eier skrivebordet, eller la skrivebordets egen klient reise varselet.

Foretrekk klientens eksisterende varsel hvis det allerede dekker tilfellet, siden to varslere for én hendelse er et støtteproblem snarere enn redundans. Behold hendelsestiden, profilen og årsaken i støttenotatet, og hold passord og fullstendige profiler utenfor. Husk hva varselet er: en rapport om en observert tilstand, ikke en håndhevelsesmekanisme, fordi å blokkere trafikk mens tunnelen mangler er en egen policy med sin egen implementering.