FAQ
Hi all,

I have the following problem: A client written by me using the C API hung
recently during some operation (almost certainly a SELECT, but possibly
an INSERT). I fired up a "mysql" text client, and that hung too, every
time I did a SELECT on the table I was interested in. Upon further
investigation I discovered that the partition which my data directory was
in, was full. It had, in fact, been filled by the mysql.log! It seems
that this had caused the server to hang, and that caused the clients to
hang when they tried to access it.

I "resolved" the problem by killing the mysql daemons (there were 18
running!), and re-installing mysql from source, pointing to a different
data directory.

However, I'm still somewhat (read: very) concerned that it appears that
a hung server led to a hung client, which leads me to my question: Can
I write my client code so that when it issues a mysql_real_query(), it
will time out if it receives no response from the server after a given
period of time? This would seem an obvious thing to do but I can't see
timeouts on anything other than connection...

One of my colleagues is suggesting hacking the libmysqlclient code, but
I really don't want to do that if I can help it!!! :)

I haven't used mysqlbug for this report, since the problem install is no
longer there (yes, I know, d'oh) - and this isn't an easily replicable
error anyway! Really I just want to know if/how I can modify my client
to avoid this problem? Also, is this something that's known about
already? If not, I might try to replicate on a toy machine here...

On the server:
The old version was from the mysql-3.22.27 binary RPM.
The new version is from the mysql-3.23.11 source tarbal.
The OS is Red Hat Linux 6.1 or maybe 6.0, w/ kernel version 2.2.12-20smp

The client was using client library from mysql-3.23.6.1

All advice appreciated. Best regards,

Andy

--
Andy Gimblett, Programmer, Frontier Internet Services Ltd. <gimbo@ftech.net>

All statements made are subject to Frontier's Terms and Conditions of
Business which are available upon request.

Search Discussions

  • Thimble Smith at Feb 23, 2000 at 1:41 pm

    On Wed, Feb 23, 2000 at 11:14:13AM +0000, Andy Gimblett wrote:
    I have the following problem: A client written by me using the C API hung
    recently during some operation (almost certainly a SELECT, but possibly
    an INSERT). I fired up a "mysql" text client, and that hung too, every
    time I did a SELECT on the table I was interested in. Upon further
    investigation I discovered that the partition which my data directory was
    in, was full. It had, in fact, been filled by the mysql.log! It seems
    that this had caused the server to hang, and that caused the clients to
    hang when they tried to access it.
    Andy, the manual has a section on ``How MySQL handles a full disk''.
    It suggests a few options to try.

    You might decide to wrap alarm() calls around your connect, so that
    if it takes to long you can abort it, and possibly fire off a script
    that tries to find out what's wrong and rectify the situation.

    Tim
    --
    Tim Smith < tim@mysql.com > :MySQL Development Team: Boone, NC USA.
  • Andy Gimblett at Feb 23, 2000 at 1:57 pm

    Andy, the manual has a section on ``How MySQL handles a full disk''.
    It suggests a few options to try.
    Nuts, so it does! And I thought I'd read it cover to cover... D'oh!
    You might decide to wrap alarm() calls around your connect, so that
    if it takes to long you can abort it, and possibly fire off a script
    that tries to find out what's wrong and rectify the situation.
    Hmmm... I'm not too familiar with signals and such. I have *some* idea
    what you mean, but can you help me fill in the blanks?

    function go_alarm(int sig)
    {
    // what goes here?
    }

    ...

    signal(SIGALRM, go_alarm)
    alarm(5) // Send out a SIGALRM in 5 seconds
    mysql_real_query(...) // Want this interrupted/aborted - but how?
    alarm(0) // Clear the previous alarm

    That's the basic structure you're talking about, right? But how does the
    mysql_real_query() call get aborted by the alarm signal?

    Thanks for your help! Cheers,

    Andy

    --
    Andy Gimblett, Programmer, Frontier Internet Services Ltd. <gimbo@ftech.net>

    All statements made are subject to Frontier's Terms and Conditions of
    Business which are available upon request.
  • Thimble Smith at Feb 24, 2000 at 9:34 am

    On Wed, Feb 23, 2000 at 11:49:37AM +0000, Andy Gimblett wrote:
    Hmmm... I'm not too familiar with signals and such. I have *some* idea
    what you mean, but can you help me fill in the blanks?

    function go_alarm(int sig)
    {
    // what goes here?
    }

    ...

    signal(SIGALRM, go_alarm)
    alarm(5) // Send out a SIGALRM in 5 seconds
    mysql_real_query(...) // Want this interrupted/aborted - but how?
    alarm(0) // Clear the previous alarm

    That's the basic structure you're talking about, right? But how does the
    mysql_real_query() call get aborted by the alarm signal?
    Andy, you might set a global variable that says that you were
    interrupted. Set it to false before alarm(5), and then check it
    after alarm(0). You don't have to do anything special to get
    mysql_real_connect to be aborted by the alarm call - that's what
    alarm does. You just have to trap the signal to keep the program
    from being terminated.

    Note that some operating systems don't reinstate signal handlers
    after they're used, so the next time you call alarm() the signal
    won't be caught. You have to reinstate the signal handler inside
    the signal handler itself. You can check a Unix book for more
    info.

    Tim
    --
    Tim Smith < tim@mysql.com > :MySQL Development Team: Boone, NC USA.
  • Andy Gimblett at Feb 29, 2000 at 6:33 pm
    Replying to myself, such a shame... :)

    Andy wrote:
    Sasha wrote:
    If I am thinking correctly, the problem is that your alarm
    handler gets called, but then control get transferred back
    to the normal execution of mysql_query().
    Yes, I agree: That certainly looks like the case. Whereas
    what we'd like, would be for mysql_query() to bail out with
    the SIGALRM, right?
    You need to jump out of the alarm handler using siglongjmp().
    ??? Sorry, I have not seen siglongjmp() before. Interesting
    man page - kind of makes sense. ;) Please could you advise
    on how I acheive this? Is it safe?
    I've consulted with my boss, a long-term linux hacker, and he
    asserts that jumping out of a signal handler is a Very Bad
    Thing, because after doing that, you're not going to catch
    any more signals. Is that correct?

    Please, can I have some more advise on how to get this
    timeout working? I find it hard to believe that timing out a
    call to mysql_real_query() isn't *trivial* - but it's
    starting to look like it's hardly possible???

    I *can't* use MySql if I can't get this timeout to work - the
    client I'm writing *mustn't* hang, quite simply... Please, there
    has to be a way to get this to work?

    Thanks again,

    Andy

    --
    Andy Gimblett, Programmer, Frontier Internet Services Ltd. <gimbo@ftech.net>

    All statements made are subject to Frontier's Terms and Conditions of
    Business which are available upon request.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmysql @
categoriesmysql
postedFeb 23, '00 at 1:21p
activeFeb 29, '00 at 6:33p
posts5
users2
websitemysql.com
irc#mysql

2 users in discussion

Andy Gimblett: 3 posts Thimble Smith: 2 posts

People

Translate

site design / logo © 2022 Grokbase