mirror of
https://github.com/MariaDB/server.git
synced 2026-10-23 18:49:29 +03:00
76590804bf
Problem: ======== If a server hangs in startup, mtr either waits for its pid file for --start-timeout seconds and gives up with "Failed to start" (or) when the test restarts the server, leaves the waiting to mysqltest, which ends after about 500 seconds with "Server failed to restart". In both cases the hung server is killed with SIGKILL, so no core dump and no stack trace is produced, and it is impossible to find out where the server got stuck. Solution: ========= dump_core_for_hung_server(): Sends SIGABRT to a server that is still alive and waits for it to finish dumping core. The server's fatal signal handler writes the stack trace to the error log. sleep_until_file_created(): call it when the wait for the pid file times out and the process is still alive. This covers the servers that mtr starts and waits for itself. check_expected_crash_and_restart(): when mtr restarts a server on behalf of the test, remember the time by which the server must have created its pid file ($opt_start_timeout) run_testcase() wakes up at that time, and if the server is still alive without a pid file, it dumps core, fails the test with "Failed to restart mysqldN, no pid file after N seconds" and kills mysqltest, instead of waiting for it to give up. mysql_server_wait(): append the server log of the failed server to the failure report, as the other failure paths do. Behavior change: ================ A restart done by the test now has to finish within --start-timeout (180 seconds by default, MTR_START_TIMEOUT), the same as an initial start. Before, only the test's own wait applied, about 500 seconds with restart_mysqld.inc. A slow but healthy restart that needs more than --start-timeout now fails with a core dump. Raise MTR_START_TIMEOUT for such tests. Under a debugger the timeouts are much longer, so nothing changes there. Servers that are only slow, or that mtr has not waited for yet are not aborted before the timeout.