Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

1 votes

What's new in IP.Board 3.1.2? SQL Error Logging

Posted by Matt, 06 July 2010 · 2,672 views

IPBoard ipb 3.1.2

It's an unfortunate fact that something may go wrong with your hosting environment at some point. MySQL is sensitive to many things and often this results in an error being thrown. This can be confusing for you and your members and getting support for this can take time as our technicians often have to request FTP details so they can log in and check the error logs written to disk.

A lot of the time, our technicians discover that there isn't an issue with IP.Board but rather something has happened with your MySQL database or server. This can delay you getting your board back up.

With this in mind, IP.Board 3.1.2 separates out "server level" errors such as a crashed table, 'out of memory' issues and more into its own error page which is displayed.

Posted Image

This instantly informs you of the problem and directs you to contact your host or troubleshoot the issue further if you run a dedicated server.

In the Admin CP, we have written a log viewer which lists all the generated SQL error logs. It also keeps a record of the latest error of the day which is displayed above the list of logs.

Posted Image

Of course, these logs can get quite large, so when you view a log, it is "tailed" and only shows the most recent 300 lines.

Posted Image

We hope these features help speed up getting the correct support for when you need it most.

TheRevTastic

Jul 09 2010 01:46 AM

Yay, just what I needed, hate finding out its not ipb then taking longer to fix things.

Claudia999

Jul 09 2010 02:02 AM

Hey, that's fine! Can you now integrate an information per email if sql errors happen? I'm not always in the admin CP, but almost always reach via e-mail.

- estan, Haku2, inspire and 5 others like this

estan

Jul 09 2010 03:11 AM

Very Nice!

A very good idea would be to add an option for email notification as proposed by Claudia999. It would be nice if I could get an email every time when there is a critical error that completely stops my board from operation.

I do not check my forum so often but I always check my email.

Axel Wers

Jul 09 2010 03:14 AM

Cool. Now I have one suggestion

All these features and similar things about server, php, mysql, system diagnostics, error logging etc. could be under one table, because something is under System Tab, and other things are under Support tab.

Mark

Jul 09 2010 03:28 AM

Hey, that's fine! Can you now integrate an information per email if sql errors happen? I'm not always in the admin CP, but almost always reach via e-mail.

That isn't possible. If IP.Board cannot communicate with the database, it cannot retrieve your Email to notify you. In addition, even if your Email was written to a file somewhere, if your MySQL server went down, you'd suddenly get 1000s of EMails, which would also bring your mail serve down.

inspire

Jul 09 2010 04:32 AM

That isn't possible. If IP.Board cannot communicate with the database, it cannot retrieve your Email to notify you. In addition, even if your Email was written to a file somewhere, if your MySQL server went down, you'd suddenly get 1000s of EMails, which would also bring your mail serve down.

I don't see how it isn't, could you not have a simple text file in the cache folder which stores a timestamp of when the last SQL error alert email was sent and only send an email once every x amount of minutes? If the file isn't writable for some reason, don't send any emails. I'm sure the people who would like this feature wouldn't mind having an extra couple of optional settings in the initdata.php file.

pilotsnipes

Jul 09 2010 05:35 AM

I don't see how it isn't, could you not have a simple text file in the cache folder which stores a timestamp of when the last SQL error alert email was sent and only send an email once every x amount of minutes? If the file isn't writable for some reason, don't send any emails. I'm sure the people who would like this feature wouldn't mind having an extra couple of optional settings in the initdata.php file.

Yes I do this at the moment.

Whenever the board fails with a Mysql failure, I have a email address hard coded in the php code to send me a email informing me of the problem. The code also creates a yyyy-mm-dd.lck file so that when the next request comes in a few millisecs later from another user, the code looks to see if the lck file exists and if so will not send out any more emails to me.

The only downside is that if I forget to remove the lck file after I fix the problem and another error occurs THAT DAY, I won't be told about it. But come midnight we're good to go again even if I do forget....

Mark

Jul 09 2010 06:55 AM

I don't see how it isn't, could you not have a simple text file in the cache folder which stores a timestamp of when the last SQL error alert email was sent and only send an email once every x amount of minutes? If the file isn't writable for some reason, don't send any emails. I'm sure the people who would like this feature wouldn't mind having an extra couple of optional settings in the initdata.php file.

The issue is, we can't just stick

mail( $INFO['email'], "SQL Error", "An error was generated" );

in the file. It would have to be language abstracted (which would require the DB connection to fetch the language choice of the user receiving the Email) and would have to support both PHP mail and SMTP mail (which again requires a DB connection to fetch the current setting and the appropriate options surrounding it).

You are absolutely right, these things could be hardcoded in initdata.php, "impossible" was the wrong word to use, but it's something that's been discussed before and isn't as simple as one might initially think.

AtariAge

Jul 09 2010 07:42 AM

Nice additions, I remember discussing having an SQL log viewer within the ACP some time ago, great to see it become a reality!

Regarding the email suggestion--I do believe it is extremely worthwhile to have an emergency email address hardcoded somewhere so the (or an) Admin can be notified when a critical error occurs. I can't hover around my forum 24/7, and if my board goes down because the forum cannot connect to the database, I need to know immediately, since it sure isn't going to come back up on its own.

Thanks for your consideration,

..Al

Wolfie

Jul 09 2010 09:08 AM

The issue is, we can't just stick
mail( $INFO['email'], "SQL Error", "An error was generated" );
in the file. It would have to be language abstracted (which would require the DB connection to fetch the language choice of the user receiving the Email) and would have to support both PHP mail and SMTP mail (which again requires a DB connection to fetch the current setting and the appropriate options surrounding it).

You are absolutely right, these things could be hardcoded in initdata.php, "impossible" was the wrong word to use, but it's something that's been discussed before and isn't as simple as one might initially think.

What about it being put into conf_global.php, where there would be an emergency email address, the method to use to try to send it as well as the message to send (which would obviously be short and to the point)? Could be created during the initial install of the board and then if it needs to be changed, it just requires an edit of a file that wouldn't be overwritten by upgrades of IPB.

Rhuan

Jul 09 2010 11:24 AM

Great !!!

Luke

Jul 09 2010 01:54 PM

The language must be abstracted for sending an emergency email about a database error? One would think that the error message is generated by MySQL anyway... so it's not like you can do that anyway. Even if the admin's primary language isn't English, one would still appreciate the warning regardless. It's not like its' something the user or board admins would have to worry about... it would be for the sysadmin.

Mark

Jul 09 2010 03:05 PM

The language must be abstracted for sending an emergency email about a database error? One would think that the error message is generated by MySQL anyway... so it's not like you can do that anyway. Even if the admin's primary language isn't English, one would still appreciate the warning regardless. It's not like its' something the user or board admins would have to worry about... it would be for the sysadmin.

Of course it would. I mean like the Email subject and the message saying "Hey, your board is down, this is the MySQL error:". We can't hard-code English language strings.

AtariAge

Jul 09 2010 04:15 PM

Of course it would. I mean like the Email subject and the message saying "Hey, your board is down, this is the MySQL error:". We can't hard-code English language strings.

You were doing it for years in the ACP, I think an exception for an "emergency" situation like this is acceptable. It doesn't have to be anything more than, "IP.Board is unable to connect to the forum database, please check your server" or something equally as short. Put the text in the conf_global.php if you must give people a way of translating it (outside of directly modifying source files).

..Al

- estan likes this

Wolfie

Jul 09 2010 05:21 PM

At the risk of repeating myself, letting the person (during install) choose what message to send would probably be best. Perhaps have a few pre-translated versions of the same message in a drop down box, with an empty box so the admin could type their own message. Something short and to the point, so the admin could have it emailed to their cell phone if they want.

- Haku2 likes this

thompsone

Jul 10 2010 12:31 PM

The reporting tool is nice, thanks.

I would be a voice of a different opinion when it comes to the admin notification. I would not like it added.

There are plenty of NIX savvy ways to log and notify.

- Mark likes this

TCWT

Jul 10 2010 09:28 PM

Email notification would be nice.

- estan and Claudia999 like this

bfarber

Jul 12 2010 07:16 AM

Please post feature suggestions in the feedback forum. We don't routinely go to our blog entries to look for ideas while we're working on new releases.