Re: [users@httpd] Apache 2.2.3 and MySQL 5.0.24a

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rob, (Nick)

I have been looking a little more at the issue of returning meaningful error messages back to apache - i didn't like my previous mail's hijacking of apache as a solution - though it should provide an idea of what is going on. So now the implementation looks like. Rob, sorry - this should be a better way of doing exactly what my previous mail suggested - (caveat - I have built these, but not run them - the production machine is live)! However, we now have kept httpd separate from apr and so we don't need to mess with the includes and so on.

In srclib/apr-util/dbd/apr_dbd_mysql.c - rewrite dbd_mysql_check_conn, around line 740
--------------
static apr_status_t dbd_mysql_check_conn(apr_pool_t *pool, apr_dbd_t *handle) {
unsigned int mysql_err_num = mysql_ping(handle->conn);
if (mysql_err_num == 0) {
        return APR_SUCCESS;
} else {
return APR_OS_START_USERERR + mysql_err_num; /* we could also remove the CR_MIN_ERROR offset... */
}
}

--------------
Also in srclib/apr-util/dbd/apr_dbd_mysql.c - rewrite dbd_mysql_error, around line 240
--------------
static const char *dbd_mysql_error(apr_dbd_t *sql, int n) {
  const char *mysql_error_msg_string =  mysql_error(sql->conn);
     if (mysql_error_msg_string != NULL) {
          return mysql_error_msg_string;
     } else {
          switch (n) {
          case 0: return mysql_error_msg_string;
case CR_COMMANDS_OUT_OF_SYNC: return "mysql error COMMANDS_OUT_OF_SYNC"; case CR_SERVER_GONE_ERROR: return "mysql error SERVER_GONE_ERROR";
           case CR_UNKNOWN_ERROR: return "mysql error UNKNOWN_ERROR ";
/* add a whole load of other mysql errors here see mysql file errmsg.h */
          default: return "unspecified mysql error";
        }
     }
}
--------------
So we need to change return value of the apr_dbd_open function in srclib/apr-util/dbd/apr_dbd.c line 170. - The API is open regarding errors (lucky us) so rather than blanking the error out with a GEN, we can return rv
Change:
    if ((rv != APR_SUCCESS) && (rv != APR_ENOTIMPL)) {
        apr_dbd_close(driver, *handle);
        return APR_EGENERAL;
    }

To:
--------------
    if ((rv != APR_SUCCESS) && (rv != APR_ENOTIMPL)) {
        apr_dbd_close(driver, *handle);
        return rv;
    }
--------------
And finally we can change mod_dbd.c (modules/database/mod_dbd.c) around line 288
--------------
if (rec->driver == NULL) { ap_log_perror(APLOG_MARK, APLOG_CRIT, rv, rec->pool,"DBD: mod_dbd received a NULL when calling apr_dbd_get_driver for %s",svr->name); } rv = apr_dbd_open(rec->driver, rec->pool, svr->params, &rec- >handle); if (rec->driver == NULL) { ap_log_perror(APLOG_MARK, APLOG_CRIT, rv, rec->pool,"DBD: mod_dbd received a NULL when calling apr_dbd_get_driver for %s",svr->name); } rv = apr_dbd_open(rec->driver, rec->pool, svr->params, &rec- >handle);
    switch (rv) {
     case APR_SUCCESS: {
ap_log_perror(APLOG_MARK, APLOG_DEBUG, rv, rec->pool, "DBD: % s driver is successfully opened and connected", svr->name);
     } break;
     case APR_ENOTIMPL: {
ap_log_perror(APLOG_MARK, APLOG_CRIT, rv, rec->pool, "DBD: Can't connect to %s Not Implemented.", svr->name);
        return APR_ENOTIMPL;
     } break;
     default: {
const char *errmsg = apr_dbd_error(rec->driver, rec->handle, rv - APR_OS_START_USERERR); ap_log_perror(APLOG_MARK, APLOG_CRIT, rv, rec->pool,"DBD: Can't connect to %s - ", svr->name, (errmsg ? errmsg : "no reason given"));
        return APR_EGENERAL;
     } break;
    }
--------------
Nick, in modules/database/mod_dbd.c, just before we call apr_dbd_open is there any reason why not to check that rec->driver is not NULL ? The previous error management code only evaluates return values, and it seems possible to me that apr_dbd_get_driver can actually return a NULL driver without returning an error code to match. I am unsure as to whether or not the (rec->driver == NULL) test line is redundant.

Another challenge is how to pass the error result from mysql_ping (called in dbd_mysql_check_conn) over to dbd_mysql_error. I am not impressed with merely discarding it!! As the error is internal to mysql, it doesn't feel correct to be returned by apr_dbd_open, but we do have APR_OS_START_USERERR so I used that - is there a better way? Now we are handling any messages correctly, through the apr_dbd_error function, and we know that rec->driver is not null.

Of course the code above does a good deal more than merely deal with connection issues - it demonstrates how to use mysql error reporting from mod_dbd in a consistent manner. The significant change is making use of the mysql error numbers and returning them in APR_OS_START_USERERR space.

Hoping these mails are helping someone!
	-b



---------------------------------------------------------------------
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



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux