Page 1 of 1
SQL warnings after move
Posted: Thu Jun 26, 2008 10:18 pm
by macavenger
I am running Serendipity 1.3.1 on a Mac OS X 10.4.11 box with a MySQL database back-end. I have serendipity set up, and it has been functioning correctly for some time. Due to a lack of the necessary processing power to run the MySQL server on my primary machine, however, I recently moved the MySQL server to another machine, and updated the serendipity database settings to point to the new location. Everything still appears to be functioning (I can view posts, make new posts, etc) EXCEPT that now I keep getting messages like the following:
Code: Select all
Warning: mysql_query() [function.mysql-query]: Unable to save result set in /WebServer/Documents/include/db/mysql.inc.php on line 84
I found another thread here, with the suggestion of contacting their administrator, and suggesting that the database server is running out of disk space. However, unless this is a permissions issue (as far as I can tell, those didn't change), that can not be the case here- there is 211 GB of free space on the drive I put the SQL server on, with no restrictions, and even the serendipity drive has 20 GB of free space. Additionally, I AM my administrator, so it wouldn't make much sense for me to contact me
So might someone have an idea of how to fix this problem? As mentioned, it doesn't appear to affect functioning, but it is rather annoying. Thanks![/code]
Additional Info
Posted: Thu Jun 26, 2008 11:53 pm
by macavenger
Looks like it isn't quite working properly everywhere- the "Manage Styles" link in serendipity admin doesn't work any more. As far as I can tell, however, everything else does work. Additionally, I am getting a few more error messages, such as:
Code: Select all
Warning: Cannot modify header information - headers already sent by (output started at /WebServer/Documents/include/db/mysql.inc.php:84) in /WebServer/Documents/serendipity_admin.php on line 11
and on the login page:
Code: Select all
Warning: session_regenerate_id() [function.session-regenerate-id]: Cannot regenerate session id - headers already sent in /WebServer/Documents/include/functions_config.inc.php on line 352
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /WebServer/Documents/include/db/mysql.inc.php:84) in /WebServer/Documents/include/functions_config.inc.php on line 353
Warning: Cannot modify header information - headers already sent by (output started at /WebServer/Documents/include/db/mysql.inc.php:84) in /WebServer/Documents/include/functions_config.inc.php on line 649
Warning: Cannot modify header information - headers already sent by (output started at /WebServer/Documents/include/db/mysql.inc.php:84) in /WebServer/Documents/include/functions_config.inc.php on line 649
(yes, that last line is repeated). So what on earth did I mess up here? And how can I fix it? Thanks.[/code]
Re: Additional Info
Posted: Fri Jun 27, 2008 8:36 am
by garvinhicking
Hi!
This "unable to save result set" usually only happens when a link to the database broke down. It can be network issues, or the MySQL server itself is malfunctioning. Please check the mysql error logs and thoroughly check your network connection to the MySQL server.
HTH,
Garvin
Posted: Fri Jun 27, 2008 9:15 pm
by macavenger
If only it was that easy. The two machines are directly connected via ethernet through a switch, and the errors occur only is specific locations. In this scenario, I would think it rather unlikely that there is a connection problem (unless I have an ethernet port or cable going bad or the like), and if so, I would think it would be more random. And yet, the bulk of the data (all the articles, pictures, etc) transfer just fine. I only get the errors at very specific locations. Additionally, my SQL error logs show no errors at all- just entries for when I last restarted the computer.
If there were connection problems, either with the physical connection or with the Sql server itself, wouldn't you expect to see problems throughout serendipity, such as when trying to create or access articles? What's different about the SQL connections it makes to draw the header or access the manage styles link than when creating a new article or going to any other section of the configuration?
What exactly are the scripts trying to do at the lines referenced? Specifically in the header of the admin screen or login screens? I looked at them, but there are so many variables I was unable to figure out the program flow.
I could see perhaps my not having set up the serendipity user quite right on the new server, so it can't write to somewhere it needs to. I set up the user with a "GRANT ALL on serendipity.* to
serendipity@xx.xx.xx.xx IDENTIFIED BY 'xxxxx'", Should that give all the permissions needed? Thanks again.
Posted: Fri Jun 27, 2008 11:04 pm
by macavenger
Ok, fixed the problem, at least for the SQL errors I was getting. I just needed to run the myisamchk -r command. Apparently something got messed up in the move of the database. HOWEVER, I still can't access the "Manage Styles" link from the admin screen. Whenever I try the browser thinks for a while and then gives me a "server is not responding" error- even when I am on the local machine, and the web server is running fine. Perhaps this is an unrelated problem though? I don't know if it started at the same time, as I haven't tried to access that page in a while.
Posted: Sat Jun 28, 2008 11:10 am
by garvinhicking
Hi!
As for manage styles, it could be a spartacus problem. Either try to disable spartacus, or try to investigate the Apache error logs to look out for CGI errors, timeouts?
Regards
Garvin
Sparticus
Posted: Sat Jun 28, 2008 8:14 pm
by macavenger
Yep, looks like sparticus was the culprit. Turned it off, and the styles page loaded right up. Thanks! Of course, that does lead to the next logical question: why isn't sparticus working, and how do I fix it?
Never mind...
Posted: Sat Jun 28, 2008 8:37 pm
by macavenger
Never mind, I figured it out. My blog has been receiving a hellacious amount of trackback spam over the past few weeks, so in a somewhat successful attempt to limit it, I had been blocking such hosts from accessing my site (I really don't get much valid traffic, so if I blocked a few valid ip's in the process it doesn't really matter much). Apparently I got a little overzealous, however, and managed to block sparticus
. I have since gone back and simply set the spam plugin to reject a lot more of the trackbacks it gets, so hopefully that will work better.