This error caused an email to bounce (during the reading of the .forward file).
Here are the sendmail logs:
Nov 8 11:41:33 pita sm-mta[733]: libnss-mysql: mysql_store_result failed: Lost connection to MySQL server during query
Nov 8 11:41:33 pita sm-mta[733]: lA8JfXrC000730: to=\\khawe.example.com, ctladdr=<khawe@example.com> (2069/900), delay=00:00:00, mailer=local, pri=120415, dsn=5.1.1, stat=User unknown
I was using FreeBSD 6.2 and MySQL 4.1. This morning I upgraded to MySQL 5.0 to see if that helps (I am planning on the 5.1 upgrade next week if all is fine with 5.0 on my system).
*** Has anyone seen this error before? What is it?
*** How can it be avoided? (any my.cnf tunings?)
I read on the forums that lost connection errors are OK as libnss reconnects to MySQL automatically... here is the type of error logged in that case:
libnss-mysql: mysql_query failed: Lost connection to MySQL server during query, trying again (2)
*** Feature request: make the libnss-mysql retry on other errors, not just reconnect errors.
Thanks in advance, Do appreciate the libnss module,
Rudy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This will cause a retry if mysql_store_result returns NULL. This patch compiles, but is still being tested -- The error condition occurs only once or twice a day, so I have to wait to see if it works as expected.
--- src/mysql.c.orig Sat Sep 3 20:34:02 2005
+++ src/mysql.c Sat Nov 10 12:06:13 2007
@@ -302,9 +302,20 @@
In previous versions I had this whole fancy retry mechanism, including trying other MySQL servers, but it was rife with bugs so I killed it in favor of the simplicity of a simple single attempt; this problem is exacerbated by the fact that in between the first and second attempts, the socket could be invalidated due to a fork by the calling process (albeit that would be extraordinarily rare -- but it would cause a crash, so I don't want to assume otherwise).
If I go back into the code and create a new release, I'll likely code handling specific errors and retrying failed requests. For example, I don't want to retry in the case of a server unavailable which could cause huge auth delays .. but I would want to retry in the case you raise here. It's a hairy situation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been using libnss for years and love it.
This error caused an email to bounce (during the reading of the .forward file).
Here are the sendmail logs:
Nov 8 11:41:33 pita sm-mta[733]: libnss-mysql: mysql_store_result failed: Lost connection to MySQL server during query
Nov 8 11:41:33 pita sm-mta[733]: lA8JfXrC000730: to=\\khawe.example.com, ctladdr=<khawe@example.com> (2069/900), delay=00:00:00, mailer=local, pri=120415, dsn=5.1.1, stat=User unknown
I was using FreeBSD 6.2 and MySQL 4.1. This morning I upgraded to MySQL 5.0 to see if that helps (I am planning on the 5.1 upgrade next week if all is fine with 5.0 on my system).
*** Has anyone seen this error before? What is it?
*** How can it be avoided? (any my.cnf tunings?)
I read on the forums that lost connection errors are OK as libnss reconnects to MySQL automatically... here is the type of error logged in that case:
libnss-mysql: mysql_query failed: Lost connection to MySQL server during query, trying again (2)
*** Feature request: make the libnss-mysql retry on other errors, not just reconnect errors.
Thanks in advance, Do appreciate the libnss module,
Rudy
Here is the exact error I am finding:
http://dev.mysql.com/doc/refman/5.0/en/null-mysql-store-result.html
phew! OK, made a patch. Will post once tested.
This will cause a retry if mysql_store_result returns NULL. This patch compiles, but is still being tested -- The error condition occurs only once or twice a day, so I have to wait to see if it works as expected.
--- src/mysql.c.orig Sat Sep 3 20:34:02 2005
+++ src/mysql.c Sat Nov 10 12:06:13 2007
@@ -302,9 +302,20 @@
if ((*mresult = mysql_store_result (&ci.link)) == NULL)
{
- _nss_mysql_log (LOG_ALERT, "mysql_store_result failed: %s",
- mysql_error (&ci.link));
- DSRETURN (NSS_UNAVAIL);
+ --(*attempts);
+ if (*attempts > 0)
+ {
+ _nss_mysql_log (LOG_ALERT,
+ "mysql_store_result failed: %s, tries remaining: %d",
+ mysql_error (&ci.link), *attempts);
+ DSRETURN (_nss_mysql_run_query (query, mresult, attempts));
+ }
+ else
+ {
+ _nss_mysql_log (LOG_ALERT, "mysql_store_result failed: %s",
+ mysql_error (&ci.link));
+ DSRETURN (NSS_UNAVAIL);
+ }
}
DSRETURN (NSS_SUCCESS)
}
In previous versions I had this whole fancy retry mechanism, including trying other MySQL servers, but it was rife with bugs so I killed it in favor of the simplicity of a simple single attempt; this problem is exacerbated by the fact that in between the first and second attempts, the socket could be invalidated due to a fork by the calling process (albeit that would be extraordinarily rare -- but it would cause a crash, so I don't want to assume otherwise).
If I go back into the code and create a new release, I'll likely code handling specific errors and retrying failed requests. For example, I don't want to retry in the case of a server unavailable which could cause huge auth delays .. but I would want to retry in the case you raise here. It's a hairy situation.