Date: Thu, 15 Feb 2007 16:56:14 -0800 From: Chuck Swiger <cswiger@mac.com> Cc: freebsd-isp@freebsd.org, Roldan Vallejo Olivera <roldan@transnet.cu> Subject: Re: problems with KAV for FreeBSD 6.0 Message-ID: <552B7B1A-D7D4-43DD-A75C-252665E5D6B0@mac.com> In-Reply-To: <20070215230722.GA27427@dwpc.dwlabs.ca> References: <001701c75133$e1cb0870$dd64000a@transnet.cu> <20070215230722.GA27427@dwpc.dwlabs.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 15, 2007 at 02:02:47PM -0500, Roldan Vallejo Olivera wrote:
> hello list:
> I have a FreeBSD 6.0 running in an HP Proliant GL 370, Dual Xeon
> 3.2 GHz,
> 1GB RAM, and RAID-5 75 GB, in this system we have a BIND DNS
> service and a
> Sendmail as a mail relay-only server, processing an average of 3GB
> messages
> daily, we have purchased a KAV license for 4 GB traffic daily, but
> we are
> having problems: sometimes our server runs out of resources and
> issues the
> following message error:
> "maxproc limit exceeded by uid 0, please see tuning(7) and
> login.conf(5)
> ns1 sendmail[545] syserr (root): <mailbox@mydomain.com> openmailer
> (smtpscanner): cannot fork: resource temporarily unavailable no queue:
> syserr(root): daemon: cannot fork"
>
> at this moment when I try to login at the server i receive this error:
> "login: login: fork: resource temporarily unavailable"
>
> the server replies at ping command, but doesn't allow telnet
> neither ssh,
> and stops processing messages.
This sort of problem can happen when someone mailbombs your MTA,
causing it to fork excessive numbers of children. It could also
happen if your anti-spam/virus-scanning stuff ends up getting stuck
and leaving frozen processes around.
Consider adjusting this:
# maximum number of children we allow at one time
#O MaxDaemonChildren=0
...in your sendmail configuration to a reasonable value, based on how
many other processes are running and how big your process table is
("sysctl kern.maxproc"?)
If that doesn't solve your issue, perhaps you should set up a cron
job to periodically put the output of "ps aux" into a text file, and
remain logged into the machine. When you fill up the process table,
try to check this file, otherwise check it promptly after a reboot if
you have to do that, and see which processes are filling up the
system and/or getting stuck.
> we have noticed this scenario runs out of
> free memory as we read the output of top command:
It's not directly related; FreeBSD will happily use almost all RAM
simply for (inactive) page caching, and this is normal and does not
indicate a problem. However, if you encounter excessive swapping
activity, it's possible that you'll end up with lots of processes
starting up but not being able to complete their work and exit, which
would cause the system to fall over as described above.
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?552B7B1A-D7D4-43DD-A75C-252665E5D6B0>
