`ปฏิเสธ -h 'และ` nohup` ทำงานอย่างมีประสิทธิภาพเหมือนกันหรือไม่?


18

disown

  • ทำให้เชลล์ไม่ส่ง SIGHUP ไปยังงานที่ถูกปฏิเสธเมื่อเชลล์ยกเลิกและ

  • ลบงานที่ถูกปฏิเสธจากการควบคุมงานของเชลล์

ผลลัพธ์แรกของวินาทีคืออะไร? กล่าวอีกนัยหนึ่งถ้ากระบวนการที่เริ่มต้นจากเชลล์ถูกลบออกจากการควบคุมงานของเชลล์ไม่ว่าด้วยวิธีใดเชลล์จะไม่ส่ง SIGHUP ไปยังกระบวนการเมื่อเชลล์หยุดทำงานหรือไม่

disown -h ยังคงเก็บกระบวนการภายใต้การควบคุมงานของเชลล์ หมายความว่าdisown -hทำให้กระบวนการยังคงได้รับ SIGHUP ที่ส่งจากเชลล์ แต่ตั้งค่าการกระทำของ SIGHUP โดยกระบวนการให้เป็น "เพิกเฉย"? nohupที่ฟังดูคล้ายกับ

$ sleep 123 & disown -h
[1] 26103
$ jobs
[1]+  Running                 sleep 123 &
$ fg 1
sleep 123
$ ^Z
[1]+  Stopped                 sleep 125
$ bg 1
[1]+ sleep 123 &
$ exit

$ ps aux | grep sleep
t        26103  0.0  0.0  14584   824 ?        S    15:19   0:00 sleep 123

ทำdisown -hและnohupทำงานอย่างมีประสิทธิภาพเหมือนกันถ้าเราไม่สนใจความแตกต่างในการใช้เทอร์มินัล

ขอบคุณ


ข้อแตกต่างที่ไม่ได้กล่าวถึงในที่นี้คือหากคุณไม่ได้ใช้nohupงานคุณจะต้องเปลี่ยนเส้นทาง stdin / stdout / stderr ออกจาก TTY (หากเชลล์เดิมของคุณเชื่อมต่อกับตัวเอง) (OTOH ฉันจริง ๆ แล้วคิดว่าวิธีปฏิบัติที่ดีกว่าอาศัยค่าเริ่มต้น hardcoded มหันต์เช่น./nohup.out)
ชาร์ลส์ดัฟฟี่

คำตอบ:


21

nohupและdisown -hไม่เหมือนกันทุกประการ

ด้วยdisownกระบวนการจะถูกลบออกจากรายการของงานในเปลือกโต้ตอบปัจจุบัน การรันjobsหลังจากเริ่มกระบวนการพื้นหลังและการรันdisownจะไม่แสดงกระบวนการนั้นเป็นงานในเชลล์ งานที่ถูกปฏิเสธจะไม่ได้รับ a HUPจากเชลล์เมื่อออก (แต่ดู note ตอนท้าย)

ด้วยdisown -h, งานจะไม่ถูกลบออกจากรายการของงาน, แต่เชลล์จะไม่ส่งHUPสัญญาณถ้ามันออก (แต่ดู note ที่ท้าย)

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

ความแตกต่างคือกระบวนการเริ่มต้นด้วยการnohupละเว้นHUPโดยไม่คำนึงถึงผู้ที่ส่งสัญญาณ กระบวนการปฏิเสธเป็นเพียงการไม่ส่งHUPสัญญาณจากเปลือกแต่อาจจะยังไม่ส่งสัญญาณจากเช่นkill -s HUP <pid>และจะไม่สนใจนี้

โปรดทราบว่าHUPจะถูกส่งไปยังงานของเชลล์เท่านั้นหาก

  • เชลล์เป็นเชลล์ล็อกอินและhuponexitตั้งค่าตัวเลือกเชลล์หรือ
  • เปลือกตัวรับHUPสัญญาณ

บิตที่เกี่ยวข้องจากbashคู่มือ (ความสำคัญของฉัน):

SIGNALS

[ ... ]

ออกจากเปลือกโดยค่าเริ่มต้นเมื่อได้รับการ SIGHUPก่อนที่จะออกจากเชลล์เชิงโต้ตอบSIGHUPจะส่งงานทั้งหมดให้ทำงานหรือหยุดทำงาน งานหยุดจะถูกส่งไปเพื่อให้มั่นใจว่าพวกเขาได้รับSIGCONT SIGHUPเพื่อป้องกันไม่ให้เปลือกจากการส่งสัญญาณไปยังงานเฉพาะก็ควรจะถูกลบออกจากตารางงานที่มีdisownในตัว (ดูSHELL BUILTIN COMMANDSด้านล่าง) หรือการทำเครื่องหมายที่จะได้รับใช้SIGHUP disown -h

หากhuponexitตั้งค่าตัวเลือกเชลล์แล้วshoptให้bashส่ง a SIGHUPไปยังงานทั้งหมดเมื่อเชลล์ล็อกอินแบบโต้ตอบออก

disown [-ar] [-h] [jobspec ... | pid ... ]

หากไม่มีตัวเลือกให้ลบแต่ละรายการออกjobspecจากตารางของงานที่ใช้งานอยู่ [ ... ] ถ้า-hตัวเลือกที่จะได้รับในแต่ละjobspecจะไม่ถูกลบออกจากตาราง แต่มีการทำเครื่องหมายเพื่อที่จะไม่ถูกส่งไปทำงานถ้าเปลือกได้รับSIGHUP SIGHUP[ ... ]

ที่เกี่ยวข้อง:


ฉันจะได้รับbash: disown: nohup: no such jobและเดียวกันsleepและจาก5 disown nohup sleep 5 &คุณหมายถึงอะไรโดยคำสั่งที่สองจากประโยคสุดท้าย?
Ruslan

@ Ruslan ใช่ฉันหายไป&ในนั้น (และคำสั่งของnohupและdisownก็ผิด) ขอบคุณ จะอัปเดตทันที
Kusalananda

ตัวอย่างเช่นunix.stackexchange.com/questions/484315/…
ทิม

@Tim ขออภัยที่มีการแก้ไขคำตอบมากเกินไป ใช้เวลาสักครู่ก่อนที่จะได้รับรอบฉัน ฉันเสร็จแล้ว
Kusalananda

ขอบคุณ disownทำให้เชลล์ไม่ได้ส่ง SIGHUP ไปยังชายด์โดยการลบชายด์ออกจากรายการงานของเชลล์ ทำdisown -hเช่นเดียวกันได้อย่างไร?
ทิม

4

พวกเขาแตกต่าง:

  • disown ลบงานออกจากตารางงานที่แอ็คทีฟ จากนั้นดำเนินการต่อด้วยงานปัจจุบัน ด้วย -h ความคืบหน้าจะไม่ถูกส่ง SIGHUP มันถูกทิ้งให้ตายด้วยกระสุนที่บรรจุไว้เมื่อมันได้รับ SIGHUP

  • nohup ละเว้น HUP อะไรแล้วที่จะได้รับการส่งผ่านไปยังขั้วโดย proccess nohup.outปิดแทนไปยังแฟ้ม

    nohup ถูกกำหนดโดย POSIX ในขณะที่ไม่อนุญาต


คุณหมายความว่าอย่างไร "ตายด้วยกระสุนที่บรรจุอยู่" การฆ่าโพรเซสแม่ไม่ได้อยู่ในตัวของมันเองและฆ่าเด็ก โปรแกรมที่ปิดเทอร์มินัลมักจะตายเนื่องจากความล้มเหลวที่เกี่ยวข้องกับความพยายามในการโต้ตอบกับตัวจัดการไฟล์ที่แนบกับ PTY ของเทอร์มินัล แต่ถ้า stdin / stdout / stderr ถูกเปลี่ยนเส้นทางที่อื่นจะไม่เกิดขึ้น
Charles Duffy
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.