session-manager-plugin: Problem interpreting signals emitted by terminal on BSD systems properly
NOTE: This issue’s contents and title have been significantly changed as of Jan 15 because of some folks getting to the underlying issue.
The underlying issue is that when using a BSD-based system (like OS-X) this plugin sends some undesirable control signals. This appears to ONLY affect Macs, not Windows or Linux.
@pedros007 Believes this issue is related to the ControlSignals handled by a ShellSession
Reproduce steps which seems to only happen on a MacOS terminal:
- Start a shell session
aws ssm start-session --target i-00112233445566778 - Once connected, press Ctrl-y
- Expected behavior: paste from the kill-ring (which is empty, so nothing should happen)
- Actual behavior: The session terminates with the log line
Cannot perform start session: read /dev/stdin: resource temporarily unavailable
The kludgy workaround currently is
- Run stty dsusp undef on your host.
- Start a shell session
aws ssm start-session --target i-00112233445566778 - Press Ctrl-y to paste from the kill ring (which is empty, so nothing happens). This is what every other OS does, and what Linux normally does when you SSH.
For more details about this issue please see some of the comments towards the bottom of the thread/issue.
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 2
- Comments: 20
Commits related to this issue
- Fix control characters handling by switching terminal to raw mode (closes #29) — committed to jbbarth/session-manager-plugin by jbbarth 9 months ago
- Fix Ctrl+key handling by switching terminal to raw mode (closes #29) — committed to jbbarth/session-manager-plugin by jbbarth 9 months ago
I put this command in my
.zshrcon my mac so that the terminal where I run the commands is set up correctly, and that seems to do the trick. If you have any other problematic Ctrl+chars, see if they are mapped to something in thestty -aoutput. I think @pedros007 also had trouble with Ctrl+S in emacs and was able to fix it by unmapping that particular control character. Something likestty stop undef.I built upon the analysis from @justinmk3 (thanks!) and submitted a PR in #80. Everything is described in the PR description. It fixes the issue, but it needs some polishing and probably the eye of somebody experienced with such issues. It’s great if some of you can confirm if the branch fixes the problem for you or not. 🙏
TL; DR: Run
stty dsusp undefprior to starting an SSM session to allowCtrl-yto properly yank from the kill ring when connecting to a Linux instance from my Mac laptop.More details:
A coworker and I ran into an issue where we’d use SSM to ssh to an instance:
but when we would yank from the kill ring (via
Ctrl-Y), a few seconds later the session ends and the following is written to the terminal:I have only experienced this connecting from a Mac laptop to a Linux EC2 instance. Can’t reproduce it when connecting from a Linux machine to a Linux EC2 instance. We noticed that on Mac
stty -ashows that ^Y is mapped todsusp. According to GNU docs on signal characters:We found that SSM sessions will not terminate if you first unmap the dsusp signal. Here’s how to do that:
Is there some way that the session manager plugin can be updated to not fire the dsusp signal when running on a Mac and a user enters
Ctrl-y?Same problem on Ctrl+O with description in #79, I closed it as duplicate. The title of this issue should be updated to reflect that the problem is about handling of Ctrl+key inputs, it would be clearer.
Sorry if this is a daft question: one of the responses to a related ticket mentioned that JOE puts the terminal in “raw” mode so it can handle ctrl-D itself. I don’t see anywhere that the SSM client puts the local terminal in raw mode so it can transmit those control characters to the remote end. Would that be a reasonable fix?
Someone else having the same
Ctrl-Jproblem here, no resolution