VPN-reléet sluttar å godta SSH: grenser for fildeskriptorar

Ein WireGuard-handtrykk blir framleis fullført, peer viser framleis eit nyleg endepunkt, og likevel heng ei ny SSH-økt gjennom reléet bak det utan banner. Den kombinasjonen peikar bort frå tunnelen og mot prosessen som godtar socketen. Eit relé som socat sit i applikasjonsbanen med sitt eige deskriptorbudsjett, sine eigne born og sine eigne arva grenser. Vandringa nedanfor startar hos klienten og stoppar ved den første komponenten som ikkje kan opne ein ny socket.

Følg ruta før du endrar eit tal

Følg éin mislukka førespurnad i staden for å resonnera om tunnelen som heilskap. Klienten skriv inn i tunnelen, VPN-demonen dekrypterer og ruter, og reléet godtar på den andre sida. Kvart steg brukar deskriptorar, og det som vanlegvis går tom, er det siste.

Start med ein førespurnad du kan gjenskape, og mål tida. Viss TCP-handtrykket blir fullført, men ingen applikasjonsbanner kjem, tok reléet socketen og sette seg deretter fast i eit barn eller på oppstraumsbeinet. Viss sjølve handtrykket aldri blir fullført, er årsaka ruting, brannmur eller lyttartilstand, ikkje eit deskriptortak. Noter kva av dei to formene du såg, fordi dei peikar på ulike prosessar.

Tel også hoppa som dupliserer arbeid. Ein forgreinande lyttar overleverer kvar godtekne socket til eit barn som held si eiga kopi, så det reelle totalet er ein eigenskap ved heile treet, ikkje berre forelderen.

Les grensa reléet arva

Den einaste grensa som betyr noko, høyrer til den køyrande prosessen, og ho vart sett av det som starta prosessen. Å skrive ulimit -n i eit skal fortel om skalet. Spør tenestebehandlaren kva han brukte, og stadfest deretter på PID-en.

systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits

Fila limits skriv ut den mjuke og den harde grensa slik prosessen ser dei. Ein låg mjuk verdi under ein romsleg hard verdi tyder på at demonen har lov til å heve si eiga grense, og nokre gjer det ved oppstart; like låge verdiar tyder på at unit-fila er kjelda.

Drop-in-filer blir lasta i leksikalsk rekkjefølgje, og seinare filer vinn, så systemctl cat vpn-relay.service er den autoritative visninga av kva som gjeld. Å redigere ei fil som behandlaren aldri les, er den vanlegaste grunnen til at eit heva tal ikkje har effekt.

Skil jamn samtidigheit frå halden tilstand

To prosessar kan treffe same tak av ulike grunnar, og botemidla er ulike. Etterspurnad som følgjer nyttige samtidige økter, er eit kapasitetsspørsmål. Vekst som held fram etter at arbeidet er over, er ein lekkasje eller eit sett med økter som ingen lukka.

Mål i tomgang, ved din normale topp og igjen nokre minutt etter at lasta stoppar. Å telje opne oppføringar med ls /proc/PID/fd | wc -l mot den mjuke grensa fortel deg gapet, og eit tal éin eller to under taket er ein hard stopp, ikkje ein treg veg.

Når talet nektar å falle, sjå på socket-tilstandar i staden for totalar. Deskriptorar som sit i CLOSE_WAIT tyder på at peer lukka og di side aldri gjorde det, noko som er ein feil i livssyklusen til applikasjonen som ei større grense berre utset. Avgrens også barne-modellen: eit forgreinande relé utan tak på samtidige born tømmer deskriptorar, prosessplassar og minne samstundes.

Kontroller den nye verdien på den levande prosessen

Etter å ha redigert unit-fila, last behandlaren på nytt og start tenesta på nytt, sidan ei omlasting åleine aldri erstattar grenser som ein køyrande prosess allereie har arva. Stadfest på prosessen som faktisk tener trafikken.

systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l

Lina awk returnerer det nye paret; viss ho framleis viser det gamle, er drop-in-fila du redigerte ikkje den som blir lasta. Talet frå ss er lastkontrollen din, så opne talet på økter du ventar, og sjå det stige. Eit tal som held fram med å stige etter at desse øktene blir lukka, tyder på at grensa aldri var heile problemet.

Éi åtvaring følgjer kvar stor auke. Applikasjonar som spør med select(), kan ikkje overvake deskriptorar over FD_SETSIZE, som er 1024 på typiske bygg, så eit tak heva forbi det kan gi feil som verkar urelaterte. systemd-køyringsreferansen ber same åtvaringa for tenestene han startar.

Hald omstarten unna tilgjengelegheita til tunnelen

Omstart av reléet droppar dei aktive øktene, og det er ei eiga hending frå VPN-en som fell. Ordne endringa slik at tunnelen blir oppe medan reléet syklar, og varsle alle kvar langvarige økt kryssar han.

Tilbakerulling er den førre unit-fila pluss ein omstart til, og den fila blir på plass til den nye verdien har overlevd ein arbeidsdag. Lukk deretter løkka med førespurnaden som opphavleg feila: éi ny SSH-økt gjennom reléet, éin overføring lang nok til å bety noko, og eit deskriptortal som går tilbake til tomgangsnivået.