Bug #6334 | Flush Privileges causes Hang | ||
---|---|---|---|
Submitted: | 29 Oct 2004 23:36 | Modified: | 16 Dec 2004 9:44 |
Reporter: | Erik Perrohe | Email Updates: | |
Status: | No Feedback | Impact on me: | |
Category: | MySQL Server | Severity: | S3 (Non-critical) |
Version: | 4.1.3-beta | OS: | Linux (Linux/Fedora Core 1) |
Assigned to: | CPU Architecture: | Any |
[29 Oct 2004 23:36]
Erik Perrohe
[30 Oct 2004 16:06]
MySQL Verification Team
First of all, your defaults file would be needed to repeat a bug. Second, do we truly need to install entire Wikipedia or similar large sofware in order to reproduce a bug with privilege tables ??
[11 Nov 2004 13:12]
Erik Perrohe
Q: do we truly need to install entire Wikipedia or similar large sofware in order to reproduce a bug with privilege tables ?? A: No, I said that this would be the easiest way to recreate the environment. Not the required way. I think if you just enter the privlegs tables as they appear in the bug... they are in dump file format... or a stripped down version... that you should be able to repro. I am pretty sure the key to this bug is to have an unresolvable domain in the user table. But I just don't have time available to test all these possibilities. ----- Q: First of all, your defaults file would be needed to repeat a bug A: My config file is mostly empty... but here it is... [mysqld] open-files-limit=30000 delayed_insert_timeout=60 max_delayed_threads=20 max_allowed_packet=10000000 [safe_mysqld] [mysql] [mysqladmin]
[15 Nov 2004 14:10]
Marko Mäkelä
Erik, the excerpt "InnoDB: Unable to lock ./ibdata1, error: 11InnoDB: Error in opening ./ibdata1 041029 13:24:43 InnoDB: Operating system error number 11 in a file operation. InnoDB: Error number 11 means 'Resource temporarily unavailable'." indicates that you were probably running two instances of mysqld on the same InnoDB tablespace. It doesn't indicate any corruption - the advisory file locking was introduced in order to avoid corruption.
[15 Nov 2004 22:58]
Erik Perrohe
This server is running multiple copies of mysqld. But each has a different port and socket and of course a different db. The database does not even contain any innodb tables, other then those that mysqld insists upon automatically generating. As a result of this bug, the mysqld did have a catastrophic shutdown which would have left the advisory lock file behind. The innodb messages sound pretty dire, glad to know all it's complaining about is a lock file. A search of the docs did not reveal any apparent way to manually repair a corrupt innodb (myisamcheck equivlent); apparently it is just never supposed to need repair??? I was not able to make the innodb error message go away... and mysqld refused to start, I found nothing in the docs about repairing this innodb problem. since the innodb tables were empty I resorted to deleting them. Now I know that all I have to do is delete the Lock file, what is the name of this file? How about documenting this? If I had actually been using innodb tables, and in my search of repair howtos, not finding any docs about the lockfile, I would have been up the creek without a paddle.
[15 Nov 2004 23:07]
Erik Perrohe
Whooaa How Can You Say this is Not A Bug??!!! The Bug being reported here is a Hang/Crash of mysqld because of an unresolvable host name in the User Table. Under no circuimstances should doing a Flush Privileges cause a crash, but it does, and that is the primary issue of this bug. The rest is just documenting what happened after the crash. The fact that the innodb lock file prevented being able to restart mysqld after the crash is a "side show" and is worthy of a seperate bug in it's own right.
[15 Nov 2004 23:14]
Erik Perrohe
I can reproduce this crash/hang 100% of the time on my server. And in fact must be very careful to avoid causing it to happen. Doing a Flush Privileges with an unresolvable Host name should be considered a normal use scenario. There is no way to guarantee that a host will always be resolvable. If needed, I will happily arrange for a dev to have access to my server.
[16 Nov 2004 9:44]
Marko Mäkelä
I wouldn't say "not a bug", but we need a reduced, repeatable test case, e.g., commands to type in the mysql client in order to get the crash on a freshly installed mysqld. Maybe you should enable the query log in order to see the statements your application is trying to execute. At startup, InnoDB tries to acquire locks on the contents of the data files. There's no separate data file. If any of the data files have been locked by some process (typically mysqld), InnoDB refuses to start. Have you checked with "ps ax" or "ps -fe" that no instance of mysqld is running? When mysqld terminates abnormally, some threads could be left running. I don't think that the InnoDB file locking is relevant to this bug report.
[14 Feb 2005 22:54]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".