คู่มือการแก้ไขปัญหาเมื่อแสดงสถานะ Zimbra zmcontrol ว่า Host Services Stopped

ตัวอย่างสมมติ:อเล็กซ์ ผู้ดูแลระบบเซิร์ฟเวอร์ Zimbra ของบริษัทขนาดเล็ก ได้รับรายงานว่าเว็บเมลใช้งานไม่ได้หลังจากช่วงเวลาการบำรุงรักษาโฮสต์ตามปกติ จากเซิร์ฟเวอร์ อเล็กซ์รันคำสั่งzmcontrol statusและเห็นข้อความว่าmailbox Stoppedในขณะที่ LDAP และ MTA แสดงข้อความว่าRunningนี่เป็นสถานการณ์จำลอง ไม่ใช่รายงานการหยุดทำงานหรือการทดสอบจริง ขั้นตอนแรกที่สำคัญคือการค้นหาข้อผิดพลาดในการเริ่มต้นของส่วนประกอบที่ล้มเหลวก่อนที่จะรีสตาร์ทระบบทั้งหมดหรือลบไฟล์

zmcontrol statusรายงานนี้แสดงสถานะการให้บริการที่ระบบ Zimbra ที่ติดตั้งไว้รู้จัก บริการที่หยุดทำงานเป็นเพียงอาการ ไม่ใช่การวินิจฉัยปัญหา สาเหตุอาจเกิดจากระบบไฟล์เต็ม การพึ่งพาที่ไม่สำเร็จ ความขัดแย้งของพอร์ต การขัดข้องของกระบวนการ หรือปัญหาเฉพาะเวอร์ชัน ชื่อและบทบาทของบริการจะแตกต่างกันไปตามเวอร์ชันของ Zimbra และการใช้งานแบบเซิร์ฟเวอร์เดียวหรือหลายเซิร์ฟเวอร์ ข้อมูลอ้างอิงคำสั่งที่มีอยู่ในศูนย์เทคโนโลยีของ Zimbra มีเนื้อหาเก่าและที่เก็บถาวรไว้ ดังนั้นควรใช้เพื่อเป็นแนวทางเบื้องต้นและตรวจสอบการดำเนินการแก้ไขใดๆ กับเอกสารหรือการสนับสนุนสำหรับเวอร์ชันที่คุณติดตั้ง คู่มือนี้ได้รับการตรวจสอบกับข้อมูลอ้างอิงอย่างเป็นทางการของ Zimbra เมื่อวันที่ 6 ตุลาคม 2569

1. บันทึกสิ่งที่หยุดทำงานก่อนที่จะเปลี่ยนแปลงสิ่งใดๆ

เข้าสู่ระบบโฮสต์ Zimbra ที่ได้รับผลกระทบ เข้าสู่โหมดผู้ใช้ระบบปฏิบัติการ Zimbra และบันทึกเวอร์ชันผลิตภัณฑ์และสถานะทั้งหมดที่แสดง:

su - zimbra
zmcontrol -v
zmcontrol status

บันทึกผลลัพธ์และจดบันทึกเวลาที่ทำการตรวจสอบ ในกรณีสมมติของอเล็กซ์ รายละเอียดสำคัญคือ กล่องจดหมายหยุดทำงาน แต่ LDAP และ MTA ยังคงทำงานอยู่ หากส่วนประกอบหลายอย่างหยุดทำงาน ให้จดบันทึกลำดับและว่าการอัปเดตล่าสุด การรีบูต การเปลี่ยนแปลงใบรับรอง เหตุการณ์การจัดเก็บ หรือการแก้ไขการกำหนดค่าใด ๆ เกิดขึ้นก่อนปัญหา ในการใช้งานแบบหลายเซิร์ฟเวอร์ ให้ทำการตรวจสอบสถานะบนโฮสต์ที่ได้รับผลกระทบแต่ละเครื่อง โหนดกล่องจดหมาย โหนด LDAP และโหนด MTA มีบทบาทและการพึ่งพาที่แตกต่างกัน

เอกสารอ้างอิงคำสั่ง Zimbra อธิบายzmcontrol statusว่าการแสดงสถานะ "กำลังทำงาน" หรือ "หยุดทำงาน" สำหรับส่วนประกอบต่างๆ นั้นทำได้ แต่ตัวอย่างที่แสดงนั้นมาจาก ZCS เวอร์ชันเก่ากว่า ข้อมูลที่แสดงบนเซิร์ฟเวอร์ของคุณในปัจจุบันคือข้อมูลสินค้าคงคลังที่เกี่ยวข้อง โปรดดูเอกสารอ้างอิง Zimbra zmcontrolและตรวจสอบหมวดหมู่และบริบทเวอร์ชันก่อนที่จะนำขั้นตอนเฉพาะเวอร์ชันไปใช้

2. ตรวจสอบบันทึกการทำงานล่าสุดเพื่อหาสาเหตุของความล้มเหลวครั้งแรก

ตรวจสอบหาข้อผิดพลาดที่เกิดขึ้นในช่วงเวลาเดียวกับที่บริการหยุดทำงาน สำหรับการติดตั้งแบบแพ็กเกจทั่วไป ตำแหน่งที่มีประโยชน์ ได้แก่/var/log/zimbra.logและไฟล์ต่างๆ ภายใต้/opt/zimbra/logบันทึกที่ปรากฏจะขึ้นอยู่กับเวอร์ชันของ Zimbra และบริการที่เปิดใช้งาน

sudo tail -n 200 /var/log/zimbra.log
tail -n 200 /opt/zimbra/log/mailbox.log
tail -n 200 /opt/zimbra/log/zmmailboxd.out

เรียกใช้คำสั่งด้วยบัญชีที่สามารถอ่านไฟล์ได้ ใช้sudoเฉพาะเมื่อจำเป็นเท่านั้น มองหาข้อผิดพลาดที่เฉพาะเจาะจงที่สุดที่เกิดขึ้นก่อน ไม่ใช่แค่ข้อความ "บริการหยุดทำงาน" ซ้ำๆ ตัวอย่างเช่น "พื้นที่บนอุปกรณ์ไม่เพียงพอ" ข้อผิดพลาดในการผูกหรือที่อยู่ถูกใช้งาน การเชื่อมต่อ LDAP ล้มเหลว การเชื่อมต่อฐานข้อมูลล้มเหลว ข้อผิดพลาดด้านสิทธิ์ หรือการออกจากกระบวนการ Java ความล้มเหลวที่เกิดขึ้นต่อเนื่องในภายหลังอาจเป็นเพียงการสะท้อนถึงการพึ่งพาที่ล้มเหลวก่อนหน้านี้

สำหรับ Alex หากmailbox.logพบว่า mailboxd ไม่สามารถเชื่อมต่อกับ LDAP ได้ ขั้นตอนต่อไปคือการวินิจฉัยปัญหาการเชื่อมต่อ LDAP แทนที่จะรีสตาร์ท mailboxd ซ้ำๆ หน้าการแก้ไขปัญหาของ Zimbra แสดงรายการบันทึกเซิร์ฟเวอร์ทั่วไป รวมถึงmailbox.log, zimbra.log, nginx.log, และzmmailboxd.outและแนะนำให้รวบรวมส่วนที่เกี่ยวข้องกับเวลาเมื่อส่งต่อปัญหาไปยังระดับที่สูงขึ้น โปรดดูคำแนะนำในการแก้ไขปัญหาและการรวบรวมบันทึกของ Zimbra

3. ตัดปัญหาที่เกิดจากระดับโฮสต์ออกไป

ก่อนเริ่มระบบ ให้ตรวจสอบทรัพยากรและข้อมูลประจำตัวพื้นฐานของโฮสต์ การตรวจสอบแบบอ่านอย่างเดียวเหล่านี้สามารถเปิดเผยสาเหตุทั่วไปของระบบปฏิบัติการได้อย่างรวดเร็ว:

df -h /opt/zimbra /var/log
df -i /opt/zimbra /var/log
free -h
uptime
hostname -f
timedatectl status

หากวอลุ่มข้อมูลหรือบันทึกของ Zimbra เต็ม ให้ทำการล้างพื้นที่ว่างโดยใช้ขั้นตอนการเก็บรักษาและจัดการความจุตามปกติของระบบ อย่าลบที่เก็บข้อความ ไฟล์ฐานข้อมูล หรือบันทึกโดยพลการ การที่จำนวน inode เต็มอาจทำให้ไม่สามารถสร้างไฟล์ใหม่ได้ แม้ว่าระบบไฟล์จะดูเหมือนมีพื้นที่ว่างอยู่ก็ตาม หน่วยความจำเหลือน้อยหรือภาระงานสูงผิดปกติอาจทำให้บริการกล่องจดหมายที่ใช้ Java ไม่สามารถเริ่มต้นได้อย่างน่าเชื่อถือ

ตรวจสอบให้แน่ใจว่าชื่อโฮสต์แบบเต็ม (Fully Qualified Name) สามารถใช้งานได้ตามที่คาดหวังในระบบของคุณ หากชื่อโฮสต์หรือระเบียน DNS เปลี่ยนแปลง ให้เปรียบเทียบกับชื่อที่กำหนดค่าไว้ของเซิร์ฟเวอร์และโหนด Zimbra อื่นๆ ตรวจสอบการอัปเดตแพ็กเกจล่าสุด การต่ออายุใบรับรอง การเปลี่ยนแปลงไฟร์วอลล์ และการเชื่อมต่อพื้นที่จัดเก็บข้อมูลด้วย หากเซิร์ฟเวอร์ถูกรีบูต ให้ตรวจสอบว่าไดรฟ์ข้อมูลที่จำเป็นได้รับการเชื่อมต่อก่อนเริ่มใช้งานบริการ

4. แก้ไขปัญหาตามลำดับความสัมพันธ์ของส่วนประกอบต่างๆ

เริ่มต้นด้วยการตรวจสอบการพึ่งพาที่เก่าแก่ที่สุดที่ปรากฏในบันทึกหรือหยุดทำงานในเอาต์พุตสถานะ LDAP มีความสำคัญเป็นพิเศษเนื่องจากส่วนประกอบของ Zimbra ใช้ข้อมูลไดเร็กทอรีสำหรับการกำหนดค่าและการตรวจสอบสิทธิ์ หาก LDAP หยุดทำงาน บริการปลายทางอาจล้มเหลวแม้ว่าไฟล์และกระบวนการของตนเองจะดูเหมือนสมบูรณ์ ตรวจสอบรายการที่เกี่ยวข้องกับ LDAP ในไฟล์zimbra.logยืนยันการแก้ไขโฮสต์และการเชื่อมต่อระหว่างโหนด และตรวจสอบว่าวอลุ่มข้อมูล LDAP ถูกติดตั้งและสามารถเขียนได้ อย่าพยายามกู้คืนฐานข้อมูลหรือสร้างข้อมูลไดเร็กทอรีใหม่โดยอิงจากรายการตรวจสอบทั่วไป การกระทำเหล่านั้นอาจทำให้ข้อมูลสูญหายและต้องตรงกับเวอร์ชันผลิตภัณฑ์และสถานะการสำรองข้อมูล

หาก LDAP ทำงานได้ปกติแต่mailboxหยุดทำงาน ให้ตรวจสอบmailbox.logและzmmailboxd.outค้นหา ตรวจสอบพื้นที่ดิสก์ หน่วยความจำที่ใช้งานได้ และดูว่ากระบวนการอื่นครอบครองพอร์ตหรือที่อยู่ซึ่ง mailboxd ต้องการใช้งานหรือไม่ ผู้ดูแลระบบสามารถตรวจสอบซ็อกเก็ตที่กำลังรอรับการเชื่อมต่อได้ด้วยคำสั่ง:

sudo ss -ltnp

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

หากmtaการทำงานหยุดลง ให้ตรวจสอบข้อผิดพลาดในการถ่ายโอนอีเมลzimbra.logและยืนยันว่าโฮสต์ MTA สามารถเข้าถึงบริการ LDAP ที่กำหนดค่าไว้ได้ บทบาทของ MTA รวมถึงการรับและส่งต่ออีเมล และข้อความที่อยู่ในคิวอาจยังคงถูกเลื่อนออกไปในขณะที่การจัดส่งไม่พร้อมใช้งาน ตรวจสอบคิวหลังจากยืนยันคำสั่งที่เหมาะสมสำหรับการเผยแพร่ของคุณแล้วเท่านั้น อย่าล้าง ลบ หรือจัดคิวข้อความใหม่ในการตอบสนองครั้งแรก ภาพรวม MTA ของ Zimbra อธิบายความสัมพันธ์ระหว่าง Postfix, LDAP และคิวขาเข้า คิวที่ใช้งานอยู่ คิวที่ถูกเลื่อนออกไป และคิวที่ถูกพักไว้: สถาปัตยกรรมMTA และภาพรวมคิวของ Zimbra

5. ลองสตาร์ทเครื่องยนต์แบบควบคุมดู

เมื่อคุณรวบรวมหลักฐานและแก้ไขสาเหตุระดับโฮสต์ที่ระบุได้แล้ว ให้เริ่มบริการโดยใช้คำสั่งที่รองรับโดยเวอร์ชันที่ติดตั้งและบทบาทของเซิร์ฟเวอร์ของคุณ ในการติดตั้ง Zimbra Collaboration มาตรฐาน ผู้ดูแลระบบมักจะเรียกใช้zmcontrol startในฐานะผู้ใช้ Zimbra:

su - zimbra
zmcontrol start

สังเกตผลลัพธ์ของแต่ละส่วนประกอบ หากบริการใดรายงานFAILEDข้อผิดพลาด ให้บันทึกข้อความนั้นอย่างแม่นยำ และหยุดการพยายามเริ่มต้นซ้ำจนกว่าคุณจะตรวจสอบบันทึกที่เกี่ยวข้องแล้ว คำสั่งเริ่มต้นอาจแสดงข้อผิดพลาดที่เป็นประโยชน์ แต่การเริ่มต้นใหม่ซ้ำๆ อาจบดบังความล้มเหลวที่แท้จริงหรือขัดจังหวะส่วนประกอบที่ยังคงให้บริการผู้ใช้อยู่ หลีกเลี่ยงการเรียกใช้ คำสั่ง stop, shutdown, หรือ ที่ครอบคลุมกว้างๆ restartในระหว่างเหตุการณ์ที่กำลังเกิดขึ้น เว้นแต่คุณจะมีช่วงเวลาสำหรับการบำรุงรักษาและเข้าใจผลกระทบต่อทุกโหนด

อย่าลบไฟล์ PID, ยุติกระบวนการด้วย คำสั่ง `kill process` kill -9, แก้ไขการตั้งค่า Postfix ที่สร้างขึ้น หรือเรียกใช้คำสั่งซ่อมแซม LDAP/ฐานข้อมูล เพียงเพราะหน้าวิกิเก่าๆ ระบุไว้ ขั้นตอนเหล่านี้ขึ้นอยู่กับสถานะของกระบวนการและเวอร์ชันซอฟต์แวร์เป็นอย่างมาก ก่อนอื่นตรวจสอบให้แน่ใจว่ากระบวนการนั้นเป็นกระบวนการที่ถูกทิ้งร้างจริงๆ ปฏิบัติตามขั้นตอนของผู้จำหน่ายเฉพาะรุ่นอย่างถูกต้อง และตรวจสอบให้แน่ใจว่ามีข้อมูลสำรองล่าสุดอยู่ หน้าการแก้ไขปัญหาแบบสาธารณะของ Zimbra มีอายุแตกต่างกัน และบางหน้าก็ระบุไว้อย่างชัดเจนว่าเป็นเอกสารเก็บถาวรหรืออยู่ระหว่างการพัฒนา

6. ใช้ข้อมูลสถานะที่แสดงเพื่อจำกัดขอบเขตการดำเนินการต่อไป

• LDAP หยุดทำงาน และบริการหลายอย่างหยุดทำงาน:ตรวจสอบบันทึกการเริ่มต้นของ LDAP เอง, DNS, การแก้ไขชื่อโฮสต์, ปริมาณข้อมูล และการเชื่อมต่อระหว่างโหนด ก่อนที่จะวินิจฉัยบริการปลายทาง
• กล่องจดหมายหยุดทำงาน แต่ LDAP ยังทำงานอยู่:ให้ใช้บันทึกกล่องจดหมาย การตรวจสอบหน่วยความจำและดิสก์ของโฮสต์ และการตรวจสอบ Listener เพื่อค้นหาความล้มเหลวของ mailboxd ครั้งแรก
• MTA หยุดทำงาน แต่กล่องจดหมายยังทำงานอยู่:ตรวจสอบบันทึกของ MTA การเข้าถึง LDAP ข้อผิดพลาดในการสร้างการกำหนดค่า และตรวจสอบว่าเซิร์ฟเวอร์สามารถผูกกับตัวรับฟัง SMTP ที่กำหนดค่าไว้ได้หรือไม่
• อาจมีเพียงโปรแกรมบันทึกข้อมูล สถิติ โปรแกรมป้องกันสแปม หรือโปรแกรมป้องกันไวรัสเท่านั้นที่หยุดทำงาน:ตรวจสอบว่าส่วนประกอบนั้นจำเป็นต่อการรับส่งอีเมลที่ได้รับผลกระทบในเซิร์ฟเวอร์นี้หรือไม่ สถานะของส่วนประกอบนั้นอาจส่งผลต่อการตรวจสอบหรือการกรองโดยไม่ได้อธิบายถึงสาเหตุที่เว็บเมลใช้งานไม่ได้
• ส่วนประกอบทั้งหมดแสดงสถานะ "กำลังทำงาน" แต่ผู้ใช้ยังไม่สามารถเชื่อมต่อได้:ตรวจสอบพร็อกซีเว็บ, โหลดบาลานเซอร์ภายนอก, DNS, ไฟร์วอลล์, ใบรับรอง TLS และเอนด์พอยต์ที่เกี่ยวข้องกับลูกค้า การที่กระบวนการ "กำลังทำงาน" ไม่ได้หมายความว่าลูกค้าสามารถเข้าถึงบริการได้เสมอไป

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

7. ยืนยันการกู้คืนจากมุมมองของผู้ใช้

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

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

เมื่อใดควรยกระดับปัญหา

หาก LDAP ไม่สามารถเริ่มต้นได้ เกิดข้อผิดพลาดเกี่ยวกับความสมบูรณ์ของฐานข้อมูลหรือไดเร็กทอรี บริการล่มซ้ำๆ ระบบเป็นคลัสเตอร์แบบหลายโหนดที่มีสถานะไม่สอดคล้องกัน หรือการดำเนินการถัดไปที่เสนอเกี่ยวข้องกับการลบข้อมูลหรือการเปลี่ยนแปลงการกำหนดค่าที่สร้างขึ้น โปรดติดต่อฝ่ายสนับสนุนของ Zimbra หรือผู้ดูแลระบบที่รับผิดชอบการติดตั้งใช้งาน โปรดระบุเวอร์ชันและบิลด์ของ Zimbra เวอร์ชันของระบบปฏิบัติการ บทบาทและโครงสร้างของเซิร์ฟเวอร์zmcontrol statusผลลัพธ์ที่แน่นอน ประวัติการเปลี่ยนแปลงล่าสุด และส่วนหนึ่งของบันทึกที่ครอบคลุมช่วงเวลาที่เกิดความล้มเหลว โปรดปกปิดรหัสผ่าน คีย์ส่วนตัว โทเค็นการตรวจสอบสิทธิ์ และเนื้อหาข้อความส่วนตัวก่อนที่จะแชร์บันทึก

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