กระบวนการที่ล็อกอัพโดยไม่สนใจ SIGKILL นั้นทำงานได้ (ไม่ใช่ซอมบี้หรืออยู่ในโหมดสลีปที่ไม่สามารถหยุดทำงานได้) อยู่ในสถานะใด

ฉันมีกระบวนการที่หลายต่อหลายครั้งในตอนนี้หยุดการตอบสนองและดูเหมือนจะล็อคอย่างสมบูรณ์ มันไม่ตอบสนองต่อความพยายามใด ๆ ที่ strace หรือ peeking กับ gdb (gdb เพิ่งแฮงค์บน wait4 () syscall) กระบวนการนี้เป็นกระบวนการที่ทำงานได้และจะไม่รอใน syscall (/ proc / X / syscall: running) หรือในการนอนหลับแบบต่อเนื่อง (/ proc / X / สถานะ: State: R (running))

กระบวนการนี้อยู่ในสถานะใด? นี่อาจเป็นข้อผิดพลาดของเคอร์เนลในบางประเภทหรือไม่

กระบวนการเป็นสีแดงและนี่เกิดขึ้นสองสามครั้งแล้ว สิ่งเดียวที่สามารถฆ่ากระบวนการนั้นได้คือการรีบูตดูเหมือนว่า ระบบปฏิบัติการคือ Cent 7

แก้ไข: เวอร์ชันเคอร์เนลคือ 3.10.0-123.13.2.el7.x86_64 ลองอัปเดตเป็น 3.10.0-229.11.1.el7 เพื่อดูว่ามีความแตกต่างหรือไม่

process linux-kernel redis

— alienth
แหล่งที่มา

ใช้ GDB รุ่นใด ตามstackoverflow.com/questions/8978777/...รุ่นใหม่อาจจะทำงานได้ดีขึ้น

— Greg Bray

ขณะนี้ดูเหมือนว่าการตรวจสอบจะเป็นด้านเคอร์เนลมากกว่าเนื่องจากวิธีพิเศษที่แฮงค์ แต่ถ้าคุณไม่รังเกียจคุณสามารถเพิ่มข้อมูลเฉพาะของ Redis ได้หรือไม่ กระบวนการทำงานในขณะที่บล็อกและสิ่งต่าง ๆ เช่นนั้น ฉันได้รับข้อมูลบางอย่างจาก Nick Craver ผ่านทาง Twitter ดูเหมือนว่า Redis กำลังโหลดชุดข้อมูลขนาดใหญ่เมื่อเกิดเหตุการณ์นี้คือชุดข้อมูลที่โหลดเพิ่งรีสตาร์ทกระบวนการหรือด้วยวิธีอื่น (เช่นผ่านทาง DEBUG RELOAD หรือไพพ์ไลน์ของข้อมูลจำนวนมาก )? ขอบคุณ

@antirez ชุดข้อมูลกำลังถูกโหลดโดยสำเนา rdb จากอินสแตนซ์ redis อื่น การล็อกเกิดขึ้นหลังจาก Redis เริ่มต้นขึ้นและอ่านใน rdb ยักษ์ โดยเฉพาะอย่างยิ่งมันไม่ได้ล็อคในช่วงนี้บางครั้ง

— alienth

ฉันมีปัญหาแบบนี้เมื่อมีข้อผิดพลาด IO เท่านั้น คุณช่วยบอกเราเกี่ยวกับdmesgผลลัพธ์ได้ไหม

— Ho1

อะไร/proc/<pid>/stack(และ/proc/<pid>/task/*/stack) มี? กระบวนการนั้นมีหลายเธรดหรือไม่?

— Stéphane Chazelas

wait4 เป็น syscall ที่ระบุว่ากระบวนการกำลังรอการยกเลิกลูกของเขา นี่อาจชี้ประเด็นบางอย่างกับการจัดการสัญญาณ

บิตโหดร้าย แต่คุณอาจพยายามที่จะฆ่าลำดับชั้นของ kill -15 -$YourRedisPIDapp: -ก่อน PID หมายถึงว่า "PID และเด็ก" เนื่องจากดูเหมือนว่ากำลังรอการยุติของเด็กจึงอาจปลดล็อคได้

ถ้ามันใช้งานไม่ได้ลองตรวจสอบให้ลึก: ค้นหาสถานะกระบวนการสัญญาณของคุณด้วย grep ^Sig /proc/$YourRedisPID/status

คุณจะเห็นบางสิ่งเช่น:

SigQ:   8/62777
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000080
SigCgt: 0000000180004023

ตามที่กำหนดไว้ใน "fs / proc / array.c" ของเคอร์เนลซอร์ส "SigQ" คือจำนวนสัญญาณที่ค้างอยู่ / ขีด จำกัด สัญญาณที่รอดำเนินการ

หากจำนวนสัญญาณสูงเกินไปอาจบ่งบอกว่า "SIGKILL" ของคุณไม่ได้รับการจัดการเลย ฉันยังคงตรวจสอบไฟล์ "kernel / signal.c" เพื่อทำความเข้าใจการจัดการสัญญาณของสัญญาณพิเศษเหล่านี้

สำหรับความเข้าใจโดยตรงเกี่ยวกับผลลัพธ์ให้ลองใช้หนึ่งซับแสง: awk 'BEGIN{print "ibase=16;obase=2;"} /^Sig...:/{ print toupper($2)}' /proc/$YourRedisPID/status | BC_LINE_LENGTH=0 bc

ผลลัพธ์นี้ฉัน:

0
0
10000000
110000000000000000100000000100011

เริ่มกันเลยโดยส่งผลลัพธ์นี้มาให้เรา ฉันจะอัปเดตโพสต์ตามต้องการ

— Adrien M.
แหล่งที่มา

กระบวนการไม่ได้อยู่ใน wait4 () gdb จะหยุดทำงานบน wait4 () เมื่อพยายามเข้าถึงกระบวนการ กระบวนการนี้ไม่ได้อยู่ใน syscall ใด ๆ นอกจากนี้กระบวนการแขวนไม่มีลูก น่าเสียดายที่ฉันต้องรีบูทกล่อง ฉันจะรวบรวมข้อมูลที่คุณร้องขอเมื่อปัญหาเกิดขึ้นอีก

— ถึง

เอาต์พุตที่นี่: gist.githubusercontent.com/alienth/23685ad2ea46a7eade56/raw/ ...... อีกครั้ง proc กำลังเพิกเฉย SIGKILL มันไม่ได้อยู่ในตึกระฟ้า Proc ยังละเว้น SIGTERM

— alienth