From owner-freebsd-hackers Wed May 19 17:44:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.bby.com.au (ns.bby.com.au [192.83.119.129]) by hub.freebsd.org (Postfix) with ESMTP id 51C3315816; Wed, 19 May 1999 17:44:08 -0700 (PDT) (envelope-from gnb@itga.com.au) Received: (from daemon@localhost) by fw.bby.com.au (8.8.8/8.6.9) id KAA13993; Thu, 20 May 1999 10:44:06 +1000 (EST) Received: from lightning.itga.com.au(192.168.71.20) via SMTP by fw.bby.com.au, id smtpd013990; Thu May 20 00:44:04 1999 Received: from lightning (lightning [192.168.71.20]) by lightning.itga.com.au (8.9.1a/8.9.1) with ESMTP id KAA14033; Thu, 20 May 1999 10:44:04 +1000 (EST) Message-Id: <199905200044.KAA14033@lightning.itga.com.au> X-Mailer: exmh version 2.0.1 12/23/97 From: Gregory Bond To: Dan Nelson Cc: Andre Rikkert de Koe , freebsd-bugs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: timeconsuming processes on FreeBSD 3.1 In-reply-to: Your message of Wed, 19 May 1999 11:22:02 -0500. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 May 1999 10:44:03 +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It's usually due to a bug in the application. When a user exits, the > stdin/stdout filedescriptors on any backgrounded processes go away. > That makes any read() calls return with an error. If the application > doesn't check the return value of its read(), it can go into a tight > loop it'll never exit. There's another failure mode that has the same results. When a user logs out, the process is supposed to receive a SIGHUP (the HUP is from "HangUP" as in modems!). Applications are supposed to exit gracefully on receipt of SIGHUP, and if the application does nothing in the code it does work. Some applications try and be clever: they catch SIGHUP and attempt to write to stout/sterr when they get a signal. This write will fail, and stupic applications catch this error and then attempt to write a diagnostic, which fails, so they catch this error and attempt to write a diagnostic, which fails, ...... Of course, none of _my_ programs have ever made that mistake..... Not. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message