bpo-36013: Fix the interactive shell SIGINT test. #11902
Conversation
First attempt: switch shell interupt test to zsh.
Lib/test/test_signal.py
Outdated
| # when a command exits via ^C and stops executing further | ||
| # commands. | ||
| process = subprocess.run( | ||
| ["bash", "-ic", | ||
| ["zsh", "-ic", | ||
| "echo TEST START 1>&2; " | ||
| f"{sys.executable} -c 'import os,signal; os.kill(os.getpid(), signal.SIGINT)'; " |
There was a problem hiding this comment.
From the issue:
Could it be a race condition the signal delivery?
Technically, the process sends itself a signal and never waits for it, it just exits. The signal can arrive after the process has exited normally. Or I am missing something obvious in this reasoning?
There was a problem hiding this comment.
it is possible (which is why i was thinking maybe flaky) but I suspect more is going on here as it only seems unreliable on CI and buildbot systems, and seems reliable from our login shells. I'm opting to not try and figure it out. testing interactive things within in automation isn't worth the effort for this issue. :)
There was a problem hiding this comment.
the other test above this one also uses the same self-killing code fwiw.
|
even zsh fails in CI runs despite passing in an interactive shell. i'll just get rid of the test. |
Unclear if this is necessary, but if there is a race condition between delivering ourselves a SIGINT and the CPython SIGINT handler that raises KeyboardInterrupt happening before our process could exit, this should avoid it. I made it easier to read and maintain regardless.
First attempt: switch shell interupt test to zsh.
if this doesn't work out, i'll just delete this test. it's a nice bonus integration test to avoid a regression of the actual interactive mode ^C'd process detection rather than the weak test that looks only at exit status (not what shells do).
https://bugs.python.org/issue36013