Tên độ phân giải khác nhau giữa CentOS và Debian


13

Tôi có một chương trình Java nhỏ lặp lại gọi InetAddress.getByName ("example.com") mỗi giây. Khi tôi chạy nó trên hộp CentOS 6.4 bằng cách sử dụng 'strace -f', tôi thấy rằng /etc/resolv.conf được mở và đọc một lần:

$ grep /etc/resolv.conf strace.out
[pid 24810] open("/etc/resolv.conf", O_RDONLY) = 6

Khi tôi chạy nó trên Debian 7, tôi thấy /etc/resolv.conf liên tục được mở hoặc stat () 'd:

$ grep  /etc/resolv.conf strace.out
[pid 41821] open("/etc/resolv.conf", O_RDONLY) = 10
[pid 41821] stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=92, ...}) = 0
[pid 41821] open("/etc/resolv.conf", O_RDONLY) = 10
[pid 41821] stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=92, ...}) = 0
[pid 41821] stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=92, ...}) = 0

Cả hai hệ thống đều có /etc/nsswitch.conf được cấu hình với

máy chủ: tập tin dns

Cả hai hệ thống đều có một trình nền bộ nhớ đệm tên đang chạy.

Tôi đã sử dụng cùng một phiên bản JVM của Oracle HotSot trên cả hai máy để loại trừ mọi khác biệt về Java.

Hộp CentOS 6.4 đã cài đặt glibc 2.12. Hộp Debian 7 đã cài đặt glibc 2.13.

Điều gì giải thích cho hành vi khác nhau giữa hai hệ điều hành liên quan đến việc mở và đọc /etc/resolv.conf?


Bạn có thể xin vui lòng pastebin đầy đủ dấu vết.
Danila Ladner

Câu trả lời:


10

Các nhà phát triển glibc RedHat coi một số lỗi trong phần mềm của họ không phải là lỗi. Một trong những lỗi này là việc đọc lại độ phân giải sau khi thay đổi. glibc cho rằng trách nhiệm của ứng dụng, vì vậy mỗi ứng dụng sẽ cần tạo logic riêng cho việc này.

Bởi vì đây hoàn toàn là bonkers, các nhà phát triển eglibc đã khắc phục vấn đề này. Vì vậy, trên các hệ thống không phải eglibc, ứng dụng của bạn sẽ cần phải có logic riêng để khởi tạo lại nss_dns, nếu không, nó sẽ cần phải được khởi động lại sau khi thay đổi độ phân giải. Trên các hệ thống eglibc (Debian và những thứ dựa trên Debian), bạn sẽ nhận được một libc ít lỗi hơn.

Chúng tôi đã tìm ra điều này một cách khó khăn sau khi thay đổi độ phân giải, ngừng hoạt động các máy chủ DNS cũ và sau đó phải khởi động lại hơn 1200 máy chủ mysql. Không cần phải nói, điều này không vui.


Tại sao điều này được coi là "hoàn toàn bonkers"? Và tại sao glibc làm theo cách này?
Michael Hampton

1
Bởi vì thay vì sửa chữa glibc, họ đặt gánh nặng lên mọi ứng dụng ngoài kia ... Còn tại sao họ làm điều đó? Tôi không biết. Tôi không thể đọc được suy nghĩ của Dreppers và tôi không chắc mình muốn biết chuyện gì đang diễn ra ở đó ...
Dennis Kaarsemaker

1
Vấn đề là: Tôi không chắc chắn rằng glibc thực sự bị hỏng. Tại sao phải /etc/resolv.confđọc lại ở mỗi lần tra cứu DNS? Có thực sự dự kiến ​​sẽ thay đổi điều đó thường xuyên? Bây giờ nếu hành vi không có giấy tờ thì tôi có thể hiểu ...
Michael Hampton

1
Nó không được đọc lại trong mỗi lần tra cứu, điều đó cũng sẽ bị phá vỡ :) Hành vi này không có giấy tờ và thực sự phản trực giác: glibc chịu trách nhiệm khởi tạo thư viện nss_dns, nhưng sau đó làm cho ứng dụng chịu trách nhiệm khởi tạo lại nó, mặc dù các ứng dụng đó không biết anythong về nss và cách nó hoạt động. Làm thế nào mà không phải là bonkers?
Dennis Kaarsemaker

1
Dennis đã đúng, gai trong EL6 bị phá vỡ có chủ ý vì hành vi lỗi đã trở thành "hành vi mong đợi" - access.redhat.com/site/solutions/541163
suprjami 24/12/13

4

Không chỉ các phiên bản thư viện C khác nhau, mà CentOS còn sử dụng thư viện GNU C ( glibc) trong khi Debian sử dụng Embedded GLIBC ( eglibc), do đó việc thực hiện các cuộc gọi hệ thống tra cứu tên là hoàn toàn khác nhau.

Điều đó có thể sẽ giải thích cho hành vi gọi hệ thống khác nhau giữa hai bản phân phối này.

Tôi giả sử InetAddress.getByNamedịch vào getaddrinfo(). Bạn có thể bắt đầu bằng cách đọc nguồn của từng tòa nhà trong các phiên bản và triển khai thư viện C có liên quan.

Đảm bảo bạn đã đọc nguồn từ các phiên bản gói thực tế bạn đang sử dụng. Các gói trong EL 6.4 đã có hơn 2 năm cải tiến so với các phiên bản ngược dòng ban đầu của chúng. Tôi cho rằng điều tương tự cũng đúng với các gói Debian.

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.