มีอะไรฆ่ากระบวนการของฉันและทำไม


614

แอปพลิเคชันของฉันทำงานเป็นกระบวนการพื้นหลังบน Linux ขณะนี้มันเริ่มต้นที่บรรทัดคำสั่งในหน้าต่าง Terminal

เมื่อเร็ว ๆ นี้ผู้ใช้กำลังดำเนินการแอปพลิเคชันอยู่ครู่หนึ่งและมันก็ตายอย่างลึกลับ ข้อความ:

ถูกฆ่าตาย

อยู่บนสถานี เรื่องนี้เกิดขึ้นสองครั้ง ฉันถามว่ามีใครบางคนที่เทอร์มินัลอื่นใช้คำสั่ง kill เพื่อฆ่ากระบวนการหรือไม่ เลขที่

ภายใต้เงื่อนไขใดที่ Linux จะตัดสินใจฆ่ากระบวนการของฉัน ฉันเชื่อว่าเชลล์แสดงข้อความ "kill" เนื่องจากกระบวนการตายหลังจากได้รับสัญญาณ kill (9) หาก Linux ส่งสัญญาณ kill ควรมีข้อความในบันทึกของระบบที่อธิบายว่าทำไมมันถึงถูกฆ่า?


23
linux ฆ่ากระบวนการของฉันและเข้าสู่ระบบใน / var / log / ข้อความบน redhat
Dean Hiller

1
ดูคำตอบนี้ได้ที่ unix.stackexchange.com
Richard

มีผู้เล่น 3 คนในเหตุการณ์นี้: (1) กระบวนการที่ (สาเหตุทั่วไป) ใช้หน่วยความจำมากเกินไปและทำให้เกิดเงื่อนไข OOM (2) เคอร์เนลที่ส่ง SIGKILL (สัญญาณ 9) เพื่อยุติและบันทึกความจริงในบางระบบ log like /var/log/messages(3) เชลล์ที่กระบวนการทำงานซึ่งเป็นกระบวนการที่พิมพ์การKilledแจ้งเตือนเมื่อสถานะการออกจากwaitpid(2)บ่งชี้ว่ากระบวนการลูกเสียชีวิตจากสัญญาณ 9
arielf

หลังจากอ่านคำตอบของ @ DeanHiller ฉันพบข้อความบันทึกใน Ubuntu ภายใต้/var/log/syslog
Dinei

คำตอบ:


403

หากผู้ใช้หรือดูแลระบบไม่ได้ฆ่าโปรแกรมเคอร์เนลอาจมี เคอร์เนลจะฆ่ากระบวนการภายใต้สถานการณ์พิเศษเช่นความอดอยากทรัพยากรมาก (คิดว่า mem + swap อ่อนเพลีย)


25
หากเคอร์เนลฆ่ากระบวนการมันจะใส่ข้อความในบันทึกที่ไหน?
sbq

186
ฉันเพิ่งเขียนโปรแกรมที่ malloc มีหน่วยความจำในลูป inifite หลังจากระบบช้าลง "Killed" ถูกแสดงในเครื่องเทอร์มินัลและกระบวนการถูกยกเลิก ไฟล์ /var/log/kern.log มีข้อมูลจำนวนมากเกี่ยวกับการยกเลิก ขอบคุณสำหรับตัวชี้
sbq

6
มันเกือบจะแน่นอน ฉันเห็นสิ่งนี้บ่อยมากเมื่อ TAing นักเรียนหลายคนลืมที่จะปล่อยวัตถุของพวกเขาและในที่สุดแอพจะเข้าถึงการใช้หน่วยความจำเสมือน 3GB ทันทีที่มันถึงจุดนั้นมันก็ถูกฆ่า
Herms

8
เมื่อ "โปรแกรมล่มเพียง" นั่นคือระบบปฏิบัติการที่ฆ่ากระบวนการ!
Bernd Jendrissek

79
ใช้dmesgเพื่อดูบันทึกเคอร์เนล: ที่นี่ฉันพบกระบวนการหลามของฉันถูกฆ่าโดยเคอร์เนลเนื่องจากการใช้หน่วยความจำเสมือนมาก
caneta

273

ลอง:

dmesg -T| grep -E -i -B100 'killed process'

ในกรณีที่-B100หมายถึงจำนวนเส้นก่อนที่จะฆ่าเกิดขึ้น

Omit -Tบน Mac OS


6
FYI, จากinfo egrep: "egrep เหมือนกับ grep -E. ... การร้องขอโดยตรงเช่น egrep หรือ fgrep ไม่ได้รับการสนับสนุน"
Air

9
ในกรณีของรูปแบบที่เรียบง่ายอย่างที่'killed process'คุณสามารถใช้grepแทนการegrepไม่มีการเปลี่ยนแปลงอื่น ๆ สำหรับรูปแบบที่ซับซ้อนมากขึ้นคุณจะเปลี่ยนแทนที่เช่นกับegrep -i -B100 'foo|ba[rz]' คำถาม & คำตอบนี้ให้รายละเอียดเพิ่มเติม grep -E -i -B100 'foo|ba[rz]'
อากาศ

2
ฉันยังแนะนำให้ใช้dmesg -Tเพื่อให้สามารถบันทึกเวลาที่อ่านได้
gukoff

171

ดูเหมือนบทความที่ดีเกี่ยวกับเรื่องนี้: ฝึกฝนนักฆ่า OOMฝึกฝนนักฆ่า

ส่วนสำคัญคือ Linux ทับซ้อนกันหน่วยความจำ เมื่อกระบวนการขอพื้นที่เพิ่มเติม Linux จะให้พื้นที่นั้นแม้ว่ากระบวนการนั้นจะอ้างสิทธิ์โดยกระบวนการอื่นภายใต้สมมติฐานว่าไม่มีใครใช้หน่วยความจำทั้งหมดที่พวกเขาร้องขอ กระบวนการนี้จะได้รับการใช้งานอย่างพิเศษของหน่วยความจำที่จัดสรรไว้เมื่อใช้งานจริงไม่ใช่เมื่อร้องขอ สิ่งนี้ทำให้การจัดสรรรวดเร็วและอาจทำให้คุณ "โกง" และจัดสรรหน่วยความจำได้มากกว่าที่คุณมี อย่างไรก็ตามเมื่อกระบวนการเริ่มใช้หน่วยความจำนี้ลีนุกซ์อาจรู้ว่ามันมีน้ำใจมากเกินไปในการจัดสรรหน่วยความจำที่มันไม่มีและจะต้องกำจัดกระบวนการเพื่อให้มีบางอย่างว่างเปล่า กระบวนการที่จะฆ่านั้นขึ้นอยู่กับคะแนนที่คำนึงถึงเวลาทำงานของบัญชี (กระบวนการที่ใช้เวลายาวนานนั้นปลอดภัยกว่า) การใช้หน่วยความจำ (กระบวนการโลภปลอดภัยน้อยกว่า) และปัจจัยอื่น ๆ รวมถึงค่าที่คุณสามารถปรับได้เพื่อทำให้กระบวนการมีโอกาสน้อยที่จะถูกฆ่า ทุกอย่างอธิบายไว้ในบทความโดยละเอียดยิ่งขึ้น

แก้ไข: และนี่คือบทความอื่นที่อธิบายได้ค่อนข้างดีว่ากระบวนการเลือกอย่างไร (ทำหมายเหตุประกอบกับตัวอย่างโค้ดเคอร์เนลบางส่วน) สิ่งที่ดีเกี่ยวกับเรื่องนี้คือมันมีความเห็นเกี่ยวกับเหตุผลที่อยู่เบื้องหลังbadness()กฎต่างๆ


3
ฉันรักการเชื่อมโยงบทความ ฉันขอแนะนำให้ทุกคนที่มีความสนใจในหัวข้อที่จะอ่านพวกเขา - โดยเฉพาะความคิดเห็นในบทความ lwn
Jon Bringhurst

4
"ลีนุกซ์จะให้ที่ว่างนั้นแม้ว่ามันจะอ้างสิทธิ์โดยกระบวนการอื่น" นั่นไม่ใช่วิธีการทำงานของหน่วยความจำเสมือนจริง ๆ ...
Mooing Duck

1
บทความนี้ค่อนข้างเก่า (2552) และไม่ใช่ฟังก์ชั่นทั้งหมดที่แนะนำในบทความนั้นอยู่ในการฉีด
อเล็กซ์

50

ก่อนอื่นให้ฉันอธิบายว่าทำไม OOMKiller ถึงถูกเรียกเมื่อใด?

สมมติว่าคุณมีหน่วยความจำ 512 RAM + 1GB Swap ตามทฤษฎีแล้ว CPU ของคุณมีการเข้าถึงหน่วยความจำเสมือนทั้งหมด 1.5GB

ตอนนี้บางครั้งทุกอย่างทำงานได้ดีภายใน 1.5GB ของหน่วยความจำทั้งหมด แต่ในทันที (หรือทีละน้อย) ระบบของคุณเริ่มใช้หน่วยความจำมากขึ้นเรื่อย ๆ และถึงจุดประมาณ 95% ของหน่วยความจำทั้งหมดที่ใช้

ตอนนี้กระบวนการใด ๆ ที่ร้องขอหน่วยความจำขนาดใหญ่จากเคอร์เนล เคอร์เนลตรวจสอบหน่วยความจำที่มีอยู่และพบว่าไม่มีวิธีใดที่จะสามารถจัดสรรกระบวนการของคุณให้หน่วยความจำเพิ่มเติม ดังนั้นจะพยายามเพิ่มหน่วยความจำที่เรียก / เรียกใช้ OOMKiller ( http://linux-mm.org/OOM) )

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

ฉันจะหาบันทึกของ OOMKiller ได้ที่ไหน

โดยทั่วไปในไดเรกทอรี / var / log อาจเป็น /var/log/kern.log หรือ / var / log / dmesg

หวังว่านี่จะช่วยคุณได้

โซลูชันทั่วไปบางประการ:

  1. เพิ่มหน่วยความจำ (ไม่สลับ)
  2. ค้นหาหน่วยความจำรั่วในโปรแกรมของคุณและแก้ไข
  3. จำกัด หน่วยความจำทุกกระบวนการที่สามารถใช้งานได้ (ตัวอย่างเช่นหน่วยความจำ JVM สามารถถูก จำกัด ได้โดยใช้ JAVA_OPTS)
  4. ดูบันทึกและ google :)

17

นี้เป็นลินุกซ์ออกจากจัดการหน่วยความจำ (OOM) กระบวนการของคุณได้รับเลือกเนื่องจาก ' ความไม่เหมาะสม ' - การรวมกันของความทันสมัยขนาดของที่พักอาศัย (หน่วยความจำที่ใช้งานแทนที่จะจัดสรรเพียง) และปัจจัยอื่น ๆ

sudo journalctl -xb

คุณจะเห็นข้อความเช่น:

Jul 20 11:05:00 someapp kernel: Mem-Info:
Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu:
Jul 20 11:05:00 someapp kernel: CPU    0: hi:  186, btch:  31 usd:  30
Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0
                                    active_file:722 inactive_file:4126 isolated_file:0
                                    unevictable:0 dirty:5 writeback:0 unstable:0
                                    free:12202 slab_reclaimable:3849 slab_unreclaimable:14574
                                    mapped:792 shmem:12802 pagetables:1651 bounce:0
                                    free_cma:0
Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968
Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated
Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0
Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB
Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB
Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages
Jul 20 11:05:00 someapp kernel: 0 pages in swap cache
Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul 20 11:05:00 someapp kernel: Free swap  = 0kB
Jul 20 11:05:00 someapp kernel: Total swap = 0kB
Jul 20 11:05:00 someapp kernel: 262141 pages RAM
Jul 20 11:05:00 someapp kernel: 7645 pages reserved
Jul 20 11:05:00 someapp kernel: 264073 pages shared
Jul 20 11:05:00 someapp kernel: 240240 pages non-shared
Jul 20 11:05:00 someapp kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jul 20 11:05:00 someapp kernel: [  241]     0   241    13581     1610      26        0             0 systemd-journal
Jul 20 11:05:00 someapp kernel: [  246]     0   246    10494      133      22        0         -1000 systemd-udevd
Jul 20 11:05:00 someapp kernel: [  264]     0   264    29174      121      26        0         -1000 auditd
Jul 20 11:05:00 someapp kernel: [  342]     0   342    94449      466      67        0             0 NetworkManager
Jul 20 11:05:00 someapp kernel: [  346]     0   346   137495     3125      88        0             0 tuned
Jul 20 11:05:00 someapp kernel: [  348]     0   348    79595      726      60        0             0 rsyslogd
Jul 20 11:05:00 someapp kernel: [  353]    70   353     6986       72      19        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  362]    70   362     6986       58      18        0             0 avahi-daemon
Jul 20 11:05:00 someapp kernel: [  378]     0   378     1621       25       8        0             0 iprinit
Jul 20 11:05:00 someapp kernel: [  380]     0   380     1621       26       9        0             0 iprupdate
Jul 20 11:05:00 someapp kernel: [  384]    81   384     6676      142      18        0          -900 dbus-daemon
Jul 20 11:05:00 someapp kernel: [  385]     0   385     8671       83      21        0             0 systemd-logind
Jul 20 11:05:00 someapp kernel: [  386]     0   386    31573      153      15        0             0 crond
Jul 20 11:05:00 someapp kernel: [  391]   999   391   128531     2440      48        0             0 polkitd
Jul 20 11:05:00 someapp kernel: [  400]     0   400     9781       23       8        0             0 iprdump
Jul 20 11:05:00 someapp kernel: [  419]     0   419    27501       32      10        0             0 agetty
Jul 20 11:05:00 someapp kernel: [  855]     0   855    22883      258      43        0             0 master
Jul 20 11:05:00 someapp kernel: [  862]    89   862    22926      254      44        0             0 qmgr
Jul 20 11:05:00 someapp kernel: [23631]     0 23631    20698      211      43        0         -1000 sshd
Jul 20 11:05:00 someapp kernel: [12884]     0 12884    81885     3754      80        0             0 firewalld
Jul 20 11:05:00 someapp kernel: [18130]     0 18130    33359      291      65        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18132]  1000 18132    33791      748      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18133]  1000 18133    28867      122      13        0             0 bash
Jul 20 11:05:00 someapp kernel: [18428]    99 18428   208627    42909     151        0             0 node
Jul 20 11:05:00 someapp kernel: [18486]    89 18486    22909      250      46        0             0 pickup
Jul 20 11:05:00 someapp kernel: [18515]  1000 18515   352905   141851     470        0             0 npm
Jul 20 11:05:00 someapp kernel: [18520]     0 18520    33359      291      66        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18522]  1000 18522    33359      294      64        0             0 sshd
Jul 20 11:05:00 someapp kernel: [18523]  1000 18523    28866      115      12        0             0 bash
Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child
Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB

12

ดังที่ dwc และ Adam Jaskiewicz ได้กล่าวว่าผู้กระทำผิดน่าจะเป็นนักฆ่า OOM อย่างไรก็ตามคำถามถัดไปที่ตามมาคือฉันจะป้องกันได้อย่างไร

มีหลายวิธี:

  1. ให้ RAM ระบบของคุณมากขึ้นถ้าคุณทำได้ (ทำได้ง่ายถ้าเป็น VM)
  2. ตรวจสอบให้แน่ใจว่านักฆ่า OOM เลือกกระบวนการที่แตกต่าง
  3. ปิดการใช้งาน OOM Killer
  4. เลือกดิสทริบิวเตอร์ distro ที่มาพร้อมกับ OOM Killer

ผมพบว่า (2) โดยเฉพาะอย่างยิ่งง่ายต่อการใช้ขอบคุณบทความนี้


2
มันเป็นแรมสำหรับฉัน ฉันอัพเกรดจาก 2 ถึง 4GB RAM และปัญหาหายไป ขณะนี้ปัญหาเกิดขึ้นกับบิล: P
กัส

9

โมดูล PAM ทรัพยากรขีด จำกัดที่เกิดว่าผลลัพธ์ที่คุณอธิบายกระบวนการของฉันเสียชีวิตอย่างลึกลับกับข้อความที่ถูกฆ่าตายในหน้าต่างคอนโซล ไม่มีการส่งออกบันทึกค่าในsyslogหรือในkern.log ด้านบนโปรแกรมช่วยให้ฉันค้นพบว่าว่าหลังจากหนึ่งนาทีของการใช้งาน CPU กระบวนการของฉันถูกฆ่าตาย


8

เครื่องมือเช่น systemtap (หรือตัวติดตาม) สามารถตรวจสอบตรรกะการส่งสัญญาณเคอร์เนลและรายงาน เช่นhttps://sourceware.org/systemtap/examples/process/sigmon.stp

# stap .../sigmon.stp -x 31994 SIGKILL
   SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME
   5609     bash             31994 find             9      SIGKILL

ifบล็อกการกรองในสคริปต์นั้นสามารถปรับเปลี่ยนเพื่อลิ้มรสหรือกำจัดเพื่อติดตามปริมาณการใช้สัญญาณทั่วทั้งระบบ สาเหตุสามารถแยกได้เพิ่มเติมโดยรวบรวม backtraces (เพิ่ม a print_backtrace()และ / หรือprint_ubacktrace()โพรบสำหรับเคอร์เนลและ userspace- ตามลำดับ)


4

ในสภาพแวดล้อม lsf (แบบโต้ตอบหรืออื่น ๆ ) หากแอปพลิเคชันเกินกว่าการใช้หน่วยความจำเกินกว่าเกณฑ์ที่กำหนดไว้ล่วงหน้าโดยผู้ดูแลระบบในคิวหรือคำขอทรัพยากรในการส่งไปยังคิวกระบวนการจะถูกฆ่าเพื่อให้ผู้ใช้รายอื่นไม่ตกเป็นเหยื่อ วิ่งหนี มันไม่ได้ส่งอีเมลทุกครั้งเมื่อทำเช่นนั้นขึ้นอยู่กับวิธีการตั้งค่า

ทางออกหนึ่งในกรณีนี้คือการค้นหาคิวที่มีทรัพยากรมากขึ้นหรือกำหนดความต้องการทรัพยากรที่มีขนาดใหญ่กว่าในการส่ง

คุณอาจต้องการตรวจสอบ man ulimit

แม้ว่าฉันจะจำไม่ได้ว่ามันulimitเกิดขึ้นKilledนานแล้วตั้งแต่ฉันต้องการมัน


2

เรามีปัญหาที่เกิดขึ้นซ้ำ ๆ ภายใต้ Linux ที่ไซต์ลูกค้า (Red Hat ฉันคิดว่า) ด้วย OOMKiller (นักฆ่าหน่วยความจำไม่พอ) ฆ่าทั้งแอปพลิเคชันหลักของเรา (นั่นคือเหตุผลที่เซิร์ฟเวอร์มีอยู่) และเป็นกระบวนการฐานข้อมูล

ในแต่ละกรณี OOMKiller เพิ่งตัดสินใจว่ากระบวนการใช้ทรัพยากรจำนวนมาก ... เครื่องไม่ได้ล้มเหลวเพราะขาดทรัพยากร แอปพลิเคชันหรือฐานข้อมูลไม่มีปัญหากับการรั่วไหลของหน่วยความจำ (หรือการรั่วไหลของทรัพยากรอื่น ๆ )

ฉันไม่ใช่ผู้เชี่ยวชาญด้าน Linux แต่ฉันค่อนข้างรวบรวมว่าเป็นอัลกอริทึมสำหรับการตัดสินใจว่าจะฆ่าอะไรเมื่อไหร่และสิ่งที่ต้องฆ่านั้นซับซ้อน นอกจากนี้ฉันยังได้รับการบอกกล่าว (ฉันไม่สามารถพูดถึงความถูกต้องของสิ่งนี้ได้) ว่า OOMKiller ถูกอบเข้าสู่เคอร์เนลและคุณไม่สามารถเรียกใช้มันได้


1
IIRC, OOMKiller ถูกเรียกเป็นทางเลือกสุดท้ายเท่านั้น ฉันคิดว่าระบบจะส่งสัญญาณไปยังแอพต่างๆขอให้พวกเขาสละทรัพยากรบางอย่างก่อนที่มันจะถูกบังคับให้เรียกใช้ OOMKiller ใช้เวลากับเม็ดเกลือเป็นมันเป็นเวลานาน ...
rmeador

1
คุณสามารถก็ไม่ใช้มัน มันถูกอบเข้าสู่เคอร์เนล แต่มีตัวเลือกในการปรับแต่งวิธีการทำงานและแม้กระทั่งกระบวนการที่มันน่าจะฆ่า มันทำงานเมื่อระบบทั้งหมดมีหน่วยความจำไม่เพียงพอเมื่อกระบวนการเฉพาะกำลังใช้งานมากเกินไป ดูคำตอบของฉันสำหรับรายละเอียดเพิ่มเติม
Adam Jaskiewicz

6
ไม่ใช้งาน oomkiller ค่อนข้างง่าย echo "2" > /proc/sys/vm/overcommit_memory
.. GitHub หยุดช่วยน้ำแข็ง

Red Hat ไม่ต้องการอนุญาตให้มีการเปลี่ยนแปลง: sudo echo "2" > /proc/sys/vm/overcommit_memory/ proc / sys / vm / overcommit_memory: การอนุญาตถูกปฏิเสธ
Brent Faust

2
ลองecho 2 | sudo tee /proc/sys/vm/overcommit_memory
Hypershadsy

2

ในกรณีของฉันสิ่งนี้เกิดขึ้นกับพนักงานคิว Laravel บันทึกของระบบไม่ได้พูดถึงการฆ่าใด ๆ ดังนั้นฉันจึงดูเพิ่มเติมและปรากฎว่าคนงานกำลังฆ่าตัวตายเพราะงานที่เกินขีด จำกัด หน่วยความจำ (ซึ่งตั้งไว้ที่ 128M เป็นค่าเริ่มต้น)

ใช้งานผู้ปฏิบัติงานคิวด้วย--timeout=600และ--memory=1024แก้ไขปัญหาให้ฉัน


0

ผู้ใช้มีความสามารถในการฆ่าโปรแกรมของตัวเองโดยใช้ kill หรือ Control + C แต่ฉันได้รับความประทับใจว่าไม่ใช่สิ่งที่เกิดขึ้นและผู้ใช้บ่นกับคุณ

รูทมีความสามารถในการฆ่าโปรแกรมแน่นอน แต่ถ้าใครบางคนมีรูทบนเครื่องของคุณและกำลังฆ่าสิ่งต่าง ๆ คุณมีปัญหาใหญ่กว่า

หากคุณไม่ใช่ sysadmin sysadmin อาจตั้งค่าโควต้าสำหรับ CPU, RAM, การใช้ดิสก์ ort และกระบวนการฆ่าอัตโนมัติที่เกินพวกเขา

นอกเหนือจากที่คาดเดาไว้ฉันไม่แน่ใจหากไม่มีข้อมูลเพิ่มเติมเกี่ยวกับโปรแกรม


6
CTRL-C ส่งการฆ่าที่แตกต่างจากรายงาน OP (SIGINT (2) ตามที่ฉันจำได้ในขณะที่โปรแกรมกำลังรับ SIGKILL (9))
Powerlord

0

ฉันพบปัญหานี้เมื่อเร็ว ๆ นี้ ในที่สุดฉันพบว่ากระบวนการของฉันถูกฆ่าหลังจากการอัปเดต zypper ของ Opensuse ถูกเรียกโดยอัตโนมัติ หากต้องการปิดใช้งานการอัปเดต zypper แก้ปัญหาของฉันได้


ฉันเห็นปัญหาเดียวกัน คุณติดตามกระบวนการใดที่ทำให้กระบวนการของคุณหยุดชะงักได้อย่างไร ดูเหมือนว่ามีเครื่องมือในการตรวจสอบว่าใครส่ง SIGKILL ไปยังกระบวนการ
Howy

0

แก้ไขปัญหานี้โดยการเพิ่มขนาดการสลับ :

/ubuntu/1075505/how-do-i-increase-swapfile-in-ubuntu-18-04


3
โปรดอย่าโพสต์คำตอบแบบลิงก์อย่างเดียวสำหรับคำถาม Stack Exchange อื่น ๆ ให้รวมส่วนที่สำคัญของคำตอบไว้ที่นี่และปรับคำตอบสำหรับคำถามเฉพาะนี้
เสียงบี๊บสองครั้ง
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.