Unix koans và Linux bug
Unix
31
Koans
2
White

Tal viết ngày 23/05/2015

Mình là fan của Unix Koans. Nhiều bài làm thay đổi rất nhiều cách suy nghĩ của mình. Tuy vậy cũng có những bài mình đọc xong mà luôn tự hỏi tại sao tác giả lại viết như vậy. Nói cách khác là: không hiểu :)

Bài dưới đây là một ví dụ:

Tom Knight and the Lisp Machine

A novice was trying to fix a broken Lisp machine by turning the power off and on.

Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”

Knight turned the machine off and on.
The machine worked.

Rõ ràng là ông thầy và học trò làm cùng một hành động, không có lý nào lại cho 2 kết quả khác nhau. Mình nghi ngờ nội dung của mẩu Koans này.

Tuy vậy, một bug của Linux Kernel vả Intel Xeon Processor E5 gần đây mình gặp phải đã giúp mình thay đổi cách suy nghĩ về mẩu koans.

Mô tả bug

Mình có một máy chủ chạy CentOS 6.4 kernel-2.6.32-358(RHEL 6.4). Máy chủ chạy được hơn 200 ngày. Công việc phát sinh thao tác phải thay đổi cài đặt và khởi động lại máy chủ, do vậy mình thay đổi cài đặt rồi tái khởi động.

$ reboot

Sau khi khởi động máy chủ bắt đầu phát sinh các triệu chứng. Sau một thời gian tốc độ trả lời của máy chủ chậm đi rất nhiều. ssh gần như không hoạt động. Các câu lệnh như cat / ls không hoạt động, hay nói cách khác không trả lại kết quả

$ cat file
....

Mình khởi động lại máy thì thấy máy hoạt động bình thường. Tuy vậy sau 5 phút, tình trạng không hoạt động lại tái diễn. Mình nghi ngờ các cài đặt của mình có vấn đề nên đã chuyển các file cài đặt về trạng thái trước khi khởi động lại nhưng tình trạng vẫn biểu hiện như cũ.

Mình khởi động lại lần nữa và tranh thủ lúc máy vẫn hoạt động kiểm tra log hệ thống thì chỉ thấy các message như sau:

INFO: task bash:12543 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D 0000000000000012 0 12543 12542 0x00000084
ffff880c343b3ce8 0000000000000082 ffff880c343b3d98 ffffffffffffffe9
ffff880c343b3c88 ffffffffa00c9129 ffff880c343f4aa0 0000010100000015
ffff880c343f5058 ffff880c343b3fd8 000000000000fb88 ffff880c343f5058
Call Trace:
[<ffffffffa00c9129>] ? ext4_check_acl+0x29/0x90 [ext4]
[<ffffffffa008fbf0>] ? ext4_file_open+0x0/0x130 [ext4]
[<ffffffff8150ea05>] schedule_timeout+0x215/0x2e0
[<ffffffff8117e514>] ? nameidata_to_filp+0x54/0x70
[<ffffffff81277379>] ? cpumask_next_and+0x29/0x50
[<ffffffff8150e683>] wait_for_common+0x123/0x180
[<ffffffff81063310>] ? default_wake_function+0x0/0x20
[<ffffffff8150e79d>] wait_for_completion+0x1d/0x20
[<ffffffff8106513c>] sched_exec+0xdc/0xe0
[<ffffffff8118a0a0>] do_execve+0xe0/0x2c0
[<ffffffff810095ea>] sys_execve+0x4a/0x80
[<ffffffff8100b4ca>] stub_execve+0x6a/0xc0

Các tác vụ đều bị treo sau một thời gian và xuất ra message tương tự như trên. Các tác vụ cũng hoàn toàn khác nhau.

Mình nghi ngờ lỗi phần cứng nhưng phần mềm kiểm tra báo không có lỗi gì. Và mình bó tay. Mình đã rất lo lắng vì nếu không cài đặt thành công máy chủ này, mình có thể sẽ chậm kế hoạch của một dịch vụ ...

May mắn thay, trong một lúc google trong vô vọng mình phát hiện ra trang mô tả bug như sau:

https://access.redhat.com/solutions/433883

Đọc qua nội dung thấy cấu hình máy chủ, OS giống hệt với cấu hình máy chủ của mình. Biểu hiện lỗi cũng giống hệt. Và cách sửa: đừng khởi động lại máy hãy cold reboot nó. Mình làm theo quy trình mô tả và máy của mình hoạt động như bình thường!

Cold (Re)Boot là gì?

Dòng chip Intel® Xeon® Processor E5 Family 6 Model 45 có vẻ bị lỗi này. Sau khi warm reset xong, giá trị của thanh ghi TSC (Time Stamp Counter) không được xoá và khởi tạo lại và điều này dẫn đến bug.

Bằng cách Cold Reboot, tức là tắt cho máy hoàn toàn không còn điện và từ trạng thái đó khởi động lại, ta chắc chắn việc khởi tạo TSC và do vậy đưa máy tính về trạng tháy bình thường.

Nói cách khác:

  • warm (re)boot: khởi động lại máy nhưng không rút hết điện ra khỏi các thiết bị điện tử, chỉ khởi động lại chương trình chạy trên phần cứng đó.
  • cold (re)boot: đưa máy tính về trạng thái không có điện, rồi mới khởi động lại chương trình ở trên nó.

Cùng là thao tác khởi động lại, nhưng hành động khác nhau dẫn đến kết quả khác nhau. Mấu chốt ở đây là nhả cho các thiết bị điện không còn điện!

Đọc đến đây, mình hiểu ra ý nghĩa của mẩu koans. Đúng như ông thầy trong đó nói:

“You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”

Mình được khai sáng!

Một số bài viết về bug trên

  1. https://support.pivotal.io/hc/en-us/articles/203152603-DCA-Server-becomes-unresponsive-after-rebooting-using-shutdown-r-command
  2. https://access.redhat.com/solutions/433883

Bài sau sẽ viết kỹ hơn về nguyên nhân bug này ở level code

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Tal

1 bài viết.
0 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Bài viết liên quan
White
1 0
Sử dụng option I với xargs Với option I thì bạn có thể sử dụng place holder với biến được lấy ra từ xargs man của option này: I replacestr R...
LinhPT viết hơn 2 năm trước
1 0
White
48 1
Chương 1. Tổng quan một hệ thống Linux Thiên chúa thấy mọi sự người đã làm, và thấy rằng nó đuợc làm rất tốt. Bible King James Version. Genesis 1:3...
Trần Đạt viết 2 năm trước
48 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
1 bài viết.
0 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!