MySQL 5.0 Reference Manual  /  ...  /  Linux Binary Distribution Notes Linux Binary Distribution Notes

The Linux-Intel binary and RPM releases of MySQL are configured for the highest possible speed. We are always trying to use the fastest stable compiler available.

The binary release is linked with -static, which means you do not normally need to worry about which version of the system libraries you have. You need not install LinuxThreads, either. A program linked with -static is slightly larger than a dynamically linked program, but also slightly faster (3% to 5%). However, one problem with a statically linked program is that you can't use user-defined functions (UDFs). If you are going to write or use UDFs (this is something for C or C++ programmers only), you must compile MySQL yourself using dynamic linking.

A known issue with binary distributions is that on older Linux systems that use libc (such as Red Hat 4.x or Slackware), you get some (nonfatal) issues with host name resolution. If your system uses libc rather than glibc2, you probably will encounter some difficulties with host name resolution and getpwnam(). This happens because glibc (unfortunately) depends on some external libraries to implement host name resolution and getpwent(), even when compiled with -static. These problems manifest themselves in two ways:

  • You may see the following error message when you run mysql_install_db:

    Sorry, the host 'xxxx' could not be looked up

    You can deal with this by executing mysql_install_db --force, which does not execute the resolveip test in mysql_install_db. The downside is that you cannot use host names in the grant tables: except for localhost, you must use IP addresses instead. If you are using an old version of MySQL that does not support --force, you must manually remove the resolveip test in mysql_install_db using a text editor.

  • You also may see the following error when you try to run mysqld with the --user option:

    getpwnam: No such file or directory

    To work around this problem, start mysqld by using the su command rather than by specifying the --user option. This causes the system itself to change the user ID of the mysqld process so that mysqld need not do so.

Another solution, which solves both problems, is not to use a binary distribution. Obtain a MySQL source distribution (in RPM or .tar.gz format) and install that instead.

On some Linux 2.2 versions, you may get the error Resource temporarily unavailable when clients make a great many new connections to a mysqld server over TCP/IP. The problem is that Linux has a delay between the time that you close a TCP/IP socket and the time that the system actually frees it. There is room for only a finite number of TCP/IP slots, so you encounter the resource-unavailable error if clients attempt too many new TCP/IP connections over a short period of time. For example, you may see the error when you run the MySQL test-connect benchmark over TCP/IP.

We have inquired about this problem a few times on different Linux mailing lists but have never been able to find a suitable resolution. The only known fix is for clients to use persistent connections, or, if you are running the database server and clients on the same machine, to use Unix socket file connections rather than TCP/IP connections.

User Comments
  Posted by on January 30, 2003
> The problem is that Linux has a delay between
> when you close a TCP/IP socket and until this
> is actually freed by the system.

This isn't a Linux problem. The delay between closing
a TCP/IP socket, and freeing it, is part of the
network specification.

Linux should not be changed to make MySQL work,
unless Linux violates a standard. Since Linux
does not seem to be violating the standard, then
instead, you should change MySQL to work correctly.

A suggestion as to how to do that is to use the
SO_REUSEADDR socket option. WARNING! Using this
may violate the TCP/IP standard, so use with
extreme care, and only if you understand why
such a delay exists, and under what conditions it
is safe to bypass this delay.
  Posted by Scott Franson on December 15, 2005
Actually, it sounds like a lot of sockets in the TIME_WAIT state, which can last several minutes. This is a normal and important part of a socket's lifecycle. They only way to bypass it is for the server to set the SO_LINGER option, with a timeout value of zero. This forces the socket to reset when closed and avoids the TIME_WAIT state and the socket's resources are immediately recovered. The consequence is that there may be data loss if the client requests a resend of a TCP packet.
  Posted by Eject Disc on December 26, 2005
Just for the hell of it and for some experience for my MySQL Pro exam, I have got a base install of Debian 3.0 going on an old 540Mb disc I had lying around. I installed the Debian MySQL 3.23 server package and then tried to upgrade this using a 4.1 binary tarball release.

Debian 3.0 is using glibc2.2.5 but I thought it would work out fine using the glibc2.3 tarball of the latest 4.1 release. In the text above: "The binary release is linked with -static, which means you do not normally need to worry about which version of the system libraries you have."
However, I couldn't get the server to start due to errors over GLIC2.3 not being installed!

Luckily MySQL thoughtfully provides the answer in the 'Misc/Special Files' section of the 4.1 downloads list. There you will find a tarball that is compatible with glibc2.2.5 and it worked out fine.

My understanding of the glib23 statically linked release is that it's all self-contained and that I need no other software to install and run the thing. Please someone smart set me straight here.

A small snag I hit during the install is when running the grant table fixer script. This appears to be hardcoded to use /tmp/mysql.sock. I didn't want to mess aorund with hacking the script, so I simply specifyed a host param of This means it will use TCP/IP thereby getting around the problem.

Hope this helps someone! Back to studying...
Sign Up Login You must be logged in to post a comment.