SSH પર vim ફ્રીઝ થાય છે? VPN ને દોષ આપતા પહેલા stty તપાસો

આવા સેશન એડિટર શરૂ થાય ત્યારે જોડાયેલા રહે છે, પછી SSH પ્રક્રિયા સ્પષ્ટપણે જીવંત હોવા છતાં સ્ક્રીન અપડેટ થવાનું બંધ કરે છે. ટાઇપ કરવાથી કંઈ આવતું નથી, Ctrl-C કંઈ કરતું નથી એવું લાગે છે, અને સ્પષ્ટ નિષ્કર્ષ એ છે કે VPN એ કંઈક પડવા દીધું. મોટાભાગે ટનલ ઠીક હોય છે અને દૂરનું સ્યુડો-ટર્મિનલ એવી સ્થિતિમાં હોય છે જે કોઈએ ઇરાદો ન હતો, કારણ કે ઇકો, કેનોનિકલ ઇનપુટ અને ફ્લો નિયંત્રણ નેટવર્કમાં નહીં, ટર્મિનલમાં રહે છે. એ ત્રણમાંથી કયું ખસ્યું તે શોધવું બે આદેશોનું કામ છે.

ફ્રીઝ ટનલમાં નહીં, ટર્મિનલમાં રહે છે

સ્યુડો-ટર્મિનલ બાઇટ્સ કરતાં વધુ વહન કરે છે. તે લાઇન-ડિસિપ્લિન ફ્લેગ રાખે છે જે નક્કી કરે છે કે ઇનપુટ ઇકો થાય છે કે નહીં, વાંચન નવી લાઇનની રાહ જુએ છે કે નહીં, અમુક અક્ષરો સિગ્નલ બનાવે છે કે નહીં, અને કંટ્રોલ અક્ષરથી આઉટપુટ રોકી શકાય છે કે નહીં. ઇન્ટરેક્ટિવ એડિટર તે ટર્મિનલને આખા સમય માટે રો મોડમાં લઈ જાય છે અને બહાર નીકળતી વખતે અગાઉની સેટિંગ્સ પુનઃસ્થાપિત કરવાની ધારણા છે. જ્યારે પુનઃસ્થાપન થતું નથી, ત્યારે તમે જે શેલમાં પાછા આવો છો તે તમે છોડેલો શેલ નથી, જોકે કનેક્શન ક્યારેય તૂટ્યું ન હોય.

કંઈ પણ નિષ્કર્ષ કાઢતા પહેલા ટર્મિનલની સરખામણી કરો. સમાન એડિટર ચલાવતું બીજું સેશન સાબિત કરે છે કે ક્લાયંટ અને માર્ગ કામ કરી શકે છે; તે ટર્મિનલ વિશે કંઈ કહેતું નથી જેના ફ્લેગ તૂટેલા છે.

જે ટર્મિનલ ફ્રીઝ થયું તેના પર સેટિંગ્સ વાંચો

પહેલા ઉપકરણ ઓળખો, પછી તેની સ્થિતિના બંને સ્વરૂપ વાંચો. વાંચી શકાય તેવું સ્વરૂપ બતાવે છે કે શું સેટ છે, અને મશીન સ્વરૂપ તે છે જે તમે પછી પાછું આપી શકો છો.

tty
stty -a
stty -g

ત્રણ ફ્લેગ જૂથ આમાંના મોટાભાગના અહેવાલો સમજાવે છે. ઇકો સેટિંગ્સ નક્કી કરે છે કે કીસ્ટ્રોક બિલકુલ દેખાય છે કે નહીં, તેથી ઇકો બંધ ટર્મિનલ મૃત દેખાય છે જ્યારે શેલ દરેક અક્ષર મેળવે છે. કેનોનિકલ મોડ નક્કી કરે છે કે પ્રોગ્રામ ઇનપુટ એક વખતે એક લાઇન જુએ છે કે નહીં, તેથી કેનોનિકલ મોડમાં છોડેલું ટર્મિનલ રો મોડની એપ્લિકેશનને Enter સુધી કીઓ અવગણતી હોય તેવું દેખાડે છે. ફ્લો-નિયંત્રણ સેટિંગ્સ નક્કી કરે છે કે ટર્મિનલ XON અને XOFF અક્ષરોનું પાલન કરે છે કે નહીં, અને તે જૂથ ત્રણમાંથી સૌથી વિશ્વાસપાત્ર નકલી ફ્રીઝ બનાવે છે.

કંઈ બદલતા પહેલા આઉટપુટ રેકોર્ડ કરો, ખાસ કરીને જ્યારે સેશનમાં કોઈના આધારિત કસ્ટમ કી બાઇન્ડિંગ હોય. મશીન સ્વરૂપ સૌથી સુરક્ષિત રેકોર્ડ છે, એ શરત સાથે કે તે અમલીકરણ-આધારિત છે અને જે પ્રકારની સિસ્ટમે તે બનાવ્યું તે જ પ્રકારે પુનઃસ્થાપિત કરવું જોઈએ.

તે એક ટર્મિનલ સુધારો, તમે જે સેશનમાં ટાઇપ કરો છો તે નહીં

પ્રમાણભૂત સમારકામ મેન પેજમાં સૂચિબદ્ધ sane પ્રોફાઇલ પુનઃસ્થાપિત કરે છે, અને તે ફક્ત એક ટર્મિનલને અસર કરે છે. જો એડિટર હજી તે ટર્મિનલમાં અસંગ્રહિત કામ ધરાવે છે, તો કામ સંગ્રહિત ન થાય ત્યાં સુધી તેને એમ જ રહેવા દો.

બીજા શેલમાંથી, ફ્રીઝ થયેલા ઉપકરણને સ્પષ્ટ રીતે લક્ષ્ય બનાવો જેથી તમે જે ટર્મિનલમાં કામ કરો છો તે અકબંધ રહે.

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 સમસ્યા સૂચવે છે, જ્યારે એકલ કીસ્ટ્રોક પણ ગળી જતું અટકવું પેકેટના કદને નહીં, માર્ગ કે સર્વર તરફ નિર્દેશ કરે છે. ટર્મિનલના પુરાવા નેટવર્કના પુરાવાથી અલગ રાખો, કારણ કે બીજા સેશનમાં કામ કરતો એડિટર એ પુરાવો નથી કે પહેલું ટર્મિનલ ક્યારેય સ્વસ્થ હતું.