Add a few missing <application> elements and replace a 'funny' instance

of <application>sendmails</application> with a slightly reworded version
which avoids putting an 's' in the SGML element; it's not part of
Sendmail's name.

Noticed by:	ganbold at micom dot mng dot net
This commit is contained in:
Giorgos Keramidas 2006-12-12 04:26:01 +00:00
parent 2d3e7b7941
commit 2174b30c4a
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=29224

View file

@ -793,20 +793,20 @@
<para><application>Sendmail</application> has its
<option>-OMaxDaemonChildren</option> option, which tends to work
much better than trying to use sendmail's load limiting options
much better than trying to use <application>Sendmail</application>'s load limiting options
due to the load lag. You should specify a
<literal>MaxDaemonChildren</literal> parameter, when you start
<application>sendmail</application>, high enough to handle your
<application>sendmail</application>; high enough to handle your
expected load, but not so high that the computer cannot handle that
number of <application>sendmails</application> without falling on
its face. It is also prudent to run sendmail in queued mode
number of <application>Sendmail</application> instances without falling on
its face. It is also prudent to run <application>Sendmail</application> in queued mode
(<option>-ODeliveryMode=queued</option>) and to run the daemon
(<command>sendmail -bd</command>) separate from the queue-runs
(<command>sendmail -q15m</command>). If you still want real-time
delivery you can run the queue at a much lower interval, such as
<option>-q1m</option>, but be sure to specify a reasonable
<literal>MaxDaemonChildren</literal> option for
<emphasis>that</emphasis> sendmail to prevent cascade failures.</para>
<emphasis>that</emphasis> <application>Sendmail</application> to prevent cascade failures.</para>
<para><application>Syslogd</application> can be attacked directly
and it is strongly recommended that you use the <option>-s</option>