Miks shelli puhverserveri kontroll jääb ebaõnnestunuks, kui curl õnnestub

Vältige vana curl-tõrke hoidmist shelli muutujas pärast seda, kui hilisemad puhverserveri kontrollid õnnestuvad.

Puhverserver ebaõnnestub korra. Hilisemad päringud õnnestuvad, kuid valvur teatab endiselt veel ühest tõrkest. Kontrollige, kas skript jättis meelde eilse väljumisoleku.

See muster uuendab muutujat ainult siis, kui curl ebaõnnestub:

status=0
# Repeated inside a loop:
curl ... || status=$?

Pärast esimest nullist erinevat tulemust jätab õnnestunud kordus status puutumata. See ei muutu nulliks ainult seetõttu, et curl õnnestus.

Hargnege hoopis praeguse käsu järgi:

if curl --proxy socks5h://127.0.0.1:1080 --noproxy '' \
    --fail --silent --show-error --connect-timeout 3 --max-time 10 \
    https://health.example/ >/dev/null; then
    echo "check succeeded"
else
    echo "check failed"
fi

Aadress ja ajad on näitlikud. See eemaldab vananenud muutuja; see ei otsusta, milline taastamistegevus on sobiv.

Hoidke vaatlus kitsas. Päring sõltub puhverserverist, edasisest marsruudist, sihtkohast, TLS-i kontrollist ja HTTP tulemusest. Sihtkoha katkestus võib selle ebaõnnestuda, samal ajal kui SOCKS teenus on terve. Ootamatu HTTP 200 leht võib samuti läbida ainult olekupõhise kontrolli, esitamata oodatud sisu.

Valige kontrollitud vastusleping ja säilitage tõrkeetapp. Puhverserveri taaskäivitamine iga nullist erineva curl-tulemuse korral võib rikkuda terveid sessioone, jättes tegeliku sihtkoha probleemi puutumata.

Seotud artiklid