SQL warnings after move

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

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

[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

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

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

[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

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

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