Skip site navigation (1)Skip section navigation (2)
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>