Date: Thu, 20 May 1999 10:44:03 +1000 From: Gregory Bond <gnb@itga.com.au> To: Dan Nelson <dnelson@emsphone.com> Cc: Andre Rikkert de Koe <arikkert@surf.IAE.nl>, freebsd-bugs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: timeconsuming processes on FreeBSD 3.1 Message-ID: <199905200044.KAA14033@lightning.itga.com.au> In-Reply-To: Your message of Wed, 19 May 1999 11:22:02 -0500.
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905200044.KAA14033>