Tại sao Linux kdump không ghi vào / var / crash?


10

Nó lại xảy ra! Tôi có 4 máy chủ bị sập định kỳ và không có thông tin nào được in vào nhật ký hệ thống hoặc bảng điều khiển nối tiếp.

Ngoài ra, dịch vụ kdump của Linux không ghi các kết xuất lõi đến vị trí mặc định của /var/crash.

  • Bạn có thể giúp tôi tìm hiểu tại sao?
  • Có vấn đề gì không nếu hệ thống tập tin gốc của tôi là một khối LVM?

Đây là những gì tôi đã thử.

  1. Hệ thống của tôi là Science Linux 6.5 với kernel mới nhất.

    [root@host1 ~]# uname -r
    2.6.32-431.11.2.el6.x86_64
    [root@host1 ~]# cat /etc/issue
    Scientific Linux release 6.5 (Carbon)
    
  2. Tệp /etc/kdump.confnày là tệp vanilla chứa các cài đặt mặc định. Hầu hết các dòng được nhận xét, chỉ có hai dòng hoạt động cho pathcore_collector.

    #net my.server.com:/export/tmp
    #net user@my.server.com
    path /var/crash
    core_collector makedumpfile -c --message-level 1 -d 31
    #core_collector scp
    
  3. Tôi đảm bảo rằng kdumpdịch vụ đang chạy và kdumpkhông cần phải xây dựng lại initrd.

    [root@host1 ~]# chkconfig --list kdump
    kdump           0:off   1:off   2:off   3:on    4:on    5:on    6:off
    [root@host1 ~]# /etc/init.d/kdump restart
    Stopping kdump:                                            [  OK  ]
    Starting kdump:                                            [  OK  ]
    [root@host1 ~]# 
    
  4. Sau đó, tôi buộc một sự cố Kernel sử dụng các lệnh này được mượn từ Hướng dẫn triển khai RHEL6: Chương 29. Dịch vụ khôi phục sự cố kdump :

    Sau đó nhập các lệnh sau tại dấu nhắc shell:

    echo 1 > /proc/sys/kernel/sysrq
    echo c > /proc/sysrq-trigger
    

    Điều này sẽ buộc nhân Linux bị sập

  5. Hệ thống gặp sự cố. Tôi có thể xem tiến trình trên bàn điều khiển nối tiếp của tôi. Tôi thấy tin nhắn Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2, nhưng ngay sau đó tôi thấy tin nhắn lạ Usage: fsck.ext4, trông giống như một thứ gì đó đang vô tình gọi fsckthay vì bất cứ điều gì nó nên làm. Tôi không thấy đề cập đến lỗi hết bộ nhớ hoặc bất cứ điều gì.

    host1.example.org login: SysRq : Trigger a crash
    BUG: unable to handle kernel NULL pointer dereference at (null)
    ...
    ... skipping 50 lines of output
    ...
    Creating block device ram8
    Creating block device ram9
    Creating Remain Block Devices
    Making device-mapper control node
    Scanning logical volumes
      Reading all physical volumes.  This may take a while...
      No volume groups found
      No volume groups found
    Activating logical volumes
      No volume groups found
      No volume groups found
    Free memory/Total memory (free %): 58272 / 116616 ( 49.9691 )
    Saving to the local filesystem UUID=e7abcdeb-1987-4c69-a867-fabdceffghi2
    Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
            [-I inode_buffer_blocks] [-P process_inode_size]
            [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
            [-E extended-options] device
    
    Emergency help:
     -p                   Autom
    
  6. Và sau đó hệ thống khởi động lại (đó là mặc định).

  7. Khi hệ thống trở lại trực tuyến, không có gì trong /var/crash. Tôi cho rằng bãi rác không được viết.

    [root@host1 ~]# ls -lA /var/crash/
    total 0
    [root@host1 ~]#
    
  8. Tôi biết rằng các bãi đổ vỡ có thể làm việc nói chung. Nếu tôi yêu kdumpcầu sao chép kết xuất lõi sang hệ thống khác với cấu hình sau, kdump sẽ ghi thành công kết xuất lõi vào máy chủ khác:

    path vmcore
    ssh user@hostb.example.org
    sshkey /root/.ssh/kdump_id_rsa
    
  9. Nếu tôi đặt default shell/etc/kdump.confvà xây dựng lại initrd, và sau đó sụp đổ hệ thống một lần nữa tôi nhận được một lỗi hơi nhiều thông tin thêm vềmount: can't find /mnt in /etc/fstab

    Free memory/Total memory (free %): 58272 / 116616 ( 49.9691 )
    Saving to the local filesystem UUID=e720481b-1987-4c69-a867-f2b4cba3b312
    Usage: fsck.ext4 [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
    [-I inode_buffer_blocks] [-P process_inode_size]
    [-l|-L bad_blocks_file] [-C fd] [-j external_journal]
    [-E extended-options] device
    
    Emergency help:
     -p                   Automatic repair (no questions)
     -n                   Make no changes to the filesystem
     -y                   Assume "yes" to all questions
     -c                   Check for bad blocks and add them to the badblock list
     -f                   Force checking even if filesystem is marked clean
     -v                   Be verbose
     -b superblock        Use alternative superblock
     -B blocksize         Force blocksize when looking for superblock
     -j external_journal  Set location of the external journal
     -l bad_blocks_file   Add to badblocks list
     -L bad_blocks_file   Set badblocks list
    mount: can't find /mnt in /etc/fstab
    dropping to initramfs shell
    exiting this shell will reboot your system
    /sys/block #
    
  10. Nhưng bây giờ, tôi bị mắc kẹt.


Make / model của máy chủ là gì?
ewwhite

Đây là một chiếc Supermicro với bo mạch chủ X9DRW4 và bios mới nhất.
Stefan Lasiewski

Bummer. Tôi đang gặp sự cố tương tự trên HP ProLiants với kernel RHEL6 mới nhất. Tôi tự hỏi nếu nó là một vấn đề sâu sắc hơn.
ewwhite

Đối với tôi, nó trông hơi giống một con bọ. Nhưng tôi không nhớ đầu ra sẽ như thế nào.
Stefan Lasiewski

1
Chào. Bạn đã giải quyết vấn đề này? Tôi đang đối mặt với vấn đề rất giống nhau.
Chul-Woong Yang

Câu trả lời:


5

Một chút muộn để trò chơi nhưng nếu bạn cần cấu hình kdump cho tương lai:

Tôi nghĩ rằng chỉ thị đường dẫn chỉ định một đường dẫn từ phân vùng hoặc hệ thống tệp được chỉ định. Theo mặc định, đây là fs gốc. Nếu bạn có một phân vùng riêng trong fstab cho / var, nó sẽ làm xáo trộn thư mục sự cố khi hệ thống của bạn được khởi động bình thường. tức là nếu bạn khởi động bình thường và ngắt kết nối / var, bạn sẽ thấy sự cố / [UniqCoreDir]. Bạn có thể điều chỉnh điều này bằng cách thêm một lệnh "ext4 / PATH / TO / DEVICE" trong kdump.conf. Ngoài ra, bạn có thể sử dụng một đường dẫn khác sẽ không được gắn kết.

Chỉ là một phỏng đoán nhưng có thể có một số vmcores bị chôn vùi dưới / var.


2

Kéo initd kdump của bạn vào / boot / check để xem đường dẫn cuối cùng mà nó đang cố gắng chuyển sang.

  • Tôi nghĩ tùy chọn "đường dẫn" hơi lạ, có lẽ tôi sẽ để mặc định hoặc đặt nó rõ ràng thành / var / crash

  • Bạn có một số loại watchdog khởi động lại máy? điều này cũng có thể ngăn lõi được tạo bằng cách khởi động lại máy trước khi khởi động.


Tôi sẽ kiểm tra initrd và xem những gì tôi tìm thấy. Các pathtùy chọn trong # 2 là đường dẫn mặc định ( /var/crash).
Stefan Lasiewski

Không, tôi không có cơ quan giám sát khởi động lại máy. Hóa ra bộ điều khiển LSI + SSD Samsung đang bị đóng băng định kỳ vì những lý do mà chúng tôi không hoàn toàn hiểu được.
Stefan Lasiewski

Bạn có nhận được bất kỳ thông tin phản hồi nào không, vì điều đó khá điên rồ, có thể là sự cố mất điện do điện áp quá thấp?
Không có tên người dùng
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.