जब SSH सत्र समाप्त हो जाता है तो मेरी पायथन पृष्ठभूमि की प्रक्रिया क्यों समाप्त हो जाती है?


19

मेरे पास एक bash स्क्रिप्ट है जो एक python3 स्क्रिप्ट शुरू करता है (इसे कॉल करें startup.sh), कुंजी लाइन के साथ:

nohup python3 -u <script> &

जब मैं sshसीधे और इस स्क्रिप्ट को कॉल करता हूं , तो मेरे बाहर निकलने के बाद अजगर स्क्रिप्ट पृष्ठभूमि में चलती रहती है। हालाँकि, जब मैं इसे चलाता हूं:

ssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> "./startup.sh"

प्रक्रिया समाप्त होते ही sshइसे चलाना समाप्त कर दिया और सत्र बंद कर दिया।

दोनों के बीच क्या अंतर है?

EDIT: पाइथन स्क्रिप्ट बोतल के माध्यम से एक वेब सेवा चला रही है।

EDIT2: मैंने एक इनिट स्क्रिप्ट बनाने की कोशिश की जो कॉल startup.shऔर भाग गई ssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> "sudo service start <servicename>", लेकिन एक ही व्यवहार मिला।

EDIT3: हो सकता है कि यह स्क्रिप्ट में कुछ और हो। यहाँ स्क्रिप्ट का थोक है:

chmod 700 ${key_loc}

echo "INFO: Syncing files."
rsync -azP -e "ssh -i ${key_loc} -o StrictHostKeyChecking=no" ${source_client_loc} ${remote_user}@${remote_hostname}:${destination_client_loc}

echo "INFO: Running startup script."
ssh -i ${key_loc} -o StrictHostKeyChecking=no ${remote_user}@${remote_hostname} "cd ${destination_client_loc}; chmod u+x ${ctl_script}; ./${ctl_script} restart"

EDIT4: जब मैं अंत में एक नींद के साथ अंतिम पंक्ति चलाता हूं:

ssh -i ${key_loc} -o StrictHostKeyChecking=no ${remote_user}@${remote_hostname} "cd ${destination_client_loc}; chmod u+x ${ctl_script}; ./${ctl_script} restart; sleep 1"

echo "Finished"

यह कभी नहीं पहुंचता है echo "Finished", और मैं बोतल सर्वर संदेश देखता हूं, जिसे मैंने पहले कभी नहीं देखा था:

Bottle vx.x.x server starting up (using WSGIRefServer())...
Listening on <URL>
Hit Ctrl-C to quit.

मुझे "समाप्त" दिखाई देता है यदि मैं मैन्युअल रूप से SSH करता हूं और प्रक्रिया को स्वयं मारता हूं।

EDIT5: EDIT4 का उपयोग करते हुए, यदि मैं किसी भी समापन बिंदु के लिए अनुरोध करता हूं, तो मुझे एक पृष्ठ वापस मिल जाता है, लेकिन बोतल त्रुटियां समाप्त हो जाती हैं:

Bottle vx.x.x server starting up (using WSGIRefServer())...
Listening on <URL>
Hit Ctrl-C to quit.


----------------------------------------
Exception happened during processing of request from ('<IP>', 55104)

क्या कोई ऐसा तरीका है जिससे हम इस बारे में अधिक जानकारी प्राप्त कर सकते हैं कि अजगर लिपि क्या करती है? आप शायद अभी भी पूर्ण स्रोत कोड के बिना अनुमान लगा सकते हैं, लेकिन अजगर स्क्रिप्ट के बारे में अधिक जानने से हमें बेहतर शिक्षित अनुमान लगाने में मदद मिल सकती है।
ब्राचली

हां - सवाल में जोड़ा गया।
1440 में

हो सकता है कि स्क्रिप्ट कुछ जल्दी कर रही हो, किसी तरह संलग्न टर्मिनल या उस पर कुछ निर्भर करता है और यह एक टाइमिंग मुद्दा हो सकता है: यदि सत्र पहले कुछ सेकंड तक रहता है तो यह काम करता है, अन्यथा यह नहीं होता है। आपका सबसे अच्छा विकल्प यह हो सकता है straceकि यदि आप लिनक्स का उपयोग कर रहे हैं या trussयदि आप सोलारिस चला रहे हैं तो देखें कि यह कैसे / क्यों समाप्त होता है। उदाहरण के लिए ssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> strace -fo /tmp/debug ./startup.sh
सेलडा

क्या आपने &स्टार्ट अप स्क्रिप्ट के अंत में उपयोग करने की कोशिश की ? जोड़ा जा रहा है &पैरेंट आईडी (जब माता-पिता आईडी तो मर जाते हैं अपने बच्चों को करते हैं) किया जा रहा से अपने ssh सत्र की निर्भरता दूर ले जाता है। इसके अलावा मुझे लगता है कि यह इस पिछले पोस्ट पर आधारित एक डुप्लिकेट प्रश्न है । पिछले वाक्य में मैंने आपको जो पोस्ट सौंपी है, वह इस पोस्ट की एक डुप्लिकेट है जो बेहतर विवरण प्रदान कर सकती है।
याकूब ब्रायन

मैंने nohup ./startup.sh &पहले भी कोशिश की है , लेकिन यह एक ही व्यवहार था। startup.shपहले से ही एक कांटा शामिल है ( nohup python3 -u <script> &), इसलिए मुझे पूरा यकीन है कि मुझे फिर से कांटा लगाने की जरूरत नहीं है।
noendingqs

जवाबों:


11

मैं इसके मानक इनपुट / आउटपुट और त्रुटि प्रवाह से कमांड को डिस्कनेक्ट करूंगा:

nohup python3 -u <script> </dev/null >/dev/null 2>&1 &  

sshएक ऐसे संकेतक की आवश्यकता होती है जिसका कोई और आउटपुट न हो और उसे किसी और इनपुट की आवश्यकता न हो। कुछ और होने से इनपुट हो सकता है और आउटपुट का पुनर्निर्देशन का मतलब sshसुरक्षित रूप से बाहर निकल सकता है, क्योंकि इनपुट / आउटपुट टर्मिनल से आने या जाने के लिए नहीं है। इसका मतलब है कि इनपुट को कहीं और से आना है, और आउटपुट (STDOUT और STDERR दोनों) को कहीं और जाना चाहिए।

</dev/nullभाग निर्दिष्ट करता है /dev/nullके लिए इनपुट के रूप में <script>। यहाँ क्यों उपयोगी है:

स्टड को पुनर्निर्देशित / देव / अशक्त करना उस प्रक्रिया से किसी भी रीड कॉल को तत्काल ईओएफ देगा। यह आमतौर पर एक टटी (ऐसी प्रक्रिया को डेमन कहा जाता है) से एक प्रक्रिया को अलग करने के लिए उपयोगी है। उदाहरण के लिए, ssh पर दूरस्थ रूप से पृष्ठभूमि की प्रक्रिया शुरू करते समय, आपको स्थानीय इनपुट की प्रतीक्षा करने वाली प्रक्रिया को रोकने के लिए स्टड पुनर्निर्देशित करना होगा। /programming/19955260/what-is-dev-null-in-bash/19955475#19955475

वैकल्पिक रूप से, किसी अन्य इनपुट स्रोत से पुनर्निर्देशन अपेक्षाकृत सुरक्षित होना चाहिए, क्योंकि वर्तमान sshसत्र को खुला रखने की आवश्यकता नहीं है।

इस >/dev/nullभाग के साथ शेल मानक आउटपुट को / dev / null में अनिवार्य रूप से इसे त्याग देता है। >/path/to/fileभी चलेगा।

अंतिम भाग 2>&1STDERR को STDOUT पर पुनर्निर्देशित कर रहा है।

एक कार्यक्रम के लिए इनपुट और आउटपुट के तीन मानक स्रोत हैं। मानक इनपुट आमतौर पर कीबोर्ड से आता है अगर यह एक इंटरैक्टिव प्रोग्राम है, या किसी अन्य प्रोग्राम से अगर यह दूसरे प्रोग्राम के आउटपुट को प्रोसेस कर रहा है। कार्यक्रम आमतौर पर मानक आउटपुट पर प्रिंट करता है, और कभी-कभी मानक त्रुटि पर प्रिंट होता है। इन तीन फ़ाइल डिस्क्रिप्टर (आप उन्हें "डेटा पाइप" के रूप में सोच सकते हैं) अक्सर STDIN, STDOUT और STDERR कहलाते हैं।

कभी-कभी उनका नाम नहीं लिया जाता, वे गिने जाते हैं! उनके लिए अंतर्निहित संख्याएँ 0, 1, और 2 हैं, इस क्रम में। डिफ़ॉल्ट रूप से, यदि आप स्पष्ट रूप से नाम या नंबर नहीं देते हैं, तो आप STDOUT के बारे में बात कर रहे हैं।

उस संदर्भ को देखते हुए, आप ऊपर दिए गए कमांड को मानक आउटपुट को / dev / null में रीडायरेक्ट कर सकते हैं, जो एक ऐसी जगह है जिसे आप कुछ भी डंप कर सकते हैं जो आप नहीं चाहते (अक्सर बिट-बाल्टी कहा जाता है), फिर मानक आउटपुट में मानक त्रुटि को पुनर्निर्देशित करें ( जब आप ऐसा करते हैं तो आपको गंतव्य के सामने एक रखना होगा)।

इसलिए, संक्षिप्त विवरण, "इस कमांड से सभी आउटपुट को ब्लैक होल में भेज दिया जाना चाहिए।" एक प्रोग्राम को वास्तव में शांत बनाने का एक अच्छा तरीका है!
> / देव / अशक्त 2> और 1 का क्या अर्थ है? | Xaprb


nohup python3 -u <script> >/dev/null 2>&1 &और nohup python3 -u <script> > nohup.out 2>&1 &काम किया। मैंने सोचा था कि nohup स्वचालित रूप से सभी आउटपुट को पुनर्निर्देशित करता है - क्या अंतर है?
neverendingqs

@neverendingqs, nohupआपके दूरस्थ होस्ट पर आपके पास क्या संस्करण है ? एक POSIX nohupको पुनर्निर्देशित करने की आवश्यकता नहीं है stdin, जिसे मैंने याद किया, लेकिन यह अभी भी पुनर्निर्देशित होना चाहिए stdoutऔर stderr
ग्रीम

लगता है कि मैं साथ काम कर रहा हूं nohup (GNU coreutils) 8.21
neverendingqs

@neverendingqs, क्या nohupकोई संदेश प्रिंट करता है , जैसे nohup: ignoring input and appending output to ‘nohup.out’?
ग्रीम

हां - यह सटीक संदेश है।
neverendingqs

3

देखो man ssh:

 ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
     [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-L [bind_address:]port:host:hostport]
     [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
     [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
     [user@]hostname [command]

जब आप चलाते हैं ssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> "./startup.sh"तो आप शेल स्क्रिप्ट स्टार्टअप को चला रहे होते हैं। ssh कमांड के रूप में।

विवरण से:

यदि कमांड निर्दिष्ट है, तो इसे लॉगिन शेल के बजाय रिमोट होस्ट पर निष्पादित किया जाता है।

इसके आधार पर, इसे स्क्रिप्ट को दूरस्थ रूप से चलाना चाहिए।

nohup python3 -u <script> &आपके स्थानीय टर्मिनल में इसके और चलने का अंतर यह है कि यह एक स्थानीय पृष्ठभूमि प्रक्रिया के रूप में चलता है, जबकि ssh कमांड इसे दूरस्थ पृष्ठभूमि प्रक्रिया के रूप में चलाने का प्रयास करता है।

यदि आप स्क्रिप्ट को स्थानीय रूप से चलाने का इरादा रखते हैं, तो ssh कमांड के हिस्से के रूप में स्टार्टअप को न चलाएं। आप कुछ इस तरह की कोशिश कर सकते हैंssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> && "./startup.sh"

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

स्क्रीन उपयोगकर्ता का मैनुअल देखें

जबकि मुझे लगता है कि स्क्रीन आपके लिए सबसे अच्छा विकल्प है, अगर आपको नोह का उपयोग करना चाहिए, तो shopt -s huponexitनॉटअप कमांड चलाने से पहले दूरस्थ होस्ट पर सेटिंग पर विचार करें । वैकल्पिक रूप से, आप disown -h [jobID]इस प्रक्रिया को चिह्नित करने के लिए उपयोग कर सकते हैं ताकि SIGHUP इसे नहीं भेजा जाएगा। 1

बैकग्राउंड में एक शेल प्रॉम्प्ट से बाहर निकलने के बाद मैं नौकरी कैसे चलाता रहूं?

टर्मिनल को नियंत्रित करने या नियंत्रण प्रक्रिया की मृत्यु पर आपके सिस्टम द्वारा SIGHUP (Hangup) सिग्नल का उपयोग किया जाता है। आप कॉन्फ़िगरेशन फ़ाइलों को फिर से लोड करने और लॉग फ़ाइलों को भी खोलने के लिए SIGHUP का उपयोग कर सकते हैं। दूसरे शब्दों में, यदि आप अपने टर्मिनल से लॉगआउट करते हैं तो सभी चलने वाले काम समाप्त हो जाएंगे। इससे बचने के लिए आप कमांड को डिसाइड करने के लिए -h ऑप्शन पास कर सकते हैं। यह विकल्प प्रत्येक जॉब को चिह्नित करता है, ताकि यदि SIGHUP प्राप्त होता है, तो SIGHUP को नौकरी पर नहीं भेजा जाए।

इसके अलावा, यह देखें कि huponexitएक शेल के बाहर निकलने, मारे जाने या गिराए जाने पर कैसे काम करता है। मैं अनुमान लगा रहा हूं कि आपका वर्तमान मुद्दा शेल सत्र के समाप्त होने से संबंधित है। 2

  1. Ssh कनेक्शन पर खोले गए शेल के सभी चाइल्ड प्रोसेस, बैकग्राउंड या नहीं, SIGHUP के साथ मारे जाते हैं, जब ssh कनेक्शन केवल तभी बंद होता है जब huponexit ऑप्शन सेट होता है: शॉपटॉप huponexit देखें कि क्या यह सच है।

  2. अगर हूपोनेक्सिट सच है, तो आप नोह का उपयोग कर सकते हैं या शेल से प्रक्रिया को अलग करने के लिए डिस्चार्ज कर सकते हैं ताकि बाहर निकलने पर यह मारा न जाए। या, स्क्रीन के साथ चीजों को चलाएं।

  3. यदि हूपोनेक्सिट गलत है, जो इन दिनों कम से कम कुछ लिनक्स पर डिफ़ॉल्ट है, तो पृष्ठभूमि वाले काम सामान्य लॉगआउट पर नहीं मारे जाएंगे।

  4. लेकिन यहां तक ​​कि अगर हूपोनेक्सिट गलत है, तो यदि ssh कनेक्शन मारा जाता है, या ड्रॉप (सामान्य लॉगआउट से अलग), तो पृष्ठभूमि वाली प्रक्रियाएं अभी भी मारी जाएंगी। यह (2) के रूप में अस्वीकृत या नोह से बचा जा सकता है।

अंत में, यहां कुछ उदाहरण दिए गए हैं कि शॉप हूपोनेक्सिट का उपयोग कैसे करें। 3

$ shopt -s huponexit; shopt | grep huponexit
huponexit       on
# Background jobs will be terminated with SIGHUP when shell exits

$ shopt -u huponexit; shopt | grep huponexit
huponexit       off
# Background jobs will NOT be terminated with SIGHUP when shell exits

bashमैन पेज के अनुसार , huponexitकेवल इंटरैक्टिव गोले को प्रभावित करना चाहिए और स्क्रिप्ट को प्रभावित नहीं करना चाहिए - 'अगर हूपोनेक्सिट शेल विकल्प को शॉपट के साथ सेट किया गया है, तो बैश एक इंटरैक्टिव लॉगिन शेल से बाहर निकलने पर सभी नौकरियों के लिए एक SUBUP भेजता है।'
ग्रीम

2

शायद -nजब एक विकल्प शुरू करने की कोशिश कर लायक ssh? यह एक स्थानीय पर दूरस्थ प्रक्रिया निर्भरता को रोक देगा stdin, जो निश्चित रूप से ssh sessionसमाप्त होते ही बंद हो जाता है। और जब भी यह इसके उपयोग की कोशिश करता है, तो दूरस्थ मूल्य समाप्ति का कारण होगा stdin


बिना किसी सफलता के साथ कोशिश की = [।
neverendingqs

2

मुझे संदेह है कि आपके पास एक दौड़ की स्थिति है। यह कुछ इस तरह होगा:

  • SSH कनेक्शन शुरू
  • SSH स्टार्टअप शुरू करता है
  • startup.sh एक पृष्ठभूमि प्रक्रिया शुरू करता है (nohup)
  • स्टार्टअप.श खत्म
  • ssh खत्म, और यह बच्चे को मारता है प्रक्रियाओं (यानी nohup)

यदि ssh ने चीजों को छोटा नहीं किया है, तो निम्नलिखित हुआ होगा (इन दोनों के आदेश के बारे में निश्चित नहीं):

  • nohup आपके python script को शुरू करता है
  • nohup मूल प्रक्रिया और टर्मिनल से डिस्कनेक्ट करता है।

तो अंतिम दो महत्वपूर्ण चरण नहीं होते हैं, क्योंकि स्टार्टअप.श और ssh खत्म होने से पहले nohup को अपना काम करने का समय होता है।

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


अच्छी बात यह है कि इसके लिए खिड़की बहुत लंबी नहीं होगी, हालांकि - शायद केवल कुछ मिलीसेकंड। आप देख सकते हैं /proc/$!/commकि nohupअधिक या आंशिक रूप से आउटपुट का उपयोग नहीं किया गया है ps -o comm= $!
ग्रीम

यह सामान्य लॉगआउट के लिए काम करना चाहिए, लेकिन जब सत्र को गिरा दिया जाता है या मार दिया जाता है तो क्या होता है? क्या आपको अभी भी नौकरी से वंचित करने की आवश्यकता नहीं है इसलिए इसे पूरी तरह से नजरअंदाज कर दिया जाता है?
आइरिन

@RyanLoremIpsum: स्टार्टअप स्क्रिप्ट को केवल लंबे समय तक प्रतीक्षा करने की आवश्यकता है कि बच्चे की प्रक्रिया पूरी तरह से अलग हो जाए। उसके बाद, यह कोई फर्क नहीं पड़ता कि ssh सत्र क्या होता है। अगर कुछ और होता है तो संक्षिप्त विंडो में आपके ssh सत्र को मारता है, इसके बारे में बहुत कुछ नहीं है।
mc0e

@Gememe हाँ, मुझे लगता है कि यह बहुत जल्दी है, लेकिन मुझे अभी इतना नहीं पता है कि क्या कोई निश्चित नहीं है। इस पर एक आधिकारिक (या कम से कम जानकार और विस्तृत) स्रोत का सूचक उपयोगी होगा।
mc0e

कैसे के बारे में यह एक - lingrok.org/xref/coreutils/src/nohup.c
ग्रीम

1

यह pythonस्क्रिप्ट या pythonस्वयं क्या कर रही है , के साथ एक मुद्दे की तरह अधिक लगता है। वह सब जो nohupवास्तव में करता है (बार पुनर्निर्देशन को सरल बनाता है) प्रोग्राम चलाने से पहले HUPसिग्नल SIG_IGN(अनदेखा) के लिए हैंडलर सेट किया जाता है । SIG_DFLएक बार इसे चलाने के बाद प्रोग्राम को वापस सेट करने या अपने हैंडलर को स्थापित करने के लिए कुछ भी नहीं है ।

एक चीज जिसे आप आजमाना चाहते हैं, वह है कि आप कोष्ठक में अपनी कमांड को संलग्न करना है ताकि आपको एक डबल कांटा प्रभाव मिले और आपकी pythonस्क्रिप्ट अब शेल प्रक्रिया का बच्चा न हो। उदाहरण के लिए:

( nohup python3 -u <script> & )

एक और चीज जो एक कोशिश के लायक भी हो सकती है (यदि आप उपयोग कर रहे हैं bashऔर दूसरा शेल नहीं है) disownइसके बजाय बिलिन का उपयोग करना है nohup। अगर सब कुछ प्रलेखित के रूप में काम कर रहा है, तो इससे वास्तव में कोई फर्क नहीं पड़ना चाहिए, लेकिन एक इंटरैक्टिव शेल में यह HUPआपकी pythonस्क्रिप्ट के प्रचार से संकेत को रोक देगा । आप अगली पंक्ति में या नीचे के रूप में एक ही जोड़ जोड़ सकते हैं (एक के ;बाद एक जोड़ने &त्रुटि है bash):

python3 -u <script> </dev/null &>/dev/null & disown

यदि उपरोक्त या इसका कुछ संयोजन काम नहीं करता है, तो निश्चित रूप से मुद्दे को संबोधित करने का एकमात्र स्थान pythonस्क्रिप्ट में ही है।


क्या डबल कांटा प्रभाव पर्याप्त होगा (@ रियानलोरमइप्सम के उत्तर पर आधारित)?
neverendingqs

दोनों ने मुद्दे को हल नहीं किया = [। यदि यह एक पायथन मुद्दा है, तो क्या आपके पास एक विचार है जहां जांच शुरू करना है (यहां अजगर स्क्रिप्ट का बहुत अधिक पोस्ट नहीं किया जा सकता है)?
neverendingqs

@neverendingqs, यदि आपका मतलब huponexitसामान है, तो एक सब-रन में चलने का एक ही प्रभाव होना चाहिए disownक्योंकि इस प्रक्रिया को नौकरियों की सूची में नहीं जोड़ा जाएगा।
ग्रीम

@neverendingqs, ने मेरे उत्तर को अपडेट किया। भूल गए कि आपको पुनर्निर्देश का उपयोग करना चाहिए disown। उम्मीद मत करो कि यह हालांकि बहुत फर्क पड़ेगा। मुझे लगता है कि आप सबसे अच्छी शर्त pythonस्क्रिप्ट को बदलना है ताकि यह आपको बताए कि यह क्यों बाहर निकल रहा है।
ग्रीम

काम किए गए आउटपुट को रीडायरेक्ट किया गया ( unix.stackexchange.com/a/176610/52894 ), लेकिन मुझे यकीन नहीं है कि अंतर स्पष्ट रूप से इसे करने और इसे करने के बीच nohupहै।
neverendingqs

0

मुझे लगता है कि यह इसलिए है क्योंकि नौकरी सत्र से जुड़ी हुई है। एक बार समाप्त होने के बाद किसी भी उपयोगकर्ता की नौकरियां भी समाप्त हो जाती हैं।


2
लेकिन ऐसा क्यों है कि टर्मिनल प्राप्त करने, टाइप करने और कमांड चलाने, और बाहर निकलने से अलग है? इसे बंद करते ही दोनों सत्र बंद हो जाते हैं।
1438 में

सहमत हूं, मैं यह समझना चाहूंगा कि यह अपने स्वयं के टर्मिनल को मैन्युअल रूप से बंद करने से अलग क्यों नहीं है।
अवींद्र गोलचरण

0

यदि nohupआप इसकी आउटपुट फाइल खोल सकते हैं तो आपके पास एक सुराग हो सकता है nohup.out। यह संभव pythonहै कि जब आप स्क्रिप्ट के माध्यम से चलाते हैं तो वह रास्ते पर नहीं है ssh

मैं कमांड के लिए एक लॉग फाइल बनाने की कोशिश करूंगा। प्रयोग करके देखें:

nohup /usr/bin/python3 -u <script> &>logfile &

मैं sshस्क्रिप्ट को मैन्युअल रूप से चलाने के लिए उपयोग करता हूं , इसलिए मुझे लगता है कि python3 मार्ग में है।
neverendingqs

@neverendingqs क्या लॉगफ़ाइल में कुछ भी शामिल है?
बिलचोर

सामान्य से बाहर कुछ भी नहीं - स्टार्ट अप सामान्य दिखता है।
neverendingqs
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.