Lỗi phân đoạn Apache (11)

Tôi có lỗi này trong apace error.log:

[Thứ Sáu ngày 18 tháng 9 08:10:54 2009] [thông báo] pid trẻ em 9178 tín hiệu thoát Lỗi phân đoạn (11)
[Thứ Sáu ngày 18 tháng 9 08:11:41 2009] [thông báo] con pid 9187 tín hiệu thoát Lỗi phân đoạn (11)
[Thứ sáu Ngày 18 tháng 9 08:12:12 2009] [thông báo] con pid 9204 tín hiệu thoát Lỗi phân đoạn (11)
[Thứ sáu ngày 18 tháng 9 08:12:13 2009] [thông báo] con pid 9202 tín hiệu thoát Lỗi phân đoạn (11)
[Thứ sáu ngày 18 tháng 9 08:14:45 2009] [thông báo] con pid tín hiệu thoát 9251 Lỗi phân đoạn (11)

Nó bắt đầu cùng ngày tôi thực hiện một bổ sung cho tập tin vhost.conf. Vì vậy, tôi trở lại tập tin ban đầu đã khởi động lại apache2ctl. Thật không may, nó vẫn xảy ra.

Apache dường như đang phục vụ các trang OK.

Có ý kiến ​​gì không?

Chúc mừng

Nathan.

Nathan, hãy thử ngăn chặn Apache và khởi động nó trong forground (gỡ lỗi, không phân luồng), có thể rò rỉ thêm manh mối liên quan đến những gì đang khiến nó bị phân tách.

Đã nói rằng, nó không nên segfault bất kể, vì vậy đó là một lỗi, tuy nhiên, nó có thể là một cái gì đó bạn có thể sửa chữa nếu bạn biết những gì gây ra nó.

apache2 -X

Ngoài ra (không thể tiết lộ toàn bộ lý do cho vấn đề này), bất kỳ cảnh báo / lỗi nào từ ...

 apache2ctl -t

...?

Cuối cùng, là tất cả các mô-đun bạn đã tải vào Apache "Certified", có thể bạn có thể nhận xét về một nửa trong số chúng và xem liệu vấn đề có biến mất hay không, và tiếp tục tìm kiếm nhị phân phân chia và chinh phục từ đó.

Bạn cũng có thể tìm kiếm bất kỳ bãi chứa lõi nào được tạo ra từ segfault, có lẽ trong / tmp? Nếu bạn tìm thấy một số, hãy thử chạy nó qua gdb ...

gdb apache2 -c /tmp/core.<pid>

Sig11 thường chỉ xảy ra vì một trong hai lý do:

• Chương trình xấu.

  Trong trường hợp của Apache, về mặt thống kê, nó không có khả năng là một lỗi trong mã Apache cốt lõi.

  Đó là lỗi phổ biến hơn nhiều của một mô-đun. Theo cách mà một mô-đun xử lý một cách an toàn các ngoại lệ trong mã hoặc các thư viện mà nó đang xử lý. Hoặc cách mà nó tương tác với mô hình MPM đã chọn của Apache. Khi một mô-đun hoạt động sai theo cách này, nó sẽ thoát ra không kiểm soát được trước khi trả lại dữ liệu cho tiến trình con Apache và do đó tạo ra segfault.

  Xem lại tất cả các thay đổi mà bạn đã thực hiện kể từ lần cuối hoạt động. Giống như Lee B nói, đây là ví dụ hoàn hảo cho việc sử dụng kiểm soát phiên bản.

  Để làm phức tạp vấn đề một chút, bạn thường có thể tạo ra hành vi tương tự bằng cách ban hành gracefulthay vì khởi động lại hoàn toàn sau khi thay đổi thiết lập mô-đun của Apache. Bạn có thể loại trừ điều này bằng cách dừng và khởi động Apache.

• Phần cứng xấu.

  Nếu bạn chắc chắn rằng các lỗi trùng khớp với thay đổi cấu hình của bạn và bạn không thấy bất kỳ hiệu ứng xấu nào khác trên hệ thống thì có lẽ bạn có thể loại trừ lỗi này. Nhưng nó có thể là giá trị trong tâm trí nếu bạn hết các con đường khác. CPU và RAM là thủ phạm điển hình.

Cuối cùng đã sửa lỗi này. Một khởi động lại đơn giản của máy chủ đã dừng các lỗi seg.

Cảm ơn câu trả lời của bạn. Tôi chắc chắn sẽ có ích trong việc chẩn đoán các vấn đề trong tương lai.

Nathan.

Tôi cho rằng nó có thể là một mô-đun được tải có vấn đề.

Tôi đã trải nghiệm hành vi tương tự với phần mở rộng php của PHP và gettext, nó đã làm sập PHP và do đó, con của apache phục vụ yêu cầu.

Sau khi dành hàng giờ cố gắng tìm ra nguyên nhân lỗi lỗi phân khúc của riêng tôi, tôi bắt đầu vô hiệu hóa mọi thứ một cách ngẫu nhiên. Trong trường hợp của tôi, nguyên nhân gây ra lỗi là eaccelerator của Zend.

Vì tôi không cần tiện ích mở rộng này nên tôi sẽ vô hiệu hóa nó. Nếu bạn gặp vấn đề tương tự và cần tiện ích mở rộng này, bạn có thể thử xóa bộ đệm eaccelerator và khởi động lại httpd.

lần tới bạn có thể thử sử dụng strace hoặc truss

• http://httpd.apache.org/dev/debugging.html#truss