151103 16:58:46 [ERROR] /usr/libexec/mysqld: Incorrect key file for table './smf209/smf209_sessions.MYI'; try to repair it
151103 16:58:46 [ERROR] Got error 127 when reading table './smf209/smf209_sessions'
my server died and when it came up, i had to restore the database from the most recent backup.
any thoughts on why this would happen ?
Looks like your sessions table crashed. You should be able to repair that table instead of having to do a backup.
These are pretty good articles for some more info-
http://themanbehindthecode.com/2011/08/06/mysqls-error-127-when-reading-table/
http://www.planetrubyonrails.org/60/got-error-127-when-reading-mysql-error-and-recovery
thanks, i will try that next instead of restoring the database, first.
... my logs aren't helping me at all so i have no idea why this all occurred in the first place.
Tables crash... It happens
There's always a reason ... I think something is causing a memory leak or monopolising the resources by an attack, a loop, a bug, hardware or god knows what.
my tech. buddy said to run "df -h" and "ps -ef" twice an hour - will do that via cron, despite the copious amount of emailed output.
do you even know what those commands do? running then in cron and not doing anything with the result will be useless.
actually running them in cron will just start a ton of processes and may never kill them off which is even worse then what you got going on right now.
if you dont know what to do with the output of those then it is useless to run those commands.
the reason this happened is in the first post you made here, the table got corrupted when the server died, it might have been writing to it when it went down.
nah, you have it all wrong: i want to see roughly when the *memory usage goes up.
i run the server and use cron for many smf related tasks.
i have a table crashing that i want to fix so i get the email to root of the cron output every 15 minutes (disk usage, free memory, all processes, and netstat -an for the ports).
i'm almost offended ... i think doing regular system checks is smart.
legend: * i suspect a memory related issue and wanted to be proved right or wrong. i think that something takes all the memory and Linux starts terminating processes to save itself, possibly the database thread currently addressing that table, for example ... the system eventually becomes unresponsive. 3 times in almost one year isn't bad but why not aim for 100% ?.
hell, it's my system and it only runs SMF mainly - i do as i please there.
come visit one day ... by clicking here (http://forum.drugs-and-users.org/)
And you are correct, you should monitor your system.
What (I think) Illori means is that you'll get a LOT of data. To analyze it properly will take an inordinate amount of time ;)
If this was the first time it happened, I'd suggest you leave it for now. If it happens again then yes, you should consider investigation.
BTW, "sessions" is probably the most used table in SMF but it stores no valuable information. So you don't need to restore the complete database. First try to repair it and, if it fails, just drop and recreate it. You can find the CREATE TABLE command in the install.sql file ;)
Quote from: margarett on November 09, 2015, 07:13:56 AM
<snip>
BTW, "sessions" is probably the most used table in SMF but it stores no valuable information. So you don't need to restore the complete database. First try to repair it and, if it fails, just drop and recreate it. You can find the CREATE TABLE command in the install.sql file ;)
Duly noted. it has happened 3 times in about a year. i figured that it was very high use BUT i have never tried to repair it or just DROP and reCREATE it ... yeah, of course, it's all in the unload (*.sql file) and i am familiar with that file, thankfully.
fabulous suggestion if the repair fails ... EDIT: Later, i have the table drop and create SQL commands built now. won't both to reload any data, as you suggested.
thanks.
i'm unemployed so my whole life's purpose is to get this forum humming.
will keep open until the next time the table crashes, i hope you don't mind
Quote from: aegersz on November 09, 2015, 07:28:02 AM
will keep open until the next time the table crashes, i hope you don't mind
if it only crashes a few times a year, it is not necessary to mark this as not solved. that means to the team that this issue has not been resolved... if it is not happening on a regular basis then it is technically resolved.
as you wish. i will reopen it if and when it happens and hopefully, be armed with more information.
all good.
Quote from: Illori on November 09, 2015, 05:21:12 AM
do you even know what those commands do? running then in cron and not doing anything with the result will be useless.
<snip>
you crack me up ... i am a guy who has worked in IT for 35+ years.
i code IBM 24 and 32 bit 370 Assembler plus i have held many Systems Programming (DOS/VM/MVS) jobs like when I personally rebuilt Citibank's Mainframe Systems in Australia and interconnected Asia via X25.
i think i can handle a few Linux commands :)
Please don't take it personal. It isn't ;)
We get a LOT of people who run their own servers/VPS and that have little to no experience in doing it. That's why we sometimes are a bit (too much?) defensive. My apologies if you were offended, it isn't our intention ;)
no harm done.
all good.
sorry for getting all defensive but i'm a bit sensitive because nobody wants to hire me ... so i work on my forum in a sort of volunteer.
thanks for the help, all the same.
I have setup scripts to repair or recreate the sessions table.
just one command should fix it.