I wrote about MySQL Error Messages before and as you might guess I’m not very happy with quality for error messages it produces. Now I’m revisiting this subject with couple of more annoying examples I ran into during last couple of days.
|
1 2 |
mysql> drop database test; ERROR 1010 (HY000): Error dropping database (can't rmdir './test/', errno: 17) |
First question you should ask is what is error 17 ? Do to this you can run external utility perror:
|
1 2 |
[pz@test ~]$ perror 17 OS error code 17: File exists |
It would be already a lot handy if one would walk through all error messages where error code is used and add the text description right into the code. ERROR 1010 (HY000): Error dropping database (can’t rmdir ‘./test/’, errno: 17 “File exists”) would already be a lot more helpful.
If you’re wondering why this could happen, the answer is you may get some extra files, which do not belong to MySQL in database directory. MySQL will only remove files it knows about such as “.frm” or “.MYI” when it is dropping the database, if you get something else, such as .sql file containing the dump of this database you will not be able to drop it until you remove this file manually.
Another enjoyable error message: “Can’t find messagefile ‘/usr/share/mysql/english/errmsg.sys”
Everything is good and clear right ? Nope !
|
1 2 |
root@ubuntu:/root/mysql55# ls -la /usr/share/mysql/english/errmsg.sys -rw-r--r-- 1 root root 41949 2011-04-03 08:05 /usr/share/mysql/english/errmsg.sys |
The file does exist so “can’t find messagefile” error message is misleading to say the least. The error can’t open file would be much more appropriate here and error code (better with description) would be great.
What is the problem in this case ? It is SELinux denying permission to this file as can be seen from “dmesg”
|
1 |
[364985.160766] type=1503 audit(1302058460.527:360): operation="open" pid=331 parent=32631 profile="/usr/sbin/mysqld" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/usr/share/mysql/english/errmsg.sys" |
The bad error reporting has an interesting property – you do not care as you do not see those error frequently, but when you do, especially if you’re under the time pressure, bad error reporting really hurts.
I wish Oracle would invest some time fixing those errors. No complicated code required and I bet this could be a great project for some Intern to complete over summer. Why do I point finger to Oracle you would ask, why do not we just fix it in Percona Server ? We could but because there are a lot of simple changes needed, plus many of message files would need to be corrected to include the place
to provide error description in addition to error code, this would make our merge process a lot more complicated, so it is a lot better if it is fixed in upstream.
