Thanks, Jesse,
- here is the /etc/syslog.conf (stripped of comments):
==============================================
*.err;kern.*;auth.*;*debug;mail.*;*.warning /var/log/console.log
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.* /var/log/security
auth.info;authpriv.info /var/log/auth.log
mail.info /var/log/maillog
lpr.info /var/log/lpd-errs
cron.* /var/log/cron
*.emerg /var/log/emerg.log
*.warning /var/log/warn.log
console.* /var/log/console.log
!startslip
*.* /var/log/slip.log
!ppp
*.* /var/log/ppp.log
==================================================================
Note that almost *nothing* should be going to the console... not even
kernel messages... (server is normally unattended..).
And all the /var/log<whatever> files exist, are owned by root:wheel, and
chmod'ed to 600.
The *real* problem (source of the messages) seems to be that DBMail's
daemons, dbmail-imapd and dbmail-pop3d go into runaway when they are
invoked. Error messages indicate they create all their authorized quota
of child processes before (or while) connecting to the DB. Not clear if
the first connection succeeeds, but the second and subsequent surely
fail with:
PQconnectdb failed: FATAL: Sorry, too many clients already
Thereafter, we get:
PQconnectdb failed: FATAL: Non-superuser connection limit exceeded
- So far, in dbmail.conf, I have backed down the number of processes and
children permitted to ONE, but each failure is 'FATAL' and spawns a new
one anyway, and does not always get the zombies cleared out (though a
killall <daemon-name> does do so - after a pause).
There *were* bugs discussed in this area of DBMail that consumed 100% of
CPU resources, BUT, IIRC they were allegedly fixed months ago (at least
w/r MySQL <G>). Maybe not w/r pgsql?
FWIW, dbmail-smtp works fine to the postgreSQL DB, so I am off to
compare source code in search of "MySQL'ism's" ...
Regards,
Bill
Jesse Norell wrote:
Hello,
Dbmail logs via syslog, and you can adjust the verbosity
of what it logs in dbmail.conf. Probably your syslogd is
setup to print messages on the console or to some tty, which
is usually set in /etc/syslogd.conf (but if your don't find
anything there, check the manpage for your syslogd server).
If you can't figure out how to get it setup the way you want,
post back with the contents of your syslog.conf (you can strip
all commented lines if you want), and describe what you want
it to do/not do, and we can probably help get you going.
jn
---- Original Message ----
From: Bill Hacker <dbmail-dev@dbmail.org>
To: dbmail-dev@dbmail.org
Subject: [Dbmail-dev] Console Messages
Sent: Sun, 30 Nov 2003 17:25:58 +0800
Odd one here:
I have (AFAIK) all err, warning, emerg, debug, and such messages that
would ordinarily be thrown onto the console redirected in syslogd to
various /var/log<files> ...which I can then 'tail -f' in a separate
login console... Handy..
But - invoking a daemon on as-yet-not-fully-configured installation, to
wit: dbmail-pop3d or dbmail-imapd - results in an error condition
(which is not what I am posting about - the *error condition* and its
'warning' messages are quite legitimate at this stage...)
What escapes me is that these error message still appear on the console.
It would appear that syslogd is not being used, *but*....
I do not see anything in dbmail.conf that specifies either syslog or
any
other method of logging.
Q: Where should I look, and/or is this a compile-time option that
cannot
be changed at runtime?
Bill Hacker
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
-- End Original Message --
--
Jesse Norell
jesse (at) kci.net
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
