On 2/21/24 15:27, Aaron Conole wrote: > Daniel Ding <[email protected]> writes: > >> After running ovs-tcpdump and inputs multiple CTRL+C, the program will >> raise the following exception. >> >> Error in atexit._run_exitfuncs: >> Traceback (most recent call last): >> File "/usr/bin/ovs-tcpdump", line 421, in cleanup_mirror >> ovsdb = OVSDB(db_sock) >> File "/usr/bin/ovs-tcpdump", line 168, in __init__ >> OVSDB.wait_for_db_change(self._idl_conn) # Initial Sync with DB >> File "/usr/bin/ovs-tcpdump", line 155, in wait_for_db_change >> while idl.change_seqno == seq and not idl.run(): >> >> Signed-off-by: Daniel Ding <[email protected]> >> --- > > LGTM for the linux side - maybe Alin might check the windows side.
The code is copied from the fatal-signla library, so it is likely fine. However, I don;t think this issue should be fixed on the application level (ovs-tcpdump). There seems to be adifference in how C and python fatal-signla libraries behave. The C version calls the hooks in the run() function and the signal handler only updates the signal number variable. So, if the same signal arrives multiple times it will be handled only once and the run() function will not exit until all the hooks are done, unless it is a segfault. With python implementation we're calling hooks right from the signal handler (it's not a real signal handler, so we're allowed to use not really singal-safe functions there). So, if another signal arrives while we're executing the hooks, the second hook execution will be skipped due to 'recursion' check, but the signal will be re-raised immediately, killing the process. There is likley a way to fix that by using a mutex instead of recursion check and blocking it while executing the hooks. The signal number will need to be stored in the signal handler and the signal will need to be re-raised in the call_hooks() instead of signal handler. We can use mutex.acquire(blocking=False) as a way to prevent recursion. Does that make sense? Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
