ph10@??? said:
} But it sounds as though it could be done without the need for another
} database file, at least. The daemon already collects its child
} processes in order to implement the limit on total connections
} overall, so I don't think it would be a tremendously difficult thing
} to arrange.
I didn't think another db file was necessary or desirable. What you do
end up doing is storing state in the master daemon for each child
(including peer IP), and most likely at the point where you would fork (or
just after) wipping through your list of open connections and counting
occurrences of that peer IP. I think that other than for seriously large
systems (ones bigger than even I run) this would be as good a way as any
since you are only likely to be linearly searching a couple of hundred
entries - however first cut would show the efficiency hit and a
re-implementation could then be done if needed.
} Are you going to write code, or shall I put it on the Wish List?
Yes. [I'll look at coding this, but add it to the Wish List as a reminder
:-) ]
We are also seeing, particularly under these circumstances (huge hits
normally from one site) some processes hanging on read - I think the
problem is actually kernel related in that the alarm timeout is getting
lost but in theory a lot of signal stuff is unreliable. I was wondering
about changing the base read code for SMTP to use a select(),read() rather
than a alarm(),read() basis (or even use both together - however don't
some systems actually implement select using an alarm?? Any Unix varients
people here??)
Nigel.
--
[ Nigel.Metheringham@??? - Systems Software Engineer ]
[ Tel : +44 113 207 6112 Fax : +44 113 234 6065 ]
[ Real life is but a pale imitation of a Dilbert strip ]
--
*** Exim information can be found at
http://www.exim.org/ ***
