Hi,
There is still a CPU hog. This is a different problem:
I'll send this message only once for now :). Sorry about the previous
problem.
#0 0x40101583 in chunk_free (ar_ptr=0x401b5300, p=0x8084168) at
malloc.c:3252
#1 0x401013f4 in __libc_free (mem=0x8084170) at malloc.c:3154
#2 0x40150a9
It looks like not all of the dbmail-* binaries are calling auth_connect().
Grepping for auth_connect yields this:
injector.c: if (db_connect() != 0 || auth_connect() != 0)
smtp-convert.c: if (db_connect() != 0 || auth_connect() != 0)
user.c: if (auth_connect()==-1)
vut2dbmail.c: if (auth_conne
Hi Aaron,
due to some integration problems we removed the seperate authentication
support for the 1.0 release - that is, only one database connection is
created. Some code needs to be added to make this fully transparent in
a way that given a compiler option the build is for a separate databas
Hi,
I'm trying to compile dbmail on a RH 8 box.
I've run build.sh and compilation went smoothly till the following line.
config.o -L/usr/lib/mysql -I/usr/include/mysql/ -lmysqlclient
user.c: In function `cget_salt':
user.c:698: warning: implicit declaration of function `getpid'
Is there somethin
Should I get together a patch for you?
It would seem to require only a minimal change to auth_connect() in both
dbauthmysql.c and dbauthpgsql.c so that if USE_SAME_CONNECTION is defined,
the function will simply return true, since db_connect() already set up
that connection! Once this is cleared,
I have a possible thing to check for, by the way -- I found that if a
process does not success with it's db_connect() call, it will die and be
respawned in a *tight* loop until it does finally return true from
db_connect(). So perhaps some people could trace their dbmail issue to a
lack of open con
