Bug #5996
libtopo ses module unload takes too long
100%
Description
The libtopo ses module creates a thread that repeatedly uses poll() to wait for some event and then do something about it in an endless loop. The call to poll specifies a timeout of 10s. When the ses module is told to clean up, it sets a global variable to indicate that the thread should exit, sends a signal to the thread to interrupt the poll, and waits for the thread to terminate.
The bug is that the signal is masked in the thread, so the ses module takes 10s to clean up.
Updated by Hans Rosenfeld over 5 years ago
Updated by Hans Rosenfeld over 5 years ago
This bug is actually dependent on the program linking with libtopo. In this case it was found with syseventd, which blocks all signals when it starts up and creates threads.
The ses module tries to find an unblocked signal to use for thread termination, and it falls back to SIGTERM if none are found. But this signal is also blocked and needs to be unblocked in the thread. In this particular use case this is the right thing to do, in all other cases it is harmless.
Updated by Hans Rosenfeld over 5 years ago
I tested this using the ZFS test suite in conjunction with 5997. Without this change 5997 would make the zpool expand test fail: the test waits only for 10s for the autoexpand to happen, but handling of the DLE event was delayed because handling of the previous pool creation event was blocked in ses.so cleanup. With 5996 fixed the test passed again, and no delay in event processing was observed.
Updated by Electric Monk over 5 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
git commit 057c620a8f2b46f09e91dfff7da884175a36b0a8
commit 057c620a8f2b46f09e91dfff7da884175a36b0a8 Author: Hans Rosenfeld <hans.rosenfeld@nexenta.com> Date: 2015-06-19T18:05:47.000Z 5996 libtopo ses module unload takes too long Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com> Reviewed by: Dan Fields <dan.fields@nexenta.com> Reviewed by: Dan McDonald <danmcd@omniti.com> Approved by: Dan McDonald <danmcd@omniti.com>