Client Response to Signals Event scheduler status: State : INITIALIZED Thread id : 0 LLA : n/a:0 LUA : n/a:0 WOC : NO Workers : 0 Executed : 0 Data locked: NO Event queue status: Element count : 0 Data locked : NO Attempting lock : NO LLA : init_queue:95 LUA : init_queue:103 WOC : NO Next activation : never •As of MySQL 8.0.19,  SIGUSR1  causes the server to flush the error log, general query log, and slow query log. One use for  SIGUSR1  is to implement log rotation without having to connect to the server, which requires a MySQL account that has privileges sufficient for those operations. For information about log rotation, see Section 5.4.6, “Server Log Maintenance” . • SIGINT  normally is ignored by the server. Starting the server with the  --gdb  option installs an interrupt handler for  SIGINT  for debugging purposes. See Section 5.9.1.4, “Debugging mysqld under gdb” . •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-ignore  option to ignore  SIGINT  signals. •Client programs that use the MySQL client library block  SIGPIPE  signals by default. These variations are possible: •Client can install their own  SIGPIPE  handler to override the default behavior. See Writing C API Threaded Client Programs. •Clients can prevent installation of  SIGPIPE  handlers by specifying the  CLIENT_IGNORE_SIGPIPE option to  mysql_real_connect()  at connect time. See mysql_real_connect(). MySQL client programs respond to signals as follows: The server response to  SIGUSR1  is a subset of the response to  SIGHUP , enabling  SIGUSR1  to be used as a more “lightweight”  signal that flushes certain logs without the other  SIGHUP  effects such as flushing the thread and host caches and writing a status report to the error log. Client Response to Signals 636