Hvers vegna skeljar-púxunarprófun heldur áfram að mistakast þótt curl takist

Forðastu að geyma gamalt curl-mistök í skeljarbreytu eftir að síðari púxunarprófanir takast.

Púxinn mistekst einu sinni. Síðari beiðnir takast, en eftirlitið tilkynnir enn eitt mistakið. Athugaðu hvort skriftan mundi útgangsstöðuna frá í gær.

Þetta mynstur uppfærir breytuna aðeins þegar curl mistekst:

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

Eftir fyrstu niðurstöðu sem er ekki núll lætur heppin endurtekning status ósnortið. Það verður ekki núll bara af því að curl tókst.

Greindu frekar eftir núverandi skipun:

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

Vistfangið og tímannir eru dæmi. Þetta fjarlægir úreltu breytuna; það ákveður ekki hvaða endurheimtaraðgerð er viðeigandi.

Haltu athuguninni þröngri. Beiðnin er háð púxnum, leiðinni áfram, áfangastaðnum, TLS-staðfestingu og HTTP-niðurstöðu. Bilun á markinu getur látið hana mistakast á meðan SOCKS-þjónustan er heilbrigð. Óvænt HTTP 200 síða getur líka staðist prófun sem byggir eingöngu á stöðu án þess að veita efnið sem búist er við.

Veldu stýrðan svarasamning og haltu mistakastiginu. Endurræsing púxins við hverja curl-niðurstöðu sem er ekki núll getur truflað heilbrigðar lotur, á meðan raunverulega vandamálið á áfangastaðnum er ósnortið.

Tengdir greinar