On 08/01/2010 08:12 PM, Lou Picciano wrote: > Hello Paul! > > We've had a few communication disconnects re dbmail, such as when I've > quoted what I assumed would be 'authoritative' information on dbmail: > Is the wiki not the place to look for accurate, timely info on dbmail?
The wiki may or may not be accurate. The README.* docs and the manpages are! > > One example: Parts of the available docs refer to placing the conf file > at /etc/dbmail.conf; I've also heard it suggested that this location is > 'old school' - old school, as in 'deprecated'? Yet, our builds seem to > find the dbmail.conf file in /etc... (?) That's a configure-able option. /etc/dbmail.conf is the default. Debian and derivatives prefer /etc/dbmail/dbmail.conf. Ymmv, stylistic matter. > > Another is my referencing bugfixes to the 2.2 branch on that wiki: > http://www.dbmail.org/dokuwiki/doku.php/2.2 - which talk about > 'segfaulting' fixes being applied some time ago... Ah, that page is outdated! Not-maintained, etc. Use the GIT logs for real updates. > > I've also used SQL queries and other config info on this page - verbatim > - in setting up our server, so am relying on the > wiki: http://www.dbmail.org/dokuwiki/doku.php/setup_postfix That page looks a lot like README.postfix. I'm not familiar with postfix/postgresql maps myself, but have used mysql in the past and still use ldap maps extensively. Getting the maps right is a separate topic, and should be keeps apart of the matter of the daemons running normally. > > Unfortunately, we _cannot_ build the documentation from source, as we > don't have (is it asciidoc, docbook?) implementation on Solaris. We > have been building with the --disable-manual setting. IS THERE a > fully-built version of the docs somewhere, or can someone simply zip it > to an archive for us? We don't want to spend the time on a side project > - asciidoc configuration? - just to get a copy of dbmail docs. Ahem, they are ASCIIdocs for a reason: they are human readable and editable. Try reading them! > > As to version we are building: > > # git branch -v > * dbmail_2_2 793da8e massive speedup in imap-append Ok. Just fine and dandy. > Here is the entire output of the dbmail-lmtpd command, including segfault: > > # dbmail-lmtpd -D > pool...c,statefile_create(+666): Creating scoreboard at > [/var/run/dbmail-lmtpd.state]. > Segmentation Fault (core dumped) Not good! Is that what happens when you run the normal daemonizing mode? > > This run does write the following to /var/log/dbmail.err (but we have > /_never_/ seen any output to dbmail.log): > > Aug 01 12:01:46 leeloo [3170]: Debug:[server] > server.c,server_daemonize(+238): sid: [3169] > Aug 01 12:01:46 leeloo [3170]: Debug:[server] > pool.c,statefile_create(+666): Creating scoreboard at > [/var/run/dbmail-lmtpd.state]. > > We do have ALL of the debuggers on in the dbmail and ALL of the daemon > sections of the dbmail.conf file. > > TRACE_LEVEL = 5 > TRACE_STDERR = 5 > TRACE_SYSLOG = 5 All generate the same output. The first is deprecated, equals the third option. The second appends the log lines to the error log, the third option sends it to the syslog facility. Can you run the command through gdb? (That's what the -D switch is for). A backtrace would really be helpful. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
