Description:
I recently had a hard time tracking why my MySQL service would not start after upgrading to the latest version.
To try and correct the problem, I uninstalled the old version, rebooted, deleted C:\Program Files\MySQL\*, also D:\MySQL Datafiles\* and re-installed. The error was still there.
The Windows Event Viewer's application log described the problem as :
C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld-nt: Got signal 11. Aborting!
As you can hopefully imagine this wasn't particularly helpful !
How to repeat:
create my.ini file in C:\WINDOWS with bad datadir and basedir definitions.
Install MySQL server.
Service will fail to start with error "C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld-nt: Got signal 11. Aborting!"
Suggested fix:
After a while I traced the problem back to a rogue my.ini file in the C:\WINDOWS directory, which was previously one of the advertised ways to configure MySQL before the excellent gui version was around. I had forgotten all about it.
I discovered this by starting the server from the console with --console. I was surprised when the error referred to share\english\errormsg.sys inside a directory which no longer existed. I rebuilt the directory and the error message next time was more sensible, but now mentioned a different data directory which also did not exist.
By doing a text search of all files using the old directory name, I found the culprit was C:\WINDOWS\my.ini, which contained references to basedir and datadir which were no longer valid. Removing the file and reinstalling fixed everything.
It was surprising to me that the configuration utility wrote its config file to a location which was never going to be used due to the existence of the other my.ini further up the pecking order.
The request I would like to make is that during the parsing of th my.ini file, if the values of datadir and basedir are specified but do not exist, the error log contains a specific message to indicate the location of the my.ini file and the nature of the error.
It might also be useful if the installer could mention to the user if remnants of a previous installation still exist (e.g. program folders, data folders, services, config files) and offer to nuke them. That way a fresh reinstall has much less chance of failing for unexpected reasons, which is obviously frustrating for new users.
I have found the cause of my error and corrected it, so there's no immediate problem, but I did see others with similar symptoms on the MySQL forums and elsewhere. I think it's likely that the enhancements suggested would benefit others and make your truly excellent product even more accessible.
I think you could argue that this should be filed as an enhancement, and I would be okay with that, but the reason I chose non-serious was that from my perspective as a user, the problem which was preventing me from getting a working installation was the obscurity of the message. For other users who have the same issue but weren't quite as obstinate as myself, they might well file the report of the same symptoms as critical.
Thanks again for a wonderful product - keep up the good work.
