We run Sn1per internally and have come across this issue with unreliable web servers, particularly older network equipment, which impact the reliability and resilance of Sn1per especially as an unattended tool.
Some curl/wget commands in the Sn1per codebase use --connect-timeout but only a handful have --max-time/--read-timeout which can cause Sn1per to hang in the event of a socket being established but then not closed, eg due to a httpd crashing.
The cases I'm talking about aren't just about efficiency, they've been sitting there for 30+ mins before we noticed and killed the offending process, so I'm not sure they would have terminated by themselves at all without a network interruption.
I hacked together some changes to the particular files that caused ours to hang, but note that curl is implemented inconsistently throughout the code, and this error may just as easily occur elsewhere.
Hi all,
We run Sn1per internally and have come across this issue with unreliable web servers, particularly older network equipment, which impact the reliability and resilance of Sn1per especially as an unattended tool.
Some curl/wget commands in the Sn1per codebase use --connect-timeout but only a handful have --max-time/--read-timeout which can cause Sn1per to hang in the event of a socket being established but then not closed, eg due to a httpd crashing.
The cases I'm talking about aren't just about efficiency, they've been sitting there for 30+ mins before we noticed and killed the offending process, so I'm not sure they would have terminated by themselves at all without a network interruption.
I hacked together some changes to the particular files that caused ours to hang, but note that curl is implemented inconsistently throughout the code, and this error may just as easily occur elsewhere.
Cheers,
Stefan
webporthttp.sh.patch webporthttps.sh.patch