Rob, Ganesh
I think that Ganesh was confusing perl DBD for apr-DBD.
We don't use Perl on our systems.
Rob, as you correctly guessed, I didn't do something different from
the first build.
However I was pretty surprised that it built and worked the second
time round - my guess is that there were some old apr libraries or
mysql libraries that were being linked to, or something like that.
Because I use a custom directory for the install (in order to
seperate concerns - /usr/local is far too busy for my liking ) I had
to change ld.so.conf to include
/opt/httpd/lib
/opt/httpd/apr/lib
/opt/httpd/apr-util/lib
(and run ldconfig again, of course)
Are you building APR seperately? I just gave up on that, and went to
build it as a part of the overall package.
Having said all that, I didn't get the message "Internal error: DBD:
Can't connect to mysql", which is generated at line 293 (mod_dbd.c),
which is pretty meaningless, as it is invoked by a APR_EGENERAL -
defined as a "Generic Error which can not be put into another
spot" (basically, the software is saying "I dunno, some error
occured after I called apr_dbd_open" ).
There are two points in apr_dbd_open (srclib/apr-util/dbd/apr_dbd.c)
which generate that error (nothing like ambiguity, eh?) Now the right
thing to do would be to generate the correct errors, and then report
them correctly, so the following may help to work out what is going
on (it looks like the problem isn't vanishing) - I use the httpd
errors, which i am sure will piss the apr dev off - so it needs apr-
izing to be done properly..
Modify srclib/apr-util/Makefile to include the apache-httpd
includes.. (this is to get errors out to the log):
Add the two directories to INCLUDES
INCLUDES = [......] -I(FULL PATH TO YOUR SOURCE DIRECTORY)/
httpd-2.2.3/os/unix -I(FULL PATH TO YOUR SOURCE DIRECTORY)/
httpd-2.2.3/include -I/opt/include
Add the three lines to both srclib/apr-util/dbd/apr_dbd.c and srclib/
apr-util/dbd/apr_dbd_mysql.c
#include "http_protocol.h"
#include "http_config.h"
#include "http_log.h"
Add the error message in srclib/apr-util/dbd/apr_dbd.c (around line
165) in apr_dbd_open :
[...]
*handle = driver->open(pool, params);
if (*handle == NULL) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, NULL, "apr_dbd_driver_t
handle is NULL. Driver open failed with params %s",params);
return APR_DBD_VALUE_NULL;
/*
maybe this is an erroneous use of the error - in fact, we
could avoid the apache merge shenanigans above by returning this
value and catching it in mod_dbd.c
*/
}
Also, add an error message in srclib/apr-util/dbd/apr_dbd_mysql.c
(dbd_mysql_check_conn, around line 740 ) - actually, better to
rewrite the function altogether (though possibly not in a manner that
assumes you are using it for httpd... )
static apr_status_t dbd_mysql_check_conn(apr_pool_t *pool, apr_dbd_t
*handle) {
unsigned int mysql_err = mysql_ping(handle->conn);
apr_status_t result = APR_EGENERAL;
switch (mysql_err) {
case 0: result = APR_SUCCESS; break;
case CR_COMMANDS_OUT_OF_SYNC: {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, NULL, "mysqlping
failed with COMMANDS_OUT_OF_SYNC during dbd_mysql_check_conn");
} break;
case CR_SERVER_GONE_ERROR: {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, NULL, "mysqlping
failed with SERVER_GONE_ERROR during dbd_mysql_check_conn");
} break;
case CR_UNKNOWN_ERROR: {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, NULL, "mysqlping
failed with UNKNOWN_ERROR during dbd_mysql_check_conn");
} break;
default: {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, NULL, "mysqlping
failed with an unknown error %d during dbd_mysql_check_conn",
mysql_err);
} break;
}
return result;
}
I don't know if it is worth it to you, but it may help to narrow the
issue down a bit.
If you have success, or failure with revised errors as above, let me
know ...
The latter amend highlights an interesting point of ignorance for me.
It should be possible to refer to the logging engine directly,
without having to go through the httpd protocols - this is necessary
if we wish to keep local issues local (ie, be able to report reliably
on 3rd party returns, such as the mysql errors) - but add them to the
current logging environment. I am unaware of the specific
relationship between the logging environment and httpd. Of course, if
httpd owns the logging environment, then we have to either accomodate
different drivers within the httpd layer or pass a meaningful error
string (and code) back to the engine. I am sure Nick or one of the
others would know how to implement this change in a manner which
keeps the concerns of apr-util and httpd separate.
Ben.
ganesh ganesh <mailto:[EMAIL PROTECTED]> wrote:
Also check with the following perl module presence:
DBD::mysql, Bundle::DBD::mysql, Bundle::DBI, DBI, DBI::DBD
What Ben describes in his email is almost the same as what I did last
and this time. He said he got it working after a new build (not saying
if he did something different so I guess he didn't), but here I can't
get it to work by just rebuilding everything (again).
Gr,
Rob
On 9/7/06, Ben <[EMAIL PROTECTED]> wrote:
I include a step-by-step install of A223/Mysql 5024 with DBD in the
articles called:
"A NetHack-esque Journey of the dark arts for DBD(mysql) under
httpd-2.2.3" - posted 20 August on this maillist - it may be
relevant or interesting to you.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
