MySQL Bugs: #16639: MySQL 5.0 for Win32 having trouble talking to SFU/Interix

Bug #16639	MySQL 5.0 for Win32 having trouble talking to SFU/Interix
Submitted:	19 Jan 2006 17:08	Modified:	27 Sep 2008 12:29
Reporter:	Ty Schalter	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Command-line Clients	Severity:	S2 (Serious)
Version:	5.0.18	OS:	Windows (Windows 2003 Server)
Assigned to:		CPU Architecture:	Any

Description:
What I did: Attempted to connect to server via telnet and run MySQL interactively from the command line. Server is Windows 2003, running MySQL for Win32. Server is also running SFU/Interix. Tried to connect with WindowsXP machine using MySQL Command Line Client, MS-DOS prompt, Korn shell, and PuTTy.

What I expected to happen:
On any OS, with any client, after succesful telnet connection is built,
mysql.exe allows execution with login from the command line.

What actually happened:
When a client telnets to the server and attempts to invoke mysql.exe from the
command line, it either fails with the following: " (Unable to read --unknown error
(error:9))", or hangs with no output. When running locally, all of the above utilities work as expected. There is another developer on the forums having the exact same problem with the exact same environment.

How to repeat:
Install MySQL 5.0.18 and SFU/Interix onto a Windows 2003 box. From another
computer, bring up PuTTY or ksh and telnet to the server via the command line.
Navigate to the MySQL directory, and attempt to log in to MySQL via the command:
''mysql.exe -u user -ppassword''.

Suggested fix:
There is something funny between SFU (specifically SFU's telnet server) and
MySQL. I am currently attempting to compile MySQL's source inside Interix and
run it as an Interix app, but I have not yet been successful. Workarounds for
now include using remote desktop software to run interactive mode from a local
command prompt, and kicking everything off from scripts and avoiding interactive mode altogether.

Thank you for a problem report. Yes, I've got the same behaviour (mysql client hang) as you describe, on XP with SFU (used just to manage Telnet service on XP, as well as on 2003).  But looks like it is a problem of Telnet server implementation, not a problem of mysql client itself (mysql.exe was compiled to be used in Windows console, and it works there, as well as in Korn Shell of that SFU - a properly written console client).

So, looks like either something in Telnet server should be fixed or mysql command line client should be recompiled inside SFU. The former is not a MySQL problem, the later may be fixed some day, but unsupported now.

If you just want to manage data at some remote Windows'based MySQL server, use local mysql client connecting to that remote server. It is so simple, and much more secure way then telnet.

Valeriy--

Thanks for your hard work and response!  We have been able to run the client locally, either through the MS-DOS prompt, the MySQL command line client, or the SFU ksh.  However, on a remote WinXP machine (which also has SFU installed), opening up a ksh session and telnetting into the server results in this error on login: "Unable to read -- unknown error (error:9))".

I would love to try compiling the MySQL Command Line Client inside SFU, however you don't provide the source for just the command line line, and I've been unable to compile the complete MySQL 5.0 package inside SFU to date.   Any help there?

Thanks again,
Ty

Look:

C:\Documents and Settings\openxs>perror 9
OS error code   9:  Bad file descriptor

So, I think, the real reason is that Windows Telnet Service is not working with, say, STDERR properly.

To compile only client you have to use --without-server configure option (see http://dev.mysql.com/doc/refman/5.0/en/configure-options.html for the details). But anyway it is not supported. Maybe me or somebody else will take a look at compiling inside SFU (as it was done for cygwin enwironment), some day...

I think there is a workaround, based on local mysql client and SFU utilities usage (ssh or rsh, for example), for any reasonable action you are trying to perform over telnet.

I stumbled over the very same issue recently. From the analysis it seems there is nothing we can do about it. Setting to 'Won't fix'. Please reopen if you have any suggestion for a fix on MySQL side.