SSH വഴി vim ഫ്രീസ് ആകുന്നുണ്ടോ? VPN-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് stty പരിശോധിക്കുക

ഇത്തരം സെഷനുകൾ എഡിറ്റർ ആരംഭിക്കുമ്പോൾ കണക്റ്റ് ചെയ്തിരിക്കും, പിന്നീട് SSH പ്രോസസ് വ്യക്തമായി ജീവനോടെയിരിക്കുമ്പോഴും സ്ക്രീൻ പുതുക്കൽ നിർത്തും. ടൈപ്പ് ചെയ്യുന്നത് ഒന്നും നൽകുന്നില്ല, Ctrl-C ഒന്നും ചെയ്യുന്നില്ലെന്ന് തോന്നുന്നു, വ്യക്തമായ നിഗമനം VPN എന്തോ വീഴ്ത്തി എന്നാണ്. മിക്കപ്പോഴും ടണൽ കുഴപ്പമില്ലാതെയിരിക്കും, ദൂരെയുള്ള സ്യൂഡോ-ടെർമിനൽ ആരും ഉദ്ദേശിക്കാത്ത അവസ്ഥയിലായിരിക്കും, കാരണം എക്കോ, കാനോനിക്കൽ ഇൻപുട്ട്, ഫ്ലോ നിയന്ത്രണം എന്നിവ നെറ്റ്വർക്കിലല്ല, ടെർമിനലിലാണ് ജീവിക്കുന്നത്. ഈ മൂന്നിൽ ഏതാണ് നീങ്ങിയതെന്ന് കണ്ടെത്തുന്നത് രണ്ട് കമാൻഡുകളുടെ ജോലിയാണ്.

ഫ്രീസ് ടണലിലല്ല, ടെർമിനലിലാണ് ജീവിക്കുന്നത്

സ്യൂഡോ-ടെർമിനൽ ബൈറ്റുകളെക്കാൾ കൂടുതൽ വഹിക്കുന്നു. ഇൻപുട്ട് എക്കോ ചെയ്യുന്നുണ്ടോ, വായനകൾ പുതിയ വരിക്കായി കാത്തിരിക്കുന്നുണ്ടോ, ചില പ്രതീകങ്ങൾ സിഗ്നലുകൾ ഉണ്ടാക്കുന്നുണ്ടോ, നിയന്ത്രണ പ്രതീകത്താൽ ഔട്ട്പുട്ട് നിർത്താമോ എന്നിവ തീരുമാനിക്കുന്ന വരി-അച്ചടക്ക ഫ്ലാഗുകൾ അത് സൂക്ഷിക്കുന്നു. ഇന്ററാക്ടീവ് എഡിറ്റർ ആ ടെർമിനലിനെ മുഴുവൻ സമയവും അസംസ്കൃത മോഡിലാക്കുന്നു, പുറത്തുകടക്കുമ്പോൾ മുൻ ക്രമീകരണങ്ങൾ പുനഃസ്ഥാപിക്കേണ്ടതാണ്. പുനഃസ്ഥാപനം നടക്കാത്തപ്പോൾ, നിങ്ങൾ മടങ്ങിവരുന്ന ഷെൽ നിങ്ങൾ വിട്ട ഷെൽ അല്ല, കണക്ഷൻ ഒരിക്കലും മുറിഞ്ഞിട്ടില്ലെങ്കിലും.

എന്തും നിഗമനം ചെയ്യുന്നതിന് മുമ്പ് ടെർമിനലുകൾ താരതമ്യം ചെയ്യുക. അതേ എഡിറ്റർ ഓടിക്കുന്ന രണ്ടാമത്തെ സെഷൻ ക്ലയന്റും പാതയും ജോലി ചെയ്യാൻ കഴിയുമെന്ന് തെളിയിക്കുന്നു; ഫ്ലാഗുകൾ തകർന്ന ടെർമിനലിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

ഫ്രീസ് ആയ ടെർമിനലിൽ ക്രമീകരണങ്ങൾ വായിക്കുക

ആദ്യം ഉപകരണം തിരിച്ചറിയുക, പിന്നീട് അതിന്റെ അവസ്ഥയുടെ രണ്ട് രൂപങ്ങളും വായിക്കുക. വായിക്കാവുന്ന രൂപം എന്താണ് സെറ്റ് ചെയ്തിരിക്കുന്നതെന്ന് കാണിക്കുന്നു, യന്ത്ര രൂപം പിന്നീട് നിങ്ങൾക്ക് തിരികെ നൽകാവുന്നതാണ്.

tty
stty -a
stty -g

മൂന്ന് ഫ്ലാഗ് ഗ്രൂപ്പുകൾ ഈ റിപ്പോർട്ടുകളിൽ മിക്കതും വിശദീകരിക്കുന്നു. എക്കോ ക്രമീകരണങ്ങൾ കീസ്ട്രോക്കുകൾ ഒട്ടും കാണുമോ എന്ന് തീരുമാനിക്കുന്നു, അതിനാൽ എക്കോ ഓഫ് ആയ ടെർമിനൽ ഷെൽ ഓരോ പ്രതീകവും സ്വീകരിക്കുമ്പോഴും മരിച്ചതുപോലെ കാണപ്പെടും. കാനോനിക്കൽ മോഡ് പ്രോഗ്രാം ഇൻപുട്ട് ഒരു സമയത്ത് ഒരു വരിയായി കാണുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു, അതിനാൽ കാനോനിക്കൽ മോഡിൽ വിട്ട ടെർമിനൽ അസംസ്കൃത മോഡ് ആപ്ലിക്കേഷനെ Enter വരെ കീകൾ അവഗണിക്കുന്നതുപോലെ കാണിക്കുന്നു. ഫ്ലോ നിയന്ത്രണ ക്രമീകരണങ്ങൾ ടെർമിനൽ XON, XOFF പ്രതീകങ്ങൾ അനുസരിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു, ആ ഗ്രൂപ്പാണ് മൂന്നിൽ ഏറ്റവും വിശ്വസനീയമായ വ്യാജ ഫ്രീസ് ഉണ്ടാക്കുന്നത്.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഔട്ട്പുട്ട് രേഖപ്പെടുത്തുക, പ്രത്യേകിച്ച് സെഷനിൽ ആരെങ്കിലും ആശ്രയിക്കുന്ന ഇഷ്ടാനുസൃത കീ ബൈൻഡിംഗുകൾ ഉണ്ടെങ്കിൽ. യന്ത്ര രൂപമാണ് ഏറ്റവും സുരക്ഷിതമായ രേഖ, അത് നടപ്പാക്കലിനെ ആശ്രയിച്ചിരിക്കുന്നു എന്നതും അത് നിർമ്മിച്ച അതേ തരം സിസ്റ്റം തന്നെ പുനഃസ്ഥാപിക്കണം എന്നതുമുള്ള വ്യവസ്ഥയോടെ.

ആ ഒരു ടെർമിനൽ നന്നാക്കുക, നിങ്ങൾ ടൈപ്പ് ചെയ്യുന്ന സെഷനല്ല

സാധാരണ അറ്റകുറ്റപ്പണി മാന്വൽ പേജിൽ ലിസ്റ്റ് ചെയ്തിരിക്കുന്ന ആരോഗ്യകരമായ പ്രൊഫൈൽ പുനഃസ്ഥാപിക്കുന്നു, അത് ഒരു ടെർമിനലിനെ മാത്രം ബാധിക്കുന്നു. എഡിറ്റർ ആ ടെർമിനലിൽ ഇപ്പോഴും സേവ് ചെയ്യാത്ത ജോലി വഹിക്കുന്നുണ്ടെങ്കിൽ, ജോലി സേവ് ചെയ്യുന്നതുവരെ അതിനെ വിടുക.

മറ്റൊരു ഷെലിൽ നിന്ന്, ഫ്രീസ് ആയ ഉപകരണത്തെ വ്യക്തമായി ലക്ഷ്യമിടുക, നിങ്ങൾ ജോലി ചെയ്യുന്ന ടെർമിനൽ തൊടാതെ ഇരിക്കാൻ.

stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane

കേടായ ഡിസ്പ്ലേയുള്ള ശൂന്യ സ്ക്രീൻ തകർന്ന വരി-അച്ചടക്കത്തിൽ നിന്ന് വ്യത്യസ്ത പ്രശ്നമാണ്, reset പ്രോഗ്രാം ടെർമിനൽ ഇനിഷ്യലൈസേഷൻ ക്രമങ്ങൾ പുറപ്പെടുവിച്ച് അത് കൈകാര്യം ചെയ്യുന്നു. ആദ്യം അവസ്ഥ അറ്റകുറ്റപ്പണി പരീക്ഷിക്കുക, കാരണം അത് നിങ്ങൾക്ക് പരിശോധിക്കാവുന്ന ക്രമീകരണങ്ങൾ മാറ്റുന്നു, അതേസമയം reset ക്രമം സ്ക്രീൻ വീണ്ടും എഴുതുകയും എങ്ങനെ തകർന്നുവെന്ന് ഒന്നും വിശദീകരിക്കുകയും ചെയ്യുന്നില്ല.

വിശ്വസനീയമായ ഫ്രീസിന് പിന്നിലെ Ctrl-S കെണി

സോഫ്റ്റ്വെയർ ഫ്ലോ നിയന്ത്രണം സജീവമായിരിക്കുകയും സാധാരണ പ്രതീകങ്ങൾ അനുവദിച്ചിരിക്കുകയും ചെയ്യുമ്പോൾ, Ctrl-S ടെർമിനലിനോട് ഔട്ട്പുട്ട് അയയ്ക്കുന്നത് നിർത്താൻ പറയുന്നു, Ctrl-Q തുടരാൻ പറയുന്നു. സെഷൻ മുഴുവൻ സമയവും ജീവനോടെയിരിക്കും, ഒരു Ctrl-Q പലപ്പോഴും മുഴുവൻ അറ്റകുറ്റപ്പണിയാണ്, ഒരു ലോഗിലും ഒന്നും കാണപ്പെടുന്നില്ല, അങ്ങനെയാണ് ഈ ഫ്രീസ് ഇത്രയധികം എസ്കലേഷനുകളെ അതിജീവിക്കുന്നത്.

അനുമാനിക്കുന്നതിന് പകരം യഥാർത്ഥ ക്രമീകരണങ്ങൾ പരിശോധിക്കുക. ആരംഭ, നിർത്തൽ പ്രതീകങ്ങൾ പുനഃക്രമീകരിക്കാം അല്ലെങ്കിൽ പ്രവർത്തനരഹിതമാക്കാം, ഫ്ലോ നിയന്ത്രണം ഓഫ് ആയ ടെർമിനൽ രണ്ടിനോടും പ്രതികരിക്കില്ല.

അവസ്ഥ തിരികെ വന്നാൽ, അല്ലെങ്കിൽ SSH തന്നെ കുടുങ്ങിയാൽ

ആവർത്തിച്ചുള്ള മോശം അവസ്ഥ ഫ്ലാഗുകൾ പുനഃസ്ഥാപിക്കാതെ മാറ്റുന്ന എന്തിനെയോ ചൂണ്ടിക്കാണിക്കുന്നു: സ്റ്റാർട്ടപ്പ് ഫയൽ, റാപ്പർ സ്ക്രിപ്റ്റ്, തെറ്റായ വിൻഡോ റീസെറ്റ് ചെയ്യുന്ന മൾട്ടിപ്ലെക്സർ, അല്ലെങ്കിൽ അസംസ്കൃത മോഡ് പിടിച്ചുകൊണ്ട് മരിക്കുന്ന ആപ്ലിക്കേഷൻ. വ്യവസ്ഥയില്ലാത്ത റീസെറ്റിനുപകരം അവസ്ഥ റിപ്പോർട്ട് ചെയ്യുന്ന സോപാധിക പരിശോധന ചേർക്കുക, കാരണം പൊതുവായ റീസെറ്റ് കാരണം മറയ്ക്കുകയും ഉദ്ദേശിച്ച ക്രമീകരണങ്ങൾ അതിലംഘിക്കുകയും ചെയ്യാം.

സാധാരണ SSH ട്രാഫിക്കും കുടുങ്ങുകയോ അറ്റകുറ്റപ്പണി ഒന്നും മാറ്റാതിരിക്കുകയോ ചെയ്യുമ്പോൾ, ടെർമിനൽ സംശയിക്കപ്പെടുന്നത് നിർത്തുന്നു.

ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com

വലിയ കൈമാറ്റങ്ങളിൽ മാത്രം പ്രത്യക്ഷപ്പെടുന്ന തടസ്സം പാതയുടെ MTU പ്രശ്നം സൂചിപ്പിക്കുന്നു, ഒറ്റ കീസ്ട്രോക്കുകളും വിഴുങ്ങുന്ന തടസ്സം പാക്കറ്റ് വലുപ്പത്തെയല്ല, പാതയെയോ സർവറിനെയോ സൂചിപ്പിക്കുന്നു. ടെർമിനൽ തെളിവുകൾ നെറ്റ്വർക്ക് തെളിവുകളിൽ നിന്ന് വേർതിരിക്കുക, കാരണം രണ്ടാം സെഷനിൽ പ്രവർത്തിക്കുന്ന എഡിറ്റർ ആദ്യ ടെർമിനൽ ഒരിക്കലും ആരോഗ്യകരമായിരുന്നു എന്നതിന് തെളിവല്ല.