ssh से डिस्कनेक्ट करते समय tmux सेशन की मौत

23

सारांश : मैं यह पता लगाने की कोशिश कर रहा हूं कि जब मैं ssh से डिस्कनेक्ट करता हूं तो मेरा tmux सत्र क्यों मर जाता है

विवरण :

मेरे पास tmux एक आर्क लिनक्स सिस्टम पर स्थापित है। जब मैं tmux सत्र शुरू करता हूं तो मैं इससे अलग हो सकता हूं और ssh सत्र सक्रिय होने के दौरान फिर से संलग्न कर सकता हूं। लेकिन अगर मैं अपना ssh सत्र समाप्त करता हूं तो tmux सेशन मार जाता है।

मुझे पता है कि यह सामान्य व्यवहार नहीं है क्योंकि मेरे पास अन्य प्रणाली है जहां tmux सत्र चालू रहता है भले ही ssh सत्र समाप्त हो गया हो और मैं नया ssh कनेक्शन स्थापित करने के बाद tmux सत्र में संलग्न हो सकता हूं। जिस सिस्टम में समस्या है और जो सही ढंग से काम करता है, उसके पास बहुत समान कॉन्फ़िगरेशन हैं, इसलिए मुझे यकीन नहीं है कि क्या जांचना है।

मैं tmux संस्करण 1.9a चला रहा हूं। जिस सिस्टम में समस्या है (जिसके लिए मेरे पास रूट एक्सेस है) के पास 3.17.4-1 का लिनक्स कर्नेल संस्करण है और जो सिस्टम सही काम करता है उसका कर्नेल संस्करण 3.16.4-1-ARCH (मेरे पास रूट नहीं है) प्रणाली)। मुझे संदेह है कि कर्नेल संस्करण समस्या का स्रोत है, हालांकि, मैंने देखा कि सिर्फ एक अंतर है।

मैंने सोचा कि मैं यह देखने के लिए कहूंगा कि क्या किसी ने भी इसी तरह की समस्या देखी है और संभव समाधान के बारे में जानता है।

समस्या के लिए सटीक कदम हैं:

मशीन को ssh
tmuxtmux शुरू करने के लिए चलाएँ
ctrl-B D अलग करने के लिए (इस बिंदु पर मैं के साथ reattach सकता है) tmux attach
करीब ssh सत्र (इस बिंदु पर tmux सत्र को मार दिया गया है, मैं इसे तब देख सकता हूं जब मैं एक अलग इंजन में रूट के रूप में लॉग इन होता हूं)
ssh और run के साथ फिर से कनेक्ट करें tmux attachऔर मुझे संदेश no sessionsऔर रनिंग tmux lsरिटर्न मिलता है failed to connect to server: Connection refused। यह समझ में आता है क्योंकि सेवा नहीं चल रही है। मुझे इससे कोई मतलब नहीं है कि जब मैं ssh सत्र से डिस्कनेक्ट करता हूं तो यह चरण 4 में क्यों मारा जाता है।

स्ट्रेस डेटा:

टिप्पणियों में से एक के जवाब में मैंने यह देखने के लिए स्टॉर्म का उपयोग किया कि सिस्टम tmux सर्वर प्रक्रिया को क्या कहता है। ऐसा लगता है कि जब मैं अपने ssh सत्र (टाइप करके exitया साथ ctrl-d) से बाहर निकलता हूं कि tmux प्रक्रिया को मारा जा रहा है। यहाँ स्ट्रेस आउटपुट के अंतिम भाग का एक स्निपेट है।

poll([{fd=4, events=POLLIN}, {fd=11, events=POLLIN}, {fd=6, events=POLLIN}], 3, 424) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
sendto(3, "\17", 1, 0, NULL, 0)         = 1
+++ killed by SIGKILL +++

मैंने इसकी तुलना एक अलग प्रणाली से की जहाँ tmux ठीक से काम करता है और उस प्रणाली पर tmux प्रक्रिया मेरे निकलने के बाद भी चलती रहती है। तो मूल कारण यह प्रतीत होता है कि जब मैं ssh सत्र बंद करता हूं तो tmux प्रक्रिया समाप्त हो रही है। मुझे यह पता लगाने में कुछ समय बिताने की आवश्यकता होगी कि क्यों, लेकिन मुझे लगा कि स्ट्रेस सुझाव उपयोगी होने के बाद से मैं अपने प्रश्न को अपडेट करूंगा।

tmux sshd

— गेब्रियल दक्षिणी
स्रोत

सुनिश्चित करने के लिए, कृपया चरण दर चरण वर्णन करें: मुझे लगता है कि आप ssh, tmux सत्र शुरू करते हैं, सत्र से अलग होते हैं, और shh को बंद करते हैं: जब आप फिर से ssh करते हैं, तो tmix सत्र में शामिल होने के लिए आपके पास कोई तरीका नहीं है? यानी, सत्र नहीं चल रहा है?

— ओलिवियर दुलैक

@OlivierDulac हाँ आपकी धारणा सही है। मैंने इन विवरणों को शामिल करने के लिए अपने प्रश्न को भी संपादित किया है।

— गेब्रियल दक्षिणी

आप ssh सत्र को कैसे बंद करते हैं? और आप tmux की पीआईडी और sshd की पिड पर एक और स्ट्रेस संलग्न कर सकते हैं, यह देखने के लिए कि क्या वह ssh कनेक्शन को बंद करते समय कुछ प्राप्त करता है (बहुत वर्बोज़, किसी फ़ाइल में रीडायरेक्ट)

— ओलिवियर दुलैक

@OlivierDulac सुझाव के लिए धन्यवाद। मैंने स्ट्रेस से जानकारी के साथ सवाल अपडेट किया है। ऐसा लगता है कि जब मैं ssh सत्र समाप्त करता हूं तो tmux सर्वर प्रक्रिया की मृत्यु हो रही है। मुझे नहीं लगता कि यह होने वाला है, इसलिए मुझे यह पता लगाने की आवश्यकता है कि ऐसा क्यों हो रहा है।

— गेब्रियल दक्षिणी

वर्बोज़ लॉगिंग सक्षम के साथ tmux शुरू करें और देखें कि क्या डिस्क लॉग ऑन करने पर कुछ भी प्रिंट हो जाए। इसके अलावा, tmux में और बाहर रिमोट मशीन पर TERM क्या है?

— जसोनव्रीयन

16

सिद्धांत

सिस्टमड सहित कुछ इनिट सिस्टम सेवा से संबंधित सभी प्रक्रियाओं को मारने के लिए एक सुविधा प्रदान करते हैं। सेवा आम तौर पर एक एकल प्रक्रिया शुरू करती है जो फोर्किंग द्वारा अधिक प्रक्रियाएं बनाती है और वे प्रक्रियाएं भी कर सकती हैं। ऐसी सभी प्रक्रियाओं को आमतौर पर सेवा का हिस्सा माना जाता है। सिस्टमड में यह cgroups का उपयोग करके किया जाता है ।

सिस्टमड में, सेवा से संबंधित सभी प्रक्रियाओं को तब मारा जाता है जब सेवा डिफ़ॉल्ट रूप से बंद हो जाती है। SSH सर्वर जाहिर तौर पर सेवा का हिस्सा है। जब आप सर्वर से कनेक्ट होते हैं, तो SSH सर्वर आमतौर पर कांटे और नई प्रक्रिया आपके SSH सत्र को संभालती है। SSH सत्र प्रक्रिया या इसके बच्चों से फोर्क करके, आपकी स्क्रीन या tmux सहित अन्य सर्वर साइड प्रक्रियाएँ शुरू की जाती हैं ।

किल्मोड और सॉकेट सक्रियण

KillModeनिर्देश का उपयोग करके डिफ़ॉल्ट व्यवहार को बदला जा सकता है । अपस्ट्रीम प्रोजेक्ट में AFAIK शामिल नहीं .serviceहै और इसमें वितरण के हिसाब से अलग-अलग फाइलें हैं। आपके सिस्टम पर SSH को सक्षम करने के आम तौर पर दो तरीके हैं। एक क्लासिक है ssh.serviceजो नेटवर्क पर लंबे समय तक चलने वाले एसएसएच डेमन को सुनता है। अन्य सॉकेट सक्रियण के माध्यम से ssh.socketहोता है sshd@.serviceजो कि इसके द्वारा चालू होता है जो केवल एक ही SSH सत्र के लिए चलता है।

समाधान

यदि सत्र के अंत में आपकी प्रक्रियाएं समाप्त हो जाती हैं, तो यह संभव है कि आप सॉकेट सक्रियण का उपयोग कर रहे हैं और यह सिस्टमड द्वारा मारा जाता है जब यह नोटिस करता है कि एसएसएच सत्र प्रक्रिया से बाहर निकल गया। उस मामले में दो समाधान हैं। ssh.serviceइसके बजाय सॉकेट सक्रियण का उपयोग करने से बचना है ssh.socket। दूसरे KillMode=processके Serviceअनुभाग में सेट करना है ssh@.service।

KillMode=processसेटिंग भी क्लासिक के साथ उपयोगी हो सकता है ssh.serviceके रूप में यह SSH सत्र प्रक्रिया या मारे गए बचा जाता है, स्क्रीन या tmux प्रक्रियाओं जब सर्वर बंद कर दिया या पुन: प्रारंभ हो जाता है।

भविष्य के नोट

इस जवाब ने स्पष्ट रूप से लोकप्रियता का एक स्तर प्राप्त किया। हालांकि यह ओपी के लिए काम करता था लेकिन ऐसा हो सकता है कि यह सिस्टमड-लॉगइंड डेवलपमेंट या कॉन्फ़िगरेशन के कारण भविष्य में किसी के लिए काम न करे । यदि आप इस उत्तर में वर्णन से भिन्न व्यवहार का अनुभव करते हैं, तो कृपया लॉगइंड सत्र पर प्रलेखन की जाँच करें।

— पावेल Šमरदा
स्रोत

डाउनवॉटर या ट्रोलिंग से कोई विशेष प्रतिक्रिया?

— पावेल Paमरदा

3

विस्तृत प्रतिक्रिया के लिए धन्यवाद। Sshd.service पर स्विच करने से समस्या ठीक हो गई।

— गेब्रियल दक्षिणी

मैं इस समस्या को सिस्टम पर प्रयोग करने के initबजाय अनुभव करता हूं systemd। लेकिन यह वैसे भी थोड़ा अलग है, मेरा प्रश्न देखें ।

— गेरिट

5

क्या आप SSH के लिए सॉकेट सक्रियण के साथ सिस्टमड का उपयोग करते हैं?

यदि हां, तो इसके साथ एक ज्ञात समस्या है । Systemd समर्थकों के अनुसार, यह वास्तव में एक विशेषता है - जब सत्र समाप्त हो जाता है, तो systemd सत्र द्वारा प्रायोजित सभी प्रक्रियाओं को मार देता है। (मैं देख सकता हूं कि यह उपयोगी है, लेकिन जीएनयू screenया tmux, मामले में, आप निश्चित रूप से ऐसा नहीं चाहते हैं और न ही अधिकांश अन्य मामलों में जहां उपयोगकर्ता पृष्ठभूमि प्रक्रियाओं को चला सकते हैं, निश्चित रूप से।)

यदि हां, तो से स्विच sshd.socketकरने का प्रयास करेंsshd.service ।

— mirabilos
स्रोत

1

मैं कहूंगा कि आप आम तौर पर SSH लॉगिन के लिए उस सुविधा का उपयोग नहीं करना चाहते हैं यदि आपके उपयोगकर्ताओं को लॉग आउट करने के बाद चलने वाली प्रक्रियाओं को चलाने की अनुमति है। यह स्क्रीन या tmux के लिए विशिष्ट नहीं है, बल्कि SSH (सर्वर साइड में किसी भी पृष्ठभूमि प्रक्रियाओं के साथ) के लिए है।

— पावेल Paमरदा

2

@ Pavel implimerda हाँ, मुझे लगा कि यह निहित है, लेकिन इसे और अधिक स्पष्ट करने के लिए पोस्ट को संपादित किया।

— मीराबिलोस 12

3

मैं Ubuntu और 16.04 (kde नीयन) पर tmux और स्क्रीन के साथ एक ही समस्या आ रही थी। जब ssh सत्र काट दिया गया था स्क्रीन / tmux समाप्त कर दिया गया था।

लंबी कहानी छोटी, सिस्टमड ने अपनी डिफ़ॉल्ट सेटिंग को मारकसुप्रोसेस में बदल दिया = हां इसलिए एक ssh सत्र छोड़ने के बाद इसके द्वारा बनाई गई हर प्रक्रिया को समाप्त कर दिया जाएगा।

आसान कमांड (कोशिश करने के घंटों बाद) इस कमांड का उपयोग करके स्क्रीन / tmux चलाएं

स्क्रीन के लिए

systemd-run --scope --user screen

Tmux के लिए

systemd-run --scope --user tmux

आप इसे आसान बनाने के लिए एक उपनाम बना सकते हैं

alias tmux= "systemd-run --scope --user tmux"

— mrbarletta
स्रोत

-bash: systemd-run: command not foundपर है Red Hat Enterprise Linux Server release 6.8 (Santiago)।

— gerrit

क्या यह तब काम करता है जब मुझे जड़ नहीं मिली है?

— गेरिट नेव

1

मैंने देखा कि अवांछित tmux / स्क्रीन हत्या व्यवहार उबंटू 18.04 एलटीएस पर नहीं होता है, केवल 16.04।

— सेठ

2

यह करने के लिए एक अन्य समाधान है, जिसमें से चलती की आवश्यकता नहीं है sshd.socketके लिए sshd.service, शुरू करने के लिए है tmuxएक systemd सेवा [0] के रूप में सर्वर। इस प्रकार, tmuxसर्वर पहले से ही चल रहा है जब आप एसएसएच में tmuxकमांड के बजाय एसएसएच सर्वर में आते हैं, इस प्रकार नहीं मारा जाएगा।

[०] https://wiki.archlinux.org/index.php/tmux#Autostart_with.sd

— गीत गाओ
स्रोत

क्या यह तब काम करता है जब मुझे जड़ नहीं मिली है?

— गेरिट नेव

हाँ, यह एक वैध समाधान है। लेकिन आप अभी भी SSH सत्र पर SSH सेवा को फिर से शुरू करने के साथ मामले को हल करना चाहते हैं। :)

— पावेल erमिरडा

दोस्तों, यदि आप OpenRC का उपयोग करते हैं, तो मैंने एक tmux initscript बनाई है जो ArchWiki में उल्लिखित सेवा फ़ाइल के समान है

— मेगवर 83

1

सबसे अच्छा उत्तर जो मुझे मिला है, IMO, किलिंग tmux सत्र से बचाव लॉगऑफ़ में दिया गया है :

इस "सुविधा" में ही अस्तित्व में है systemdपहले से है, लेकिन डेवलपर्स डिफ़ॉल्ट में एक परिवर्तन को प्रभावित करने का फैसला किया , एक सत्र से लॉग आउट पर बच्चे प्रक्रियाओं की समाप्ति के लिए सेटिंग को सक्षम करने के लिए।systemd

आप इस सेटिंग को अपने logind.conf( /etc/systemd/logind.conf) में वापस ला सकते हैं :

KillUserProcesses=no

— जोनाथन
स्रोत