Comment 2 for bug 595877

by the way, when you are testing this, using the mysql client turns out to be unreliable. For some inexplicable reason it is ignoring the command line request that it connect to a port. You can see this if after logging in you do a "\s" at the sql prompt.

the only reliable way to test that it is working is to use telnet.

Figuring out how/why the mysql client is ignoring what it is being told to do should also be an important part of fixing this bug. For instance when running multiple mySQL servers on the same cpu you MUST be able to control the ports.

------------

As a further thought, I am also very unenthused about the automatic update that occurs every time the mySQL startup script runs. It has been my experience that unplanned, uncontrolled, automatic updates lead to random failures.

The two most important things that a server needs to deliver are security AND STABILITY. I would argue that Stability is actually more important then having that "latest security fix" that may not actually fix anything important, but ends up breaking things instead. I'm speaking from experience :-( I will say that ubuntu updates are far better than Microsoft on that score. But you still need to allow sysadmins to decide when and what upgrades they are willing to do.

For example about 6 months ago there was a security fix for apache -- the problem itself only occurred in very specific circumstances that did not happen to apply to the way my server was configured -- so the fix itself was unimportant -- but for some bizarre reason, the security fix / upgrade decided to replace the apache conf file with the default, thus tossing the custom changes that had been made to the configuration file, with the result being that suddenly and unexpectedly all of the websites went down. This type of disaster can only be avoided when the sysadmin is able to control the upgrade process and is there to supervise the result. To have updates happen randomly when nobody is around is a nightmare.