Wietse:
I have not made any changes to rsyslog.conf. All it does it redirect all
mail log messages to one log in /var/log/mail which I rotate with a cron
script nightly. However, I do agree that it really could be the only other
process that could be hanging the server.
I'm not able to determine what program is consuming the CPU because I can't
login to the console when this occurs. The only way I can recover the
machine is by forcibly powering off.
# /etc/rsyslog.conf Configuration file for rsyslog.
#
# For more information see
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html
#################
#### MODULES ####
#################
module(load="imuxsock") # provides support for local system logging
module(load="imklog") # provides kernel logging support
#module(load="immark") # provides --MARK-- message capability
# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")
# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")
###########################
#### GLOBAL DIRECTIVES ####
###########################
#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog
#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
###############
#### RULES ####
###############
#
# First some standard log files. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail/mail.log
user.* -/var/log/user.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
#mail.info -/var/log/mail.info
#mail.warn -/var/log/mail.warn
#mail.err /var/log/mail.err
#
# Some "catch-all" log files.
#
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
#
# Emergencies are sent to everybody logged in.
#
*.emerg :omusrmsg:*
On Fri, Jan 19, 2018 at 1:20 PM, Wietse Venema <wie...@porcupine.org> wrote:
> Zach Sheppard:
> > However, whenever Postfix gets a large e-mail load it processes the
> e-mails
> > for around 30-45 minutes and then consistently uses around 70-80% of the
> > CPU effectively locking up the entire system so much so that I can't even
> > login and debug without either disabling the network card in VMWare or
> > rebooting the system totally. The VM has 2 CPU cores and 4GB RAM
> allocated
> > to it which I thought was plenty for this application.
>
> Did you determine out WHAT PROGRAM is consuming CPU? As Postfix is
> totally I/O limited, I suspect that there may be some other system
> component that is messing up.
>
> For example, it is well known that one badly configured syslog
> service can use up lots more CPU than all of Postfix combined.
>
> Wietse
>
--
This message may contain confidential information and is intended only for
the individuals named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.
