Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site godot.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!mhuxn!houxm!ihnp4!godot!bruce From: bruce@godot.UUCP (Bruce Nemnich) Newsgroups: net.bugs.uucp Subject: Re: Re: hung line help needed Message-ID: <582@godot.UUCP> Date: Fri, 7-Dec-84 11:52:55 EST Article-I.D.: godot.582 Posted: Fri Dec 7 11:52:55 1984 Date-Received: Sat, 8-Dec-84 05:28:10 EST References: <85@daemon.UUCP> <33700001@trsvax.UUCP> <2923@allegra.UUCP> <542@godot.UUCP> <2933@allegra.UUCP> <1479@umcp-cs.UUCP> Reply-To: bruce@godot.UUCP (Bruce Nemnich) Organization: Thinking Machines, Cambridge, MA Lines: 17 Summary: I fixed the window of vulnerability in my sleep(3) as soon as you pointed it out. It doesn't help with the hung line problem though (I didn't expect it to, since it is not getting hung in sleep()). I have exactly the same situation as mentioned before. My outbound uucico occasionally gets hung in a read(2) system call. The read timeout SIGALRM is pending, but SIGALRM is blocked (*only* SIGALRM is blocked). I don't understand how SIGALRM could get blocked at any time in uucico. I grepped through the uucico and libc code, but I noticed no sigblock() or sigsetmask() calls other than the one I recently added to sleep(), and we know that's not the problem. That leads me to suspect a 4.2 kernel bug which is resulting in a spurious mask of SIGALRM. -- --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA ihnp4!godot!bruce, bjn@mit-mc.arpa ... soon to be bruce@godot.arpa