cannot fork: Resource temporarily unavailable
Mike Halliday
Resource temporarily unavailable" in the log.
Is this something we should worry about?
Does sendmail recover elegantly (queue the message). Or could a
partial message go out?
Are we short of paging space?
Should we throttle the daemon to prevent this from ocurring?
--
Mike Halliday <fly...@watson.ibm.com>
Neil Rickert
>When sendmail 8.8.7 gets real busy, we sometimes see "cannot fork:
>Resource temporarily unavailable" in the log.
> Is this something we should worry about?
It is not good news.
> Does sendmail recover elegantly (queue the message). Or could a
>partial message go out?
Either the message is queued, or it is not received at all, so that the
sending system should retry later.
> Are we short of paging space?
Probably. However, sendmail is memory hungry.
> Should we throttle the daemon to prevent this from ocurring?
I run my daemon with '-bd -odq -q5m' so that mail is initially
queued, and only delivered on queue runs. That reduces the number of
concurrent sendmail processes, both because there is less fork()ing
in the queue run, and because the queue run serializes a lot of the
work. I also limit the max number of concurrent incoming connections
with the MaxDaemonChildren option.
cor gest jr
>When sendmail 8.8.7 gets real busy, we sometimes see "cannot fork:
>Resource temporarily unavailable" in the log.
> Is this something we should worry about?
> Does sendmail recover elegantly (queue the message). Or could a
>partial message go out?
> Are we short of paging space?
> Should we throttle the daemon to prevent this from ocurring?
>
>--
>Mike Halliday <fly...@watson.ibm.com>
If you have the hardware resources available you could change the
options of:
#O QueueLA
#O RefuseLA
#O MaxDemonChildren
#O ConnectionRateThrottle
settings in your sendmail.cf
But be carefull, it is possible to overload the system.
cor
--
Do not get dumbed down by unintelligible binaries
There is a solution
LINUX and X11
http://www.knoware.nl/users/ccgestjr/index.html