Eloy Lafuente (stronk7)
added a comment - 30/Mar/08 6:47 AM Hi Farouk,
is this an error in some of the moodle.org sites? Or in your own server?
If it's in your server I'd suggest you to take a look to disk space (perhaps it's really full). Else, try to repair the log table in your DB, you can do it from phpMyAdmin.
Hope this helps, closing as "not a bug". Ciao

Eloy Lafuente (stronk7)
added a comment - 15/Apr/08 9:13 AM Reopening and adding some people here.
This is the improvement that added the "disk full" emails. MDL-11893
I would suggest to limit the number of emails (1/day...) and... also... to add the log record information to the message, in order to see what's causing the error on insert and fix it.
Feel free to comment....
Ciao
P.S.: Anyway Manish, I really think that this issue in the logs cannot cause the quiz problem you comment at all ( http://moodle.org/mod/forum/discuss.php?d=94934 ). 99% they are different things.

Martin Dougiamas
added a comment - 15/Apr/08 10:05 AM Let's use the original bug to talk about the log issue, I'll reopen it.
My GUESS is that this issue a temporary problem on that server which has now caused permanent errors in the table that need repairing.

Martin, yesterday I repaired database using cPanel operation. After that also I got the email, "Insert into log table failed at Tuesday 15th of April 2008 01:12:57 AM. It is possible that your disk is full."

Eloy, the problems related to quiz remain and the reason of correlating the two is that there were no issues with quiz earlier and the problems have cropped up later and if you look at my post you would notice some zeroes in the screenshot which I guess are not usual in the table.

Manish Verma
added a comment - 15/Apr/08 1:22 PM Martin, yesterday I repaired database using cPanel operation. After that also I got the email, "Insert into log table failed at Tuesday 15th of April 2008 01:12:57 AM. It is possible that your disk is full."
Eloy, the problems related to quiz remain and the reason of correlating the two is that there were no issues with quiz earlier and the problems have cropped up later and if you look at my post you would notice some zeroes in the screenshot which I guess are not usual in the table.

we have just send to CVS some changes to logs (MDL-11893) in order to:

only be notified once per day.

in the notification get the database statement that caused the problem.

So, if you can update your site in 24 hours... hopefully some error will happen again and then, if you share the problematic statement here... we'll be able to try to fix it. TIA!

About the quiz problem... I really think they are unrelated (at least I cannot imagine any relation until we get the information above, to see if the problems in logs are happening when logging some quiz operations).

Anyway, I'd suggest you to:

Create one new bug in the tracker (quiz related), giving as much info as possible and pointing to the discussion in moodle.org forums.

Link the discussion back to the new bug in the tracker.

That way, quiz maintainer (Tim Hunt) will be able to suggest you things / request more information and detect where is the problem.

Eloy Lafuente (stronk7)
added a comment - 16/Apr/08 5:15 AM Hi Manish,
we have just send to CVS some changes to logs ( MDL-11893 ) in order to:
only be notified once per day.
in the notification get the database statement that caused the problem.
So, if you can update your site in 24 hours... hopefully some error will happen again and then, if you share the problematic statement here... we'll be able to try to fix it. TIA!
About the quiz problem... I really think they are unrelated (at least I cannot imagine any relation until we get the information above, to see if the problems in logs are happening when logging some quiz operations).
Anyway, I'd suggest you to:
Create one new bug in the tracker (quiz related), giving as much info as possible and pointing to the discussion in moodle.org forums.
Link the discussion back to the new bug in the tracker.
That way, quiz maintainer (Tim Hunt) will be able to suggest you things / request more information and detect where is the problem.
Thanks a lot! Ciao

So... next step should be about to examine MySQL logs to see if something is being notified there when your logs fail to be inserted.

I really cannot imagine any reason for this failing randomly. Perhaps some buggy MySQL version could be the problem? Or so very-very busy server? Only that and table needing repair/optimise are my ideas.

Eloy Lafuente (stronk7)
added a comment - 19/Apr/08 1:29 AM Hi Manish,
and did you received those emails from the same server? Strange, because one of the things implemented is about to receive only ONE notification per day. Uhm...
Anyway, the offending SQL statement looks really perfect (no strange chars, correct numbers...). I've executed here manually and there isn't any problem with it.
So... next step should be about to examine MySQL logs to see if something is being notified there when your logs fail to be inserted.
I really cannot imagine any reason for this failing randomly. Perhaps some buggy MySQL version could be the problem? Or so very-very busy server? Only that and table needing repair/optimise are my ideas.
Ciao

I have not received that email since last 4 days. When I got most of those emails it appeared to be a very busy period for the server. There was an event and a very large number of users were accessing the site.

Now, how a busy server is linked to that message would be interesting to understand.

Manish Verma
added a comment - 26/Apr/08 2:38 PM Hi Eloy,
I have not received that email since last 4 days. When I got most of those emails it appeared to be a very busy period for the server. There was an event and a very large number of users were accessing the site.
Now, how a busy server is linked to that message would be interesting to understand.

Uhm... perhaps under high load, your MySQL server rejects some connections and that's the ultimate cause for that message? Or the log table is practically locked due to high concurrence or some timeouts happen?

I would suggest to:

1) Analyse and optimise your database from time to time (it's a heavy operation, so it's recommended to perform it when the server is idle).
2) Test if MySQL concurrent-inserts can give you a benefit (http://dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html). I've some servers with that variable set to 2 and seems to make a good job, alleviating things under high concurrence. Not 100% guaranteed, but could be a thing to explore.

I'm going to close this because seems to be some problem in your end... feel free to continue commenting here if you need anything else.

Eloy Lafuente (stronk7)
added a comment - 28/Apr/08 6:44 AM Uhm... perhaps under high load, your MySQL server rejects some connections and that's the ultimate cause for that message? Or the log table is practically locked due to high concurrence or some timeouts happen?
I would suggest to:
1) Analyse and optimise your database from time to time (it's a heavy operation, so it's recommended to perform it when the server is idle).
2) Test if MySQL concurrent-inserts can give you a benefit ( http://dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html ). I've some servers with that variable set to 2 and seems to make a good job, alleviating things under high concurrence. Not 100% guaranteed, but could be a thing to explore.
I'm going to close this because seems to be some problem in your end... feel free to continue commenting here if you need anything else.
Ciao

Martin Dougiamas
added a comment - 01/Jul/08 11:27 PM This isn't a Moodle bug, Matthew, it's some MySQL administration issue, so it shouldn't be here in the tracker.
However, some discussion about how to detect/fix the actual problem could be useful in the moodle.org forums
eg http://moodle.org/mod/forum/view.php?id=596

The SQL fails because it is an invalid SQL statement. The course field is set to blank. It should be a numeric value and MySQL is smart enough to know that it is a number even though it has ' ' around it...but since it is blank it mismatches the field type. I don't see how this is anything but a Moodle problem.

Matthew Davidson
added a comment - 02/Jul/08 9:35 PM Martin,
The SQL fails because it is an invalid SQL statement. The course field is set to blank. It should be a numeric value and MySQL is smart enough to know that it is a number even though it has ' ' around it...but since it is blank it mismatches the field type. I don't see how this is anything but a Moodle problem.

Stuart Chapman
added a comment - 02/Sep/08 8:04 PM We are having the same issue and there are no errors in the MySQL log.
Would it be possible to add the error message the server returns when the query is executed to the e-mail? This would certainly help narrow down the cause of the problem.
The site load at the time was minimal (two actions in the same minute the log insert failed) so it appears that isn't the issue for us.

Martin Dougiamas
added a comment - 17/Sep/08 1:10 PM - edited Petr and Eloy, is there any way (in Moodle code) we can find out more details about the problem when it happens so we can give users more accurate feedback?

1) Dump the stack trace to know which script was the original caller of the add_to_log() call. That will help to know the originator of problems like the blank course commented by Matthew above.
2) Try to capture the error from the DB backend. It can show the final cause of the INSERT being rejected.

Eloy Lafuente (stronk7)
added a comment - 18/Sep/08 4:30 PM Well,
I can see two ways to complete the information, adding these:
1) Dump the stack trace to know which script was the original caller of the add_to_log() call. That will help to know the originator of problems like the blank course commented by Matthew above.
2) Try to capture the error from the DB backend. It can show the final cause of the INSERT being rejected.
Ciao

MyISAM table with dynamic (variable length) rows, the index file for the table (tablename.MYI) stores row locations using 32-bit pointers into the data file (tablename.MYD). That means it can address only 4GB of space.

For a long time 4GB was an entire hard disk and most operating systems had trouble with files larger than 2GB, so when MySQL designed their engine they didnt

think for a while that there will be someone who will use that much of storage or at least reach millions of records in his table :s

from my point of view; the 32-bit pointer is ideal becasue most people are running MySQL on 32-bit hardware (Intel/Linux), hence, the 32-bit pointer is most efficient way to do this on 32-bit hardware.

okay okay.. I know I talked so much.. but how to overcome this problem? and enlarge the limit or 4 GB?

here we go,
we need first to show the table status by executing:

MYSQL>show table status like 'mdl_log' \G
then in the result set you will find Max_data_length: 4294967295 (4 GB).

Amr Hourani
added a comment - 25/Oct/08 12:42 AM The fact that MySQL has a 4GB limit..
MyISAM table with dynamic (variable length) rows, the index file for the table (tablename.MYI) stores row locations using 32-bit pointers into the data file (tablename.MYD). That means it can address only 4GB of space.
For a long time 4GB was an entire hard disk and most operating systems had trouble with files larger than 2GB, so when MySQL designed their engine they didnt
think for a while that there will be someone who will use that much of storage or at least reach millions of records in his table :s
from my point of view; the 32-bit pointer is ideal becasue most people are running MySQL on 32-bit hardware (Intel/Linux), hence, the 32-bit pointer is most efficient way to do this on 32-bit hardware.
okay okay.. I know I talked so much.. but how to overcome this problem? and enlarge the limit or 4 GB?
here we go,
we need first to show the table status by executing:
MYSQL>show table status like 'mdl_log' \G
then in the result set you will find Max_data_length: 4294967295 (4 GB).
To change the 4 GB, just execute
MYSQL>alter table mdl_log max_rows = 200000000000 avg_row_length = 50;
now you are done, but notice that the alter statement may take long time.
another note that if you are using 64-bit machine you will not need to execute the alter statement becasue the installation of mysql will increase the max_data_length accordingly.
cheers..
Amr Hourani!

David Mudrak
added a comment - 14/Apr/09 4:47 AM I have got the same issue with one of my installation. I am getting approximately one such email per week. The server is not mine (commercial webhosting) so I can't provide more information right now.

This problem seems to have been around a long while (March 08), I'm not a programmer so I am not much use to the dev team but I thought this description may help.
This error has only become apparent for us since we upgraded the Moodle version three weeks ago. We have had an increasing number of students using the system but we are not a large site compared with some (< 100 students on at any one time).
We have the same 'INSERT INTO' messages as noted above.
We have noticed that the error happens when the front page partially loads, left column and centre column load but right column is not present and centre column spreads across to right of the browser window - as you'd expect. The browser then waits for the remainder of the page to load but it doesn't.

At the same time one of the server CPUs hits 100% utilisation. The only way to get out of the situation is to stop the MySql server and then restart it. Apache then sends its error message "INSERT INTO" etc to our admin email address.

This is happening many times a day - probably 10 times yesterday. We are constantly resetting MYSQL just to keep classes running.

We have updated to the latest release Moodle 1.9.5+ (Build: 20090729)
We are at Mysql community version 5.1.36
We are running PHP 5.2.5 and about to try 5.2.10

Our Mysql runs two installations of moodle (one configured as a staff portal and one for students) - I hope this helps - I will butt out now let the real guru's get on with the job - Thanks to all.

Alex Delaforce
added a comment - 31/Jul/09 7:28 AM This problem seems to have been around a long while (March 08), I'm not a programmer so I am not much use to the dev team but I thought this description may help.
This error has only become apparent for us since we upgraded the Moodle version three weeks ago. We have had an increasing number of students using the system but we are not a large site compared with some (< 100 students on at any one time).
We have the same 'INSERT INTO' messages as noted above.
We have noticed that the error happens when the front page partially loads, left column and centre column load but right column is not present and centre column spreads across to right of the browser window - as you'd expect. The browser then waits for the remainder of the page to load but it doesn't.
At the same time one of the server CPUs hits 100% utilisation. The only way to get out of the situation is to stop the MySql server and then restart it. Apache then sends its error message "INSERT INTO" etc to our admin email address.
This is happening many times a day - probably 10 times yesterday. We are constantly resetting MYSQL just to keep classes running.
We have updated to the latest release Moodle 1.9.5+ (Build: 20090729)
We are at Mysql community version 5.1.36
We are running PHP 5.2.5 and about to try 5.2.10
Our Mysql runs two installations of moodle (one configured as a staff portal and one for students) - I hope this helps - I will butt out now let the real guru's get on with the job - Thanks to all.

Whenever an error happens, report the whole error trace and the sql error, instead of only reporting the insert command, just to see if there is some "wrong" insert somewhere (to fix cases like the one commented by Matthew Davidson above) and what exact type of error is happening in the DB.

But really we cannot do too much else if the insert query is ok (like all cases above but the Matthew one) and the DB is giving errors.

Eloy Lafuente (stronk7)
added a comment - 06/Oct/09 4:17 AM Hi Gaurav,
as commented above we cannot really do much here but:
Test if MySQL concurrent-inserts can give you a benefit ( http://dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html ). I've some servers with that variable set to 2 and seems to make a good job, alleviating things under high concurrence. Not 100% guaranteed, but could be a thing to explore.
Whenever an error happens, report the whole error trace and the sql error, instead of only reporting the insert command, just to see if there is some "wrong" insert somewhere (to fix cases like the one commented by Matthew Davidson above) and what exact type of error is happening in the DB.
But really we cannot do too much else if the insert query is ok (like all cases above but the Matthew one) and the DB is giving errors.

I think it's the fact that, in the m_log table, all the fields have a 'NOT NULL' constraint, and SQL statements like yours (and some I've seen on our system) try to put the empty string (i.e. '') into one of the fields (like the 'url' field in the SQL statement in your example). Our Moodle administrator contacted me with a similar example, but in our case, the empty string was for the 'action' field.

Perhaps it would be enough to take the 'NOT NULL' constraint off a few of those fields (at least the 'action' and 'url' fields)? Can anyone reading this think of anything in Moodle 1.9.5+ that would break if some of the fields in records in the log table were empty?

Guy Waugh
added a comment - 30/Oct/09 9:47 PM Brad, I'm getting the same thing with our Moodle 1.9.5+ and Oracle 10g installation.
I think it's the fact that, in the m_log table, all the fields have a 'NOT NULL' constraint, and SQL statements like yours (and some I've seen on our system) try to put the empty string (i.e. '') into one of the fields (like the 'url' field in the SQL statement in your example). Our Moodle administrator contacted me with a similar example, but in our case, the empty string was for the 'action' field.
Perhaps it would be enough to take the 'NOT NULL' constraint off a few of those fields (at least the 'action' and 'url' fields)? Can anyone reading this think of anything in Moodle 1.9.5+ that would break if some of the fields in records in the log table were empty?
Cheers,
Guy.

Eloy Lafuente (stronk7)
added a comment - 30/Oct/09 11:58 PM Hi Brad, Guy... your problem is a different one caused by moodle trying to insert '' (empty char) in that tables. Oracle assumes empty = null. It's a well-know problem we have already handled in other places. I'm going to fix that, plz, don't change table/field specs.
This bug remains open since ages because of MySQL prone to fail inserting records from time to time and we haven't found any cause in Moodle, but some ideas to avoid that concurrence of workaround it.
So, for the Oracle problem... fixing/testing now... I'll keep you informed. Ciao

We are getting this error as well on 1.9.6 running MySQL 5. Here are several messages we've received over the last couple weeks. All of the SQL executes when I run it manually, so it seems to be valid SQL.

We are getting this error as well on 1.9.6 running MySQL 5. Here are several messages we've received over the last couple weeks. All of the SQL executes when I run it manually, so it seems to be valid SQL.

I'm seeing the same error, with near identical SQL INSERT statements under Moodle 1.9.7+ MySQl 5. The database checks out ok. We started seeing these errors after we installed Moodle 1.9.7 and moved the Moodle database to a dedicated MySQL server (separate from the Moodle server). Based on our monitoring, we don't think this is a load issue; the alerts are sent infrequently and at all hours; the last one was at midnight.

We've increased our MySQL log level to see if we can get any more details on this error.

Kenneth Newquist
added a comment - 20/Jan/10 6:33 PM I'm seeing the same error, with near identical SQL INSERT statements under Moodle 1.9.7+ MySQl 5. The database checks out ok. We started seeing these errors after we installed Moodle 1.9.7 and moved the Moodle database to a dedicated MySQL server (separate from the Moodle server). Based on our monitoring, we don't think this is a load issue; the alerts are sent infrequently and at all hours; the last one was at midnight.
We've increased our MySQL log level to see if we can get any more details on this error.

if they are "incorrect" insert sqls, then we can fix them. If they are correct sqls, then all we can do is to blame MySQL, or recommend ppl to switch from MyISAM (table locks) to InnoDB (row locks, plus a lot of nice extras like proper isolation, transactions...).

Eloy Lafuente (stronk7)
added a comment - 20/Jan/10 9:22 PM Thanks!
if they are "incorrect" insert sqls, then we can fix them. If they are correct sqls, then all we can do is to blame MySQL, or recommend ppl to switch from MyISAM (table locks) to InnoDB (row locks, plus a lot of nice extras like proper isolation, transactions...).
Ciao

Nacho - It helps to know more about your server (OS, database and version, PHP version, etc.). Initially I like to ensure that it is not related to any database corruption so I would check the tables. Let me know if I can be of help to you in tracking this down. Peace - Anthony

Anthony Borrow
added a comment - 04/Nov/10 1:21 AM Nacho - It helps to know more about your server (OS, database and version, PHP version, etc.). Initially I like to ensure that it is not related to any database corruption so I would check the tables. Let me know if I can be of help to you in tracking this down. Peace - Anthony

During testing of upgrade to Moodle 2.0 RC2+, I noticed insert error to log table during quiz attempt (debugging was on). In RC2+ database table, "mdl_log", the field, "action" was showing, "varchar(15)" which I changed to, "varchar(40)" from phpMyAdmin. That stopped showing the insert error. Perhaps these two issues are related. If you are getting those emails frequently, perhaps you could test this with your database copy in a test installation using copy of moodle data folder if you are running perhaps Moodle 1.6.x or later (reference, http://tracker.moodle.org/browse/MDL-25297) if the original entry was indeed, "varchar(15)" in the concerned area of your database.

Manish Verma
added a comment - 19/Nov/10 3:30 PM During testing of upgrade to Moodle 2.0 RC2+, I noticed insert error to log table during quiz attempt (debugging was on). In RC2+ database table, "mdl_log", the field, "action" was showing, "varchar(15)" which I changed to, "varchar(40)" from phpMyAdmin. That stopped showing the insert error. Perhaps these two issues are related. If you are getting those emails frequently, perhaps you could test this with your database copy in a test installation using copy of moodle data folder if you are running perhaps Moodle 1.6.x or later (reference, http://tracker.moodle.org/browse/MDL-25297 ) if the original entry was indeed, "varchar(15)" in the concerned area of your database.

Daniel Neis
added a comment - 22/Nov/10 9:28 PM The MDL-25297 seems unrelated to me, because all errors reported here have very short "action" values (up to 10 characters).
I still think it is a MyISAM concurrent insert problem...

Yes, i also think that the problem is related to Mysql being "stressed" by another long query.

Thinking of Eloy Lafuente (stronk7) message from 20/janv./10 09:22 PM, is there a good documentation about switching from MyISAM to InnoDB ?http://docs.moodle.org/en/admin/innodb needs to be completed...

Séverin Terrier
added a comment - 22/Nov/10 10:42 PM Yes, i also think that the problem is related to Mysql being "stressed" by another long query.
Thinking of Eloy Lafuente (stronk7) message from 20/janv./10 09:22 PM, is there a good documentation about switching from MyISAM to InnoDB ?
http://docs.moodle.org/en/admin/innodb needs to be completed...

Daniel Neis
added a comment - 23/Nov/10 7:46 PM There will be a webinar from Percona about migrating myisam to innodb
http://www.percona.com/webinars/2010-12-01-migrating-myisam-innodb/
At Universidade Federal de Santa Catarina, we are planning this migration so i hope to contribute with moodle's documentation on this kind of migration in the near future.

akfoote
added a comment - 01/Dec/10 10:26 PM this issue is nearly 2.5 years old now..
If your serving more than 10 people on your moodle and your not running on InnoDB tables then you need to switch. regardless of what moodle version your using.
Eloy said this already 20/Jan/2010

I'm going to resolve this as Won't Fix, as far as there is nothing in Moodle that can be done for this. After re-reading the whole thread, here it is the summary, for further reference:

Problems in some (old, upgraded) sites having the log->action column being varchar(15) when it should be varchar(40). Solution: change the length to 40, also see MDL-24088 for fix incoming for Moodle 2.0.1

Random and continuos problems not caused by the above log->action incorrect length. If you are using MySQL, switch to InnoDB storage (http://docs.moodle.org/en/admin/innodb). It has been proved to be the only solution in busy sites.

Problems with some (constant) insertion. If you detect that the problem is caused always by the same action, then report it as separate issue. Surely there is one bug in one call to add_to_log().

And that's all. I think the 3 points above summarize the whole thing...ciao

Eloy Lafuente (stronk7)
added a comment - 01/Dec/10 11:30 PM - edited Hi guys,
I'm going to resolve this as Won't Fix, as far as there is nothing in Moodle that can be done for this. After re-reading the whole thread, here it is the summary, for further reference:
Problems in some (old, upgraded) sites having the log->action column being varchar(15) when it should be varchar(40). Solution: change the length to 40, also see MDL-24088 for fix incoming for Moodle 2.0.1
Random and continuos problems not caused by the above log->action incorrect length. If you are using MySQL, switch to InnoDB storage ( http://docs.moodle.org/en/admin/innodb ). It has been proved to be the only solution in busy sites.
Problems with some (constant) insertion. If you detect that the problem is caused always by the same action, then report it as separate issue. Surely there is one bug in one call to add_to_log().
And that's all. I think the 3 points above summarize the whole thing...ciao
Edited: They were 3 points, not 4, fixed. lol.

Ryan Smith
added a comment - 10/Jan/11 9:39 PM We are still using MyISAM, but changing varchar(15) to varchar(40) fixed the error for us. I haven't seen the error for over a month since fixing the database.

We have also been having this issue. From my investigations, I believe the problem is related to php/mysql interaction, rather than just a mysql issue. The reason is as follows:

we wanted to make sure that the data was logged in the log table, so we wrote a .net web service that would perform the insert when the regular insert function failed. We added a web service call immediately after the insert into log call; if the insert fails using the regular function, we then call the web service, using the exact same SQL statement! The .net service is able to successfully make the entry when the php call fails. So, if we're able to write to the log table using .net, then it means that there's an issue with php.

One thing we did notice is that all the failed calls - as far as we can tell - appear to be exclusively related to the scorm/view entries. Of course, because we haven't received any emails for failed entries in other tables doesn't necessarily mean that there are not other failures out there, but I can tell you that entering courses, scorm pre-views, viewing forums, etc.. are all being logged properly (eg, no insert fail messages).

Kim Halat
added a comment - 29/Jun/11 9:22 PM Hello all,
We have also been having this issue. From my investigations, I believe the problem is related to php/mysql interaction, rather than just a mysql issue. The reason is as follows:
we wanted to make sure that the data was logged in the log table, so we wrote a .net web service that would perform the insert when the regular insert function failed. We added a web service call immediately after the insert into log call; if the insert fails using the regular function, we then call the web service, using the exact same SQL statement! The .net service is able to successfully make the entry when the php call fails. So, if we're able to write to the log table using .net, then it means that there's an issue with php.
One thing we did notice is that all the failed calls - as far as we can tell - appear to be exclusively related to the scorm/view entries. Of course, because we haven't received any emails for failed entries in other tables doesn't necessarily mean that there are not other failures out there, but I can tell you that entering courses, scorm pre-views, viewing forums, etc.. are all being logged properly (eg, no insert fail messages).
So, I'm pointing the figure to php... The mystery is why...
Kim