Kvifor ein shell-proxykontroll blir ståande som mislukka etter at curl lukkast

Unngå å behalde ein gammal curl-feil i ein shell-variabel etter at seinare proxykontrollar lukkast.

Proxyen feilar éin gong. Seinare førespurnader lukkast, men overvakinga melder framleis om endå ein feil. Sjekk om skriptet hugsa utgangsstatusen frå i går.

Dette mønsteret oppdaterer berre variabelen når curl feilar:

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

Etter det første ikkje-null-resultatet lèt ein vellukka iterasjon status stå urørt. Det blir ikkje null berre fordi curl lukkast.

Forgrein deg i staden på den gjeldande kommandoen:

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

Adressa og tidene er illustrerande. Dette fjernar den utdaterte variabelen; det avgjer ikkje kva gjenopprettingstiltak som er høveleg.

Hald observasjonen smal. Førespurnaden er avhengig av proxyen, den vidare ruta, målet, TLS-verifiseringa og HTTP-resultatet. Eit avbrot hos målet kan få han til å feile medan SOCKS-tenesta er frisk. Ei uventa HTTP 200-side kan òg klare ein kontroll som berre ser på status, utan å levere det forventa innhaldet.

Vel ein kontrollert svaravtale og behald feiltrinnet. Å starte proxyen på nytt ved kvart ikkje-null curl-resultat kan forstyrre friske økter, medan det eigentlege målproblemet blir ståande urørt.

Relaterte artiklar