On Fri, Nov 11, 2005, Steffen Weinreich wrote:
> I´m fighting with mysql on debian 3.1 for some days now. What I have
> found is the following:
>
> - A build on a fresh installation of Debian 3.1 and OPenPKG 2.5
> produces a mysqld with bails out with a Sig11 directly after
> start.
>
> - The build on rm2 (our Debian3.1 buidl box) works without a problem
>
> - after taking a look with ldd /path/to/libexec/mysql/mysqld I found
> that rm2 ist using the libs from /lib/tls and my fresh installs
> uses the libs from /lib
>
> - Taking a look at 'uname' shows that my fresh installed boxes are
> still running a kernel 2.4.27.
>
> - After a kernel upgrade to 2.6.8 the already compiled version of mysql
> still bails out, but a rebuild of mysql produces running version of
> mysql
>
> - A reboot back to 2.4.27 show that the compiled binaries are runnable
> under the old kernel due to an error message from mysqld bdb (unable
> to initialize mutex: Function not implemented)
>
> For now I have solved the problem by using a 2.6 kernel, but I dont
> think thats the real solution. What do the other developer think about this?
One thing which comes to my mind is: Berkeley-DB uses "fast" mutex
implementations by default, i.e., it uses an implementation which should
be most optimal for the underlying platform. In our "db" package (which
"mysql" is _NOT_ using currently -- for threading purposes AFAIK) we
force Berkeley-DB into a portable mode. MySQL certainly doesn't do
this. Additionally, experience with our "openpkg" package and it's DB
based RPM shows that DB by default uses open(2)'s O_DIRECT flag and
unfortunately plain kernel.org Linux kernels (at least in the past) had
a broken O_DIRECT implementation. The implementation was also broken on
other vendor kernels, _BUT_ they usually masked out the flag directly
in the open(2) system call (and hence the broken implementation was not
actually used even the application thought it is). This can be the
difference between Kernel 2.4 and 2.6 here: 2.4 certainly is still
broken while 2.6 is finally fixed.
So, my suggestion is: try to apply the following hunk from db.patch
to the "mysql" local copy of Berkeley-DB (in subdir bdb/):
Index: os/os_open.c
--- os/os_open.c.orig 2004-09-28 18:46:57 +0200
+++ os/os_open.c 2004-11-11 20:04:31 +0100
@@ -121,7 +121,7 @@
if (LF_ISSET(DB_OSO_EXCL))
oflags |= O_EXCL;
-#ifdef HAVE_O_DIRECT
+#if defined(HAVE_O_DIRECT) && defined(__FreeBSD__)
if (LF_ISSET(DB_OSO_DIRECT))
oflags |= O_DIRECT;
#endif
I guess MySQL then works also under Kernel 2.4 (finger's crossed ;-)...
PS: obligatory Linux side blow: I really like Linux for its broken
interfaces. My favorite one in the past was not just this O_DIRECT,
but the fact that glibc sometimes provides silly stub functions
which just return ENOSYS. This way some Autoconf checks think the
functions exists on the underlying system and happily let the
application choose to use them. With the nice side-effect that it
later fails horribly under run-time. This approach of fulfilling
APIs and being "POSIX compliant" I liked most during the last
years... :-(
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
