Bug #17241 bad (missing) error handling when basedir is wrong
Submitted: 8 Feb 2006 19:48 Modified: 3 Mar 2006 10:12
Reporter: d di (Basic Quality Contributor) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0.18 OS:Windows (Windows)
Assigned to: CPU Architecture:Any

[8 Feb 2006 19:48] d di
Description:
When upgrading from eg. 4.0.22 to 5.0.18, the basedir of the mysql installation changes.

However, the "basedir" variable in my.ini is not automatically altered, so it might be for example:

[mysqld]
basedir = c:/program files/mysql

when in fact the server is located in "c:/program files/mysql/mysql server 5.0" after the upgrade.

When attempting to start the upgraded server, the "NET START MySQL" command yields the following output:

"Could not start the MySQL service [...]
Error 1067: The process terminated unexpectedly."

No further information is available in the NT event log nor the <hostname>.err file, which is rather unhelpful.

How to repeat:
Fake the basedir.

Suggested fix:
Report a correct error message to the NT event log (syslog on Unix).

If the datadir exists and the <hostname>.err file is accessible in write mode, also log the error there.
[9 Feb 2006 10:18] Valeriy Kravchuk
Thank you for a reasonable feature request. Yes, it will be useful for Windows installer to check existing my.ini file/services and suggest changes for the user to confirm.
[9 Feb 2006 15:44] d di
MySQL *CRASHES*.
No excusing error message or nothing, just a rock hard crash.

That's definitely a bug.

Are you trying to tell me that if I want MySQL Server not to crash when it's upgraded, I should request it as a feature? :-D
[15 Feb 2006 15:03] Valeriy Kravchuk
Please, specify the exact version of Windows and MySQL distribution package used. I was unable to repeat the crash with "fake" basedir with 5.0.18 on XP.
[15 Feb 2006 15:21] d di
I've run into it on two different PCs, both are Windows 2000.
One of them is SP3, can't remember what the other is.

The configuration file is called "my.ini" and is located in C:\WINNT.
(There are no ini / cnf files in the mysql base dir.)

MySQL is installed as a service, using "mysqld-max-nt --install".
[21 Feb 2006 14:07] Valeriy Kravchuk
If there was a crash, there should be something about it in the server's error log. Please, send or upload error log of your 5.0.18 server (should be in the data directory).
[21 Feb 2006 15:07] d di
I don't think we are talking about the same kind of "crash".

I'm talking about the service manager telling me this (NET START):
========================
A system error has occurred.

System error 1067 has occurred.

The process terminated unexpectedly.
========================

I consider it a crash, because MySQL obviously exits uncleanly.
By unclean, I mean "without telling the service manager that an error has occurred and that MySQL failed to start".

As stated in the bug description, there is no information in the error file.  If the error file does not exist, the server will terminate uncleanly before creating it.  So there's nothing for me to upload...
[21 Feb 2006 15:18] MySQL Verification Team
Hi,

The 1067 error means tha server aborted the service due to some reason
which you can see if try to start the server as standalone. i.e.:

\mysqld-nt --defaults-file=\path_for_my.ini --standalone --console

from a DOS prompt command.

Then take a look which are the error messages displayed.
[21 Feb 2006 15:34] d di
Yes, ok.

The error message shown is (for the record) "Can't find messagefile 'c:\program files\mysql\share\english\errmsg.sys'".  A more appropriate error message could've been "base directory not found".

Do we agree that 1067, "The process terminated unexpectedly" is not exactly appropriate and should've been for example 1066, "The service has returned a service-specific error code" or some other error code, or are we disagreeing on that point?
[23 Feb 2006 9:25] Valeriy Kravchuk
These:

"Do we agree that 1067, "The process terminated unexpectedly" is not exactly
appropriate and should've been for example 1066, "The service has returned a
service-specific error code" or some other error code, or are we disagreeing on
that point?"

once again sounds like a (reasonable) feature request for me. You want to get more precise and proper error messages in such a cases. Do you agree?
[23 Feb 2006 11:30] d di
> once again sounds like a (reasonable) feature request for me.

No, it was a reasonable question (which you apparently declined to answer..).

> You want to get more precise and proper error messages in such a cases.
> Do you agree?

That I'd like to see "more precise and proper error messages"?  Yes.

That it's a feature request?  No.  The MySQL server process crashes without letting the service manager know that an internal error has occurred.

That's a flawed way to interact with the service manager; one which indeed others than myself have wondered about:
http://bugs.mysql.com/bug.php?id=995
http://bugs.mysql.com/bug.php?id=4349
http://bugs.mysql.com/bug.php?id=6278
http://bugs.mysql.com/bug.php?id=3399
http://bugs.mysql.com/bug.php?id=2941
http://bugs.mysql.com/bug.php?id=3670
http://bugs.mysql.com/bug.php?id=4746
http://forums.devside.net/viewtopic.php?t=250&postdays=0&postorder=asc&start=0
http://www.experts-exchange.com/Databases/Mysql/Q_21045378.html
http://forums.mysql.com/read.php?11,11388,11388
http://www.faqts.com/knowledge_base/view.phtml/aid/2569/fid/185
http://www.phpe.net/faq/74.shtml
http://www.issociate.de/board/post/171223/Mysql_will_not_start-error_1067.html
http://www.issociate.de/board/post/288337/Error_1067.html
http://www.thescripts.com/forum/threadedpost1736198.html
http://www.codecomments.com/archive229-2005-9-622621.html
[...]

In fact, the most popular page if you search for "system error 1067" on Google is a page explaining this problem with MySQL..

When your application is flawed in the way it interacts with the operating system then that's a bug, if you ask me.
[23 Feb 2006 11:33] d di
In addition to 1066: "The service has returned a service-specific error code",
another good one is 3534: "The service did not report an error".

This is the error code used by the .NET framework when an exception occurs during service startup.  The exception itself can then be seen in the Application event log.
[24 Feb 2006 10:58] Valeriy Kravchuk
I've got in XP Event log (Even Viewer > Application) 2 events:

"Aborting

For more information, see Help and Support Center at http://www.mysql.com."

and before that:

"Can't find messagefile 'C:\Program Files\MySQL\share\english\errmsg.sys'

For more information, see Help and Support Center at http://www.mysql.com."

NET START does not show service as started.

So, please, check again on your Windows 2000. MySQL interacts as expected with XP, as I can see.
[2 Mar 2006 15:13] d di
You are right, when retesting on my local XP workstation I get an error in the event log as you describe.

I don't know why I do not see that on the Windows 2000 machines.
I'm not going to retest (these are live production systems), but I can test on another Windows 2000 box if you wish.
[3 Mar 2006 10:12] d di
Just tested on Windows 2000 in a VMware box, it seems to work.
So I guess we can rule MySQL out as a cause of that problem.

This bug is getting a little confusing, so I'm closing it.
I'll open new bugs specifically for the parts that I think is really bugs in MySQL.