4.10 Unix Signal Handling in MySQL
On Unix and Unix-like systems, a process can be the recipient of signals sent to it by
root or the account that owns the process. Signals can be sent using the kill command. Some command interpreters associate certain key sequences with signals, such as Control+C to send a
SIGINT signal. This section describes how the MySQL server and client programs respond to signals.
mysqld responds to signals as follows:
SIGHUPcauses the server to reload the grant tables and to flush tables, logs, the thread cache, and the host cache. These actions are like various forms of the
FLUSHstatement. The server also writes a status report to the error log that has this format:
Status information: Current dir: /var/mysql/data/ Running threads: 0 Stack size: 196608 Current locks: Key caches: default Buffer_size: 8388600 Block_size: 1024 Division_limit: 100 Age_limit: 300 blocks used: 0 not flushed: 0 w_requests: 0 writes: 0 r_requests: 0 reads: 0 handler status: read_key: 0 read_next: 0 read_rnd 0 read_first: 1 write: 0 delete 0 update: 0 Table status: Opened tables: 5 Open tables: 0 Open files: 7 Open streams: 0 Alarm status: Active alarms: 1 Max used alarms: 2 Next alarm time: 67
SIGINTnormally is ignored by the server. Starting the server with the
--gdboption installs an interrupt handler for
SIGINTfor debugging purposes. See Section 188.8.131.52, “Debugging mysqld under gdb”.
MySQL client programs respond to signals as follows:
The mysql client interprets
SIGINT(typically the result of typing Control+C) as instruction to interrupt the current statement if there is one, or to cancel any partial input line otherwise. This behavior can be disabled using the
--sigint-ignoreoption to ignore
Client programs that use the MySQL client library block
SIGPIPEsignals by default. These variations are possible:
Client can install their own
SIGPIPEhandler to override the default behavior. See Section 184.108.40.206, “Writing C API Threaded Client Programs”.