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 INCLUDESINCLUDES = [......] -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:ganeshapache@xxxxxxxxx> 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, RobOn 9/7/06, Ben <ben@xxxxxxxxxxxxxx> 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: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|