The following reply was made to PR general/1787; it has been noted by GNATS.
From: Matt Braithwaite <[EMAIL PROTECTED]>
To: Dean Gaudet <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: general/1787: accept loops on ENOTSOCK, filling up logfile
Date: 12 Feb 1998 13:13:35 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
>>>>> "DG" == Dean Gaudet <[EMAIL PROTECTED]> writes:
DG> On 10 Feb 1998, Matt Braithwaite wrote:
>> in these tickets you have been able to suggest specific fixes
>> that go to the root of the problem. however, i think this loop
>> could be more defensive, given that the case of accept or
>> select getting stuck on a particular error seems not entirely
>> uncommon. one possibility: count failed accept()s against the
>> maximum number of connections permitted for a child process, so
>> that in conditions like this the logs won't fill up
DG> Interesting idea... 'cept I tend to run servers with
DG> MaxRequestsPerChild 100000.
yeah, but 100000 * (100 * sizeof(char)) == 10,000,000, which is
*still* a lot better than filling up the disk. :-)
DG> I think what I'll try to do is figure out what accept
DG> responses are expected and make the rest die immediately. In
DG> many of these cases the child is just useless at that point.
that sounds good. since it can never *hurt*, it seems best to err on
the side of having the child exit when it doesn't know how to
interpret something.
if you feel like sending us a patch, that would just be super. :-)
have you any ideas on how the ENOTSOCK occurs in the first place? i
still have no ideas about this. it's important to me, because one
thing i do not know, which it is very important to me to know, is
whether the accept(2) error is being simultaneously encountered and
logged by all children, or just by one. if the former, the root
problem cannot be fixed just by having the children encountering the
error exit.
DG> Oh yeah your note about possibly missing SIGUSR1 -- it
DG> shouldn't matter because there is a generation check against
DG> the scoreboard to make sure the generation hasn't changed.
sorry, i don't know what you mean by ``generation''.
- --
Matthew Braithwaite <[EMAIL PROTECTED]>
A-Link Network Services, Inc. 408.720.6161 http://www.alink.net/
Alors, � ma beaut�! dites � la vermine / Qui vous mangera de baisers,
Qui j'ai gard� la forme et l'essence divine / De mes amours d�compos�s!
---Baudelaire
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNONl/J6nR3MdS46dAQGpngQAmdBdQlIoiS3j7KeOpRxH7GXtzIfSr+HA
I9r9jWC5novCXe6YeuKmHivB1U/X3omcOqTZ07HB7vOJTXvt0V4jQRvAK5TuCSY9
6dGyQu65zFkI6+C4t4y7awUtdT+zTOKWJOFk1wmhEHCbNpA1t4sHAA/1GubreV3+
CYn9JVtpYXQ=
=inev
-----END PGP SIGNATURE-----
