ทำไม wget ของฉันไม่ตายหลังจากการสูญเสียการเชื่อมต่อ ssh?

ฉันsshแก้ไขเซิร์ฟเวอร์ของฉันwget -r -np zzz.aaa/bbb/cccและเริ่มทำงานและมันก็เริ่มทำงาน จากนั้นการเชื่อมต่ออินเทอร์เน็ตของฉัน (ที่บ้านของฉัน) ก็ถูกขัดจังหวะและฉันก็กังวลว่าสมมติว่าwgetมันเป็นhupเพราะการsshเชื่อมต่อขาดหายไปดังนั้นเทอร์มินัลก็เสียชีวิต แต่ฉันsshก็รู้ว่ามันยังทำงานอยู่และวางเอาท์พุทwget.logและดาวน์โหลดสิ่งต่างๆ มีใครช่วยอธิบายให้ฉันฟังหน่อยว่าเกิดอะไรขึ้นที่นี่

นี่คือสิ่งที่psให้ฉัน:

PID   %CPU %MEM    VSZ    RSS TTY     STAT START   TIME COMMAND
32283  0.6 29.4 179824 147088 ?       S    14:00   1:53 wget -r -np zzz.aaa/bbb/ccc

อะไรที่มันไม่ (เครื่องหมายคำถาม) ?หมายถึงในคอลัมน์ของtty?

โปรแกรม (และสคริปต์) KILLสามารถเลือกที่จะไม่สนใจสัญญาณส่วนใหญ่ยกเว้นไม่กี่เช่น HUPสัญญาณสามารถจับและละเว้นถ้าซอฟแวร์เพื่อความประสงค์ที่จะ

นี้เป็นจากsrc/main.cของwgetแหล่งที่มา (เวอร์ชั่น 1.19.2):

/* Hangup signal handler.  When wget receives SIGHUP or SIGUSR1, it
   will proceed operation as usual, trying to write into a log file.
   If that is impossible, the output will be turned off.  */

ติดตั้งตัวจัดการสัญญาณอีกเล็กน้อย:

  /* Setup the signal handler to redirect output when hangup is
     received.  */
  if (signal(SIGHUP, SIG_IGN) != SIG_IGN)
    signal(SIGHUP, redirect_output_signal);

ดังนั้นดูเหมือนว่าwgetจะไม่เพิกเฉยต่อHUPสัญญาณ แต่มันเลือกที่จะดำเนินการต่อโดยเอาท์พุทของมันเปลี่ยนเส้นทางไปยังไฟล์บันทึก

ร้องขอในความคิดเห็น: ความหมายของ?ในTTYคอลัมน์ของผลลัพธ์จากpsในคำถามคือwgetกระบวนการไม่ได้เชื่อมโยงกับเทอร์มินัล / TTY อีกต่อไป TTY หายไปเมื่อการเชื่อมต่อ SSH ลดลง

ง่าย : ไม่ได้ยกเลิกในwget SIGHUPมันทำในSIGTERMและSIGINTแม้ว่า

ไม่มีอะไรในmanหน้า แต่ถ้าคุณส่งไปSIGHUPยังwgetกระบวนการคุณจะได้รับสิ่งนี้ใน terminal:

# in a different terminal while wget is running (with PID 12345)
kill -HUP 12345
# in the wget terminal
SIGHUP received.
Redirecting output to 'wget-log'.