เหตุใดกระบวนการพื้นหลัง Python ของฉันจึงสิ้นสุดลงเมื่อเซสชัน SSH ถูกยกเลิก

ฉันมีสคริปต์ทุบตีที่เริ่มต้นสคริปต์ python3 (เรียกมันว่าstartup.sh) โดยใช้บรรทัดสำคัญ:

nohup python3 -u <script> &

เมื่อฉันsshเข้าใช้งานโดยตรงและเรียกสคริปต์นี้สคริปต์ python ยังคงทำงานในพื้นหลังหลังจากที่ฉันออก อย่างไรก็ตามเมื่อฉันเรียกใช้สิ่งนี้:

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

กระบวนการจะสิ้นสุดลงทันทีที่sshดำเนินการเสร็จและปิดเซสชัน

ความแตกต่างระหว่างสองคืออะไร?

แก้ไข: สคริปต์หลามกำลังเรียกใช้บริการเว็บผ่านทางขวด

แก้ไข 2: ฉันยังพยายามสร้างสคริปต์เริ่มต้นที่เรียกstartup.shและเรียกใช้ssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> "sudo service start <servicename>"แต่ทำงานเหมือนเดิม

แก้ไข 3: อาจเป็นอย่างอื่นในสคริปต์ นี่คือส่วนใหญ่ของสคริปต์:

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)

ฉันจะตัดการเชื่อมต่อคำสั่งจากอินพุต / เอาต์พุตมาตรฐานและโฟลว์ข้อผิดพลาด:

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

sshต้องการตัวบ่งชี้ที่ไม่มีเอาต์พุตอีกต่อไปและไม่ต้องการอินพุตอีกต่อไป การมีสิ่งอื่นเป็นอินพุตและการเปลี่ยนเส้นทางหมายถึงเอาต์พุตsshสามารถออกได้อย่างปลอดภัยเนื่องจากอินพุต / เอาต์พุตไม่ได้มาจากหรือไปที่เทอร์มินัล ซึ่งหมายความว่าอินพุตต้องมาจากที่อื่นและเอาต์พุต (ทั้ง STDOUT และ STDERR) ควรไปที่อื่น

</dev/nullส่วนหนึ่งระบุ/dev/nullเป็น input <script>สำหรับ ทำไมจึงมีประโยชน์ที่นี่:

การเปลี่ยนเส้นทาง / dev / null ไปยัง stdin จะให้ EOF ทันทีไปยังการเรียกอ่านใด ๆ จากกระบวนการนั้น โดยทั่วไปจะมีประโยชน์ในการแยกกระบวนการออกจาก tty (กระบวนการดังกล่าวเรียกว่า daemon) ตัวอย่างเช่นเมื่อเริ่มต้นกระบวนการพื้นหลังจากระยะไกลผ่าน ssh คุณต้องเปลี่ยนเส้นทาง stdin เพื่อป้องกันไม่ให้กระบวนการรออินพุตในเครื่อง /programming/19955260/what-is-dev-null-in-bash/19955475#19955475

อีกวิธีหนึ่งการเปลี่ยนเส้นทางจากแหล่งอินพุตอื่นควรค่อนข้างปลอดภัยตราบใดที่sshเซสชันปัจจุบันไม่จำเป็นต้องเปิดไว้

ด้วย>/dev/nullส่วนที่เชลล์เปลี่ยนเส้นทางเอาต์พุตมาตรฐานไปเป็น / dev / null โดยพื้นฐานแล้วจะละทิ้งมัน >/path/to/fileยังจะทำงาน

ส่วนสุดท้าย2>&1คือการเปลี่ยนเส้นทาง STDERR ไปยัง STDOUT

มีแหล่งอินพุตและเอาต์พุตมาตรฐานสามแหล่งสำหรับโปรแกรม อินพุตมาตรฐานมักมาจากคีย์บอร์ดหากเป็นโปรแกรมแบบโต้ตอบหรือจากโปรแกรมอื่นหากประมวลผลเอาต์พุตของโปรแกรมอื่น โปรแกรมมักจะพิมพ์ไปยังเอาต์พุตมาตรฐานและบางครั้งพิมพ์ไปที่ข้อผิดพลาดมาตรฐาน ตัวอธิบายไฟล์ทั้งสาม (คุณสามารถนึกได้ว่าเป็น“ data pipes”) มักจะเรียกว่า STDIN, STDOUT และ STDERR

บางครั้งพวกเขาไม่ได้ตั้งชื่อพวกเขามีหมายเลข! ลำดับเลขในตัวสำหรับพวกเขาคือ 0, 1 และ 2 ตามลำดับ ตามค่าเริ่มต้นหากคุณไม่ระบุชื่อหรือหมายเลขหนึ่งอย่างชัดเจนคุณกำลังพูดถึง STDOUT

จากบริบทนั้นคุณสามารถเห็นคำสั่งด้านบนกำลังเปลี่ยนเส้นทางเอาต์พุตมาตรฐานไปยัง / dev / null ซึ่งเป็นที่ที่คุณสามารถทิ้งสิ่งที่คุณไม่ต้องการ (มักเรียกว่า bit-bucket) จากนั้นเปลี่ยนเส้นทางข้อผิดพลาดมาตรฐานไปยังเอาต์พุตมาตรฐาน ( คุณต้องใส่ & ด้านหน้าของปลายทางเมื่อคุณทำสิ่งนี้)

คำอธิบายสั้น ๆ คือ“ เอาท์พุททั้งหมดจากคำสั่งนี้จะถูกผลักเข้าไปในหลุมดำ” นั่นเป็นวิธีที่ดีวิธีหนึ่งที่จะทำให้โปรแกรมเงียบจริงๆ!
> / dev / null 2> & 1 หมายถึงอะไร | Xaprb

ดูที่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"คุณกำลังรันเชลล์สคริปต์ startup.sh เป็นคำสั่ง ssh

จากคำอธิบาย:

หากระบุคำสั่งคำสั่งจะถูกดำเนินการบนรีโมตโฮสต์แทนล็อกอินเชลล์

จากนี้จึงควรเรียกใช้สคริปต์จากระยะไกล

ความแตกต่างระหว่างสิ่งนั้นและการทำงานnohup python3 -u <script> &ในเครื่องเทอร์มินัลของคุณก็คือสิ่งนี้จะทำงานเป็นกระบวนการพื้นหลังแบบโลคัลในขณะที่คำสั่ง ssh พยายามที่จะเรียกใช้งานเป็นกระบวนการพื้นหลังระยะไกล

หากคุณต้องการรันสคริปต์ภายในเครื่องอย่าเรียกใช้ startup.sh ซึ่งเป็นส่วนหนึ่งของคำสั่ง ssh คุณอาจลองทำสิ่งที่ชอบssh -i <keyfile> -o StrictHostKeyChecking=no <user>@<hostname> && "./startup.sh"

หากคุณต้องการเรียกใช้สคริปต์จากระยะไกลและคุณต้องการให้กระบวนการนี้ดำเนินการต่อหลังจากเซสชัน ssh ของคุณสิ้นสุดลงคุณจะต้องเริ่มscreenเซสชันในโฮสต์ระยะไกลก่อน จากนั้นคุณต้องรันสคริปต์ python ภายในหน้าจอและมันจะยังคงทำงานต่อไปหลังจากที่คุณจบเซสชัน ssh ของคุณ

ดูคู่มือผู้ใช้ของหน้าจอ

ในขณะที่ฉันคิดว่าหน้าจอเป็นตัวเลือกที่ดีที่สุดของคุณหากคุณต้องใช้ nohup ให้พิจารณาการตั้งค่าshopt -s huponexitบนโฮสต์ระยะไกลก่อนที่จะใช้คำสั่ง nohup หรือคุณสามารถใช้disown -h [jobID]เพื่อทำเครื่องหมายกระบวนการดังนั้น SIGHUP จะไม่ถูกส่งไปยังกระบวนการ 1

ฉันจะทำงานต่อไปได้อย่างไรหลังจากที่ฉันออกจาก shell prompt เป็นเบื้องหลัง

ระบบของคุณใช้สัญญาณ SIGHUP (Hangup) ในการควบคุมสถานีหรือกระบวนการตาย คุณสามารถใช้ SIGHUP เพื่อโหลดไฟล์กำหนดค่าและเปิด / ปิดล็อกไฟล์ได้เช่นกัน กล่าวอีกนัยหนึ่งถ้าคุณออกจากระบบเทอร์มินัลของคุณงานที่ทำงานอยู่ทั้งหมดจะถูกยกเลิก เพื่อหลีกเลี่ยงปัญหานี้คุณสามารถผ่านตัวเลือก -h เพื่อบอกเลิกคำสั่ง ตัวเลือกนี้ทำเครื่องหมายแต่ละ jobID เพื่อให้ SIGHUP ไม่ได้ถูกส่งไปยังงานถ้าเชลล์ได้รับ SIGHUP

นอกจากนี้ให้ดูข้อมูลสรุปของวิธีการhuponexitทำงานเมื่อมีการออกเชลล์ฆ่าหรือดร็อป ฉันเดาว่าปัญหาปัจจุบันของคุณเกี่ยวข้องกับวิธีการสิ้นสุดเซสชันของเชลล์ 2

1. กระบวนการลูกทั้งหมดพื้นหลังหรือไม่ของเชลล์ที่เปิดผ่านการเชื่อมต่อ ssh ถูกฆ่าด้วย SIGHUP เมื่อการเชื่อมต่อ ssh ถูกปิดเฉพาะในกรณีที่มีการตั้งค่าตัวเลือก huponexit: เรียกใช้ shopt huponexit เพื่อดูว่าสิ่งนี้เป็นจริงหรือไม่

2. หาก huponexit เป็นจริงคุณสามารถใช้ nohup หรือแยกออกจากกันเพื่อแยกกระบวนการออกจากเชลล์ดังนั้นมันจะไม่ถูกฆ่าเมื่อคุณออกจาก หรือเรียกใช้สิ่งต่าง ๆ ด้วยหน้าจอ

3. หาก huponexit เป็นเท็จซึ่งเป็นค่าเริ่มต้นใน linuxes อย่างน้อยวันนี้งานที่อยู่เบื้องหลังจะไม่ถูกทำลายเมื่อออกจากระบบปกติ

4. แต่แม้ว่า huponexit เป็นเท็จแล้วหากการเชื่อมต่อ ssh ถูกฆ่าหรือลดลง (แตกต่างจากการออกจากระบบปกติ) กระบวนการที่อยู่ข้างหลังจะยังคงถูกฆ่า สิ่งนี้สามารถหลีกเลี่ยงได้โดยการไม่บอกหรือไม่ดังใน (2)

สุดท้ายนี้คือตัวอย่างของวิธีการใช้ shopt huponexit 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

อาจจะมีมูลค่าพยายาม -nตัวเลือกเมื่อเริ่มต้นssh? มันจะป้องกันการพึ่งพากระบวนการระยะไกลในท้องถิ่นstdinซึ่งแน่นอนปิดทันทีที่ssh sessionสิ้นสุด stdinและสิ่งนี้จะทำให้เกิดการเลิกจ้างราคาระยะไกลเมื่อใดก็ตามที่พยายามที่จะเข้าถึงมัน

ฉันสงสัยว่าคุณมีสภาพการแข่งขัน มันจะเป็นอะไรเช่นนี้:

• การเชื่อมต่อ SSH เริ่มต้นขึ้น
• SSH เริ่ม startup.sh
• startup.sh เริ่มต้นกระบวนการพื้นหลัง (nohup)
• startup.sh เสร็จสิ้น
• ssh เสร็จสิ้นและสิ่งนี้จะฆ่ากระบวนการลูก (เช่น nohup)

หาก ssh ไม่ตัดสั้นสิ่งต่อไปนี้จะเกิดขึ้น (ไม่แน่ใจเกี่ยวกับคำสั่งของทั้งสองนี้):

• nohup เริ่มต้นสคริปต์ python ของคุณ
• nohup ยกเลิกการเชื่อมต่อจากกระบวนการหลักและเทอร์มินัล

ดังนั้นขั้นตอนสำคัญสองขั้นตอนสุดท้ายจะไม่เกิดขึ้นเนื่องจากการเริ่มต้นและการสิ้นสุดก่อนที่จะไม่มีเวลาทำสิ่งนั้น

ฉันคาดหวังว่าปัญหาของคุณจะหายไปหากคุณนอนไม่กี่วินาทีในตอนท้ายของการเริ่มต้น ฉันไม่แน่ใจว่าคุณต้องการเวลาเท่าไร ถ้าเป็นเรื่องสำคัญที่จะต้องรักษาให้น้อยที่สุดบางทีคุณอาจมองอะไรบางอย่างใน proc เพื่อดูว่าปลอดภัยหรือไม่

ฟังดูเหมือนเป็นปัญหากับสิ่งที่pythonสคริปต์หรือpythonตัวเองกำลังทำอยู่ สิ่งที่ทำnohupจริง ๆ (การเปลี่ยนเส้นทางแบบง่าย ๆ แบบบาร์) เพียงแค่ตั้งค่าตัวจัดการสำหรับHUPสัญญาณเป็นSIG_IGN(ไม่สนใจ) ก่อนที่จะเรียกใช้โปรแกรม ไม่มีอะไรจะหยุดโปรแกรมการตั้งค่ามันกลับไปที่SIG_DFLหรือติดตั้งตัวจัดการของตัวเองเมื่อมันเริ่มทำงาน

สิ่งหนึ่งที่คุณอาจต้องการลองคือการใส่คำสั่งของคุณไว้ในวงเล็บเพื่อให้คุณได้เอฟเฟกต์สองทางแยกและpythonสคริปต์ของคุณจะไม่เป็นลูกของกระบวนการเชลล์อีกต่อไป เช่น:

( nohup python3 -u <script> & )

สิ่งที่อาจจะยังมีมูลค่าลอง (ถ้าคุณกำลังใช้อีกbashและไม่เปลือกอื่น) คือการใช้disownbuiltin nohupแทน หากทุกอย่างทำงานเป็นเอกสารสิ่งนี้ไม่ควรสร้างความแตกต่างใด ๆ แต่ในเชลล์เชิงโต้ตอบสิ่งนี้จะหยุดHUPสัญญาณจากการแพร่กระจายไปยังpythonสคริปต์ของคุณ คุณสามารถเพิ่มการปฏิเสธในบรรทัดถัดไปหรืออันเดียวกันด้านล่าง (หมายเหตุการเพิ่ม a ;หลังจาก&ข้อผิดพลาดเป็นbash):

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

หากการรวมกันด้านบนหรือบางส่วนของมันไม่ทำงานแน่นอนว่าสถานที่เดียวที่จะแก้ไขปัญหานี้อยู่ในpythonสคริปต์ของตัวเอง

ฉันคิดว่าเป็นเพราะงานเชื่อมโยงกับเซสชัน หลังจากนั้นจะสิ้นสุดงานของผู้ใช้ใด ๆ ก็จะสิ้นสุดลงเช่นกัน

หากnohupสามารถเปิดไฟล์ที่ส่งออกคุณอาจมีเงื่อนงำnohup.outสามารถเปิดไฟล์ที่ส่งออกของคุณอาจมีเงื่อนงำในมันเป็นไปไม่ได้อยู่ในเส้นทางเมื่อคุณเรียกใช้สคริปต์ผ่าน pythonssh

ฉันจะลองสร้างไฟล์บันทึกสำหรับคำสั่ง ลองใช้:

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