Hi!
>>>>> "elfchief" == elfchief <elfchief@stripped> writes:
>> Description:
elfchief> [This bug was previously reported informally to the mailing list.
elfchief> I'm submitting a formal report, now, since we didn't get very
elfchief> far from there]
elfchief> Very simply, MySQL occasionally prints in the log:
elfchief> 000407 9:18:14 Warning: Got signal 14 from thread 4
elfchief> 000407 9:18:14 Warning: Got signal 14 from thread 4
elfchief> 000407 12:29:46 Warning: Got signal 14 from thread 4
elfchief> 000407 12:29:46 Warning: Got signal 14 from thread 4
elfchief> ... sometimes multiple times per day, sometimes not at all. The
elfchief> messages -always- seem to come in pairs.
elfchief> This problem seems to have begun after an upgrade from Solaris
elfchief> 2.5.1 to Solaris 7 (both x86), though I admit to not having
elfchief> looked at my logs very closely before the upgrade.
elfchief> The Solaris box is fully patched with the current reccomended
elfchief> patch cluster.
elfchief> This problem can not be duplicated on the other in-house Solaris 7
elfchief> x86 box, nor a Solaris 7/sparc box.
elfchief> This Solaris 7 x86 box is the only multi-processor Solaris x86 box
elfchief> we have -- The second Solaris x86 box we tested on (that worked
elfchief> fine, we think) is uniprocessor.
>> How-To-Repeat:
elfchief> I can not find a repeatable case of this issue; At first I thought
elfchief> it to be load related, but the messages have continued even after
elfchief> my load-testing on my server completed. (The current server load
elfchief> is averaging about one (simple) query a second). I've seen the
elfchief> messages during high-usage times of the day, and during low-usage
elfchief> times of the day. Best I can tell, the message is completely
elfchief> random.
>> Fix:
elfchief> Beg Monty to look at it? :)
We have several multi-cpu sparc boxes that we use here at TCX and we
don't have this problem on these. Sorry, but we don't have any x86
Solaris box to test this one :(
signal 14 is the alarm signal; The above probably means that the sigwait
call doesn't work properly on Solaris x86 multi-cpu boxes. On the
other hand, when the above stray signal happens, MySQL will just print
a warning about it and then silently reschedule the alarm 2 seconds
later. This should not cause any real performance problems.
Could the trigger for this be that you have some clients waiting for a
long time and you get the error when mysqld tries to shut down the
connection after 'wait_timeout' seconds ?
Regards,
Monty
