impossible to use Ports on mySQL - Upstart/Config Problem

[codeslinger]

Binary package hint: upstart

new install of ubuntu-10.04-server-i386.iso

spent 3 hours attempting to connect to mySQL using 127.0.0.1:3606

for instance, telnet 127.0.0.1 3606
should return something like:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
@
5.1.41-3ubuntu12.3 (gibberesh)Connection closed by foreign host.

always and forever mySQL is forced to use the socket or nothing.
Have disabled apparmor, disabled the default configs etc.

but somehow no matter what I try, it always gets overridden and refuses connections on the port.
this is the case even though the mySQL log itself says that it is listening on the port + socket.

100618 1:32:29 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.41-3ubuntu12.3' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)

finally I manually start mySQL and totally bypass the rc/upstart system. and finally I can indeed connect using the port.

This Works:
/usr/sbin/mysqld --bind-address=127.0.0.1 --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3606 --socket=/var/run/mysqld/mysqld.sock &

except that the mysql client program itself is still hardcoded in some way to only use the socket despite it's config file clearly telling it to use the port. and despite me telling it on the command line that --port=3606

I find this situation to be rather uncharming and unendearing. ;-o

There are a lot of valid reasons for programs to want to use ports, you should allow the programmer to decided about the security issues, you should not force people into a straight-jacket and padded room because they *might* hurt themselves. -- guard rails yes, locked padded rooms, No!

I am not inclined to reverse engineer the entire upstart system in order to find this problem. actually, this points out a very serious problem with the upstart design, everything is now hidden into obscurity and problems become impossible to find and fix without huge effort.

I can work around this issue for now by writing my own init script. But this whole mess needs to be rethought and mySQL Ports MUST be enabled to function.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: upstart 0.6.5-6
ProcVersionSignature: Ubuntu 2.6.32-21.32-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-21-generic i686
Architecture: i386
Date: Fri Jun 18 02:41:04 2010
InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release i386 (20100427)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: upstart

[codeslinger (codeslinger)]

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.

[Clint Byrum (clint-fewbar)]

Hi codeslinger, thanks for taking the time to file this bug report and help us make Ubuntu better.

This appears to be an issue with the mysql upstart job or my.cnf, not with upstart, so I am moving it to the appropriate package.

I know it has been a long time, but can you maybe upload /etc/mysql/my.cnf and /etc/init/mysql.conf ? (if you have replication setup, my.cnf may have passwords, so please make sure to redact those).

Marking Incomplete pending response from codeslinger.

[xteejx (xteejx-deactivatedaccount)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!