As of 11.4 git sha 70de4075a18c12ed7e55db9a49e66eb6cff308b2 (but not necessarily due to this commit), sending the TERM signal to mariadb on macOS no longer gracefully terminates mariadb. In fact, nothing appears to happen from the perspective of the console (running mariadb in the foreground rather than as a daemon).
013fc02a23e7861dfb879e4bea5cf02d0562a509 is the git commit that introduces this problem. The commit immediately preceding, 3424ed7d428b604616fabd2c73620a49348baa21 works as expected.
Dave Gosselin
added a comment - 013fc02a23e7861dfb879e4bea5cf02d0562a509 is the git commit that introduces this problem. The commit immediately preceding, 3424ed7d428b604616fabd2c73620a49348baa21 works as expected.
that's probably about waking main thread, something pthread_kill did in the past, can't think about anything else. I was not sure socket shutdown would work, yet neither buildbot, nor our macOS folks would complain. There is already some `termination_event_fd` for Linux for systemd by Daniel Black, to avoid socket shutdowns (bad for systemd "socket activation") . that thing works with eventfd. I think it is more portable way would be good old Unix self-pipe.
Vladislav Vaintroub
added a comment - - edited that's probably about waking main thread, something pthread_kill did in the past, can't think about anything else. I was not sure socket shutdown would work, yet neither buildbot, nor our macOS folks would complain. There is already some `termination_event_fd` for Linux for systemd by Daniel Black, to avoid socket shutdowns (bad for systemd "socket activation") . that thing works with eventfd. I think it is more portable way would be good old Unix self-pipe.
We will need to port this to 10.5. As of git sha 7432a487b1334aacd1ed535f8a29cf939a13cde7 I'm seeing the original issue on 10.5 once again. We initially fixed this in 11.4 but somehow a merge into 10.5 has brought this problem to light.
Dave Gosselin
added a comment - We will need to port this to 10.5. As of git sha 7432a487b1334aacd1ed535f8a29cf939a13cde7 I'm seeing the original issue on 10.5 once again. We initially fixed this in 11.4 but somehow a merge into 10.5 has brought this problem to light.
Gosselin, can you bisect to find out which change broke macOS? What are stacktraces of all threads, when server does not stop? There was no merging of 11.4 into 10.5, so this time it would be something different.
Vladislav Vaintroub
added a comment - Gosselin , can you bisect to find out which change broke macOS? What are stacktraces of all threads, when server does not stop? There was no merging of 11.4 into 10.5, so this time it would be something different.
Yes, I'll bisect to find where the problem came in. When I spoke about a merge, I didn't mean a merge from 11.4 to into 10.5. Instead, I meant a merge from an earlier version, into 10.5. I'm not certain about which earlier version, but a bisect will uncover it.
Dave Gosselin
added a comment - Yes, I'll bisect to find where the problem came in. When I spoke about a merge, I didn't mean a merge from 11.4 to into 10.5. Instead, I meant a merge from an earlier version, into 10.5. I'm not certain about which earlier version, but a bisect will uncover it.
The commit where 10.5 breaks on macOS is git sha 952ab9a59659b28f10ce2770e17249e0ff5b0681
The commit before it, 4980fcb9909449f4d65886ee2c1d1080bb3d55a5 works fine.
I attached a sampling of the process as provided by Activity Monitor in macOS which shows all the threads.
Dave Gosselin
added a comment - - edited The commit where 10.5 breaks on macOS is git sha 952ab9a59659b28f10ce2770e17249e0ff5b0681
The commit before it, 4980fcb9909449f4d65886ee2c1d1080bb3d55a5 works fine.
I attached a sampling of the process as provided by Activity Monitor in macOS which shows all the threads.
I see that this removed some but not all use of HAVE_POLL. Could the remaining use be removed, along with the compile-time checks for HAVE_POLL and HAVE_POLL_H? That would speed up the initial CMake invocation.
Marko Mäkelä
added a comment - I see that this removed some but not all use of HAVE_POLL . Could the remaining use be removed, along with the compile-time checks for HAVE_POLL and HAVE_POLL_H ? That would speed up the initial CMake invocation.
I'm starting this now because it's starting to annoy me.