Hi Tim, all!
Sorry, but I have to start with a negative remark:
Why, oh why, don't you mention the version number you are using?
I hope it is some roughly current 5.1, but I'd rather like you to tell it.
Tim Gustafson wrote:
> I have three mySQL server, all of which are SSL-enable and all of which are
> generally accessible from remote clients over SSL.
>
> However, one of my FreeBSD mySQL clients is having problems connecting to any
> of the servers. Running mySQL under truss reports the following:
>
Looking at this output tells something went terribly wrong:
file descriptor 2 is mishandled.
> ----------
> clock_gettime(13,{1298593067.000000000 }) = 0 (0x0)
> open("/dev/urandom",O_RDONLY,00) = 4 (0x4)
> read(4,"\a\^V\M-)\^C\M-L{`\M^O\M^@\M-v"...,32) = 32 (0x20)
> sendto(2,"\^V\^C\^A\0Y\^A\0\0U\^C\^A\M-m"...,94,0x0,NULL,0x0) = 94 (0x5e)
> recvfrom(2,"\^V",1,0x2,NULL,0x0) = 1 (0x1)
> ioctl(2,FIONREAD,0xffffd784) = 0 (0x0)
> recvfrom(2,"\^V\^C\^A\0J\^B\0\0F\^C\^AMf\M-u"...,1819,0x0,NULL,0x0) = 1819
> (0x71b)
In the above lines, socket calls 'sendto()' and 'recvfrom()' are applied
to FD 2. Whatever the transmitted data may be, this should not be done:
FD 2 is "standard error", so it is a file and no socket, and "receiving"
from it doesn't make any sense at all.
As the problem happens only for one of your combinations, I suspect that
for some unknown reason FD 2 was closed in that run, and then this
number got returned when a socket was to be created.
Again, this should not happen: The only reason to close FD 2 should be
to re-open standard error to some other destination, which is unlikely
for the client to do.
> [[...]]
> shutdown(2,SHUT_RDWR) = 0 (0x0)
> close(2) = 0 (0x0)
So FD 2 is closed now.
> fstat(1,{ mode=crw--w---- ,inode=113,size=0,blksize=4096 }) = 0 (0x0)
> ioctl(1,TIOCGETA,0xffffe390) = 0 (0x0)
> write(2,"ERROR 2026 (HY000): ",20) ERR#9 'Bad file descriptor'
> write(2,"SSL connection error",20) ERR#9 'Bad file descriptor'
> write(2,"\n",1) ERR#9 'Bad file
> descriptor'
... but with a closed FD 2 there is no chance to output an error message.
(The operations on FD 1 also look suspicious to me.)
> write(1,"\a",1) = 1 (0x1)
> close(4) = 0 (0x0)
> process exit, rval = 1
> ----------
>
> Can anyone tell me, based on the truss output above, what might be going
> wrong? I'm using the exact same command line options and ssl-ca file that I
> am using on other clients, which can connect successfully.
I can't really tell what happened. It might be that file descriptor 2
(and probably also 1) were closed without good reason, and then creating
a socket (or opening some file) returned these descriptors.
You might check the preceding "truss" output for a "close(2)", IMO that
would likely be an error - but I have no idea why it happened.
>
> (As an aside: feature request: better SSL connection debugging, please!)
I assume your SSL problems might just be a consequence of inappropriate
actions on FDs 1 and 2. Did you do any redirection, are you running into
"disk full", or is there any similar rsk on your stdout and stderr?
HTH,
Jörg
--
Joerg Bruehe, MySQL Build Team, joerg.bru...@oracle.com
ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
