Date: Tue, 15 Aug 2000 09:50:02 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/20613: fetch -T n is not timeout correctly Message-ID: <200008151650.JAA67910@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/20613; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: ishizuka@ish.org Cc: FreeBSD-gnats-submit@FreeBSD.ORG, des@freebsd.org Subject: Re: bin/20613: fetch -T n is not timeout correctly Date: Wed, 16 Aug 2000 02:48:58 +1000 (EST) On Tue, 15 Aug 2000 ishizuka@ish.org wrote: > >Description: > > % fetch -T 5 http://www.hoge.com/index.html > > When server 'www.hoge.com' is down or can't lookup address from > DNS server, fetch command is not timeout with 5 seconds. > Older version of fetch (with 4.0R or 3.4R) is timeout with 5 seconds. This reminded me of an old problem with ping(8). ^C doesn't work for killing ping when DNS lookup hangs, provided you wait a second or two for execution to reach res_send(). This is because res_send() retries after EINTR, so it doesn't work with signal handlers that just set a flag. ping's SIGINT handler was fixed a few years ago to just set a flag (previously it called stdio functions). The problem in fetch(1) seems to be the same. fetch's SIGINT and SIGALRM handlers just set a flag, so neither -T nor ^C can be used to kill fetch when DNS lookup hangs. ping's SIGALRM handler also just sets a flag, but this works right because ping only uses alarms to control syscalls and EINTR works right for syscalls. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008151650.JAA67910>