Lưu ý: Điều này bắt đầu như một "Cách gỡ lỗi", hướng dẫn, nhưng cuối cùng lại là giải pháp giúp tôi trên máy chủ Ubuntu 16.04 LTS.
TLDR : Chạy landscape-sysinfo
và kiểm tra xem lệnh đó có mất nhiều thời gian để hoàn thành hay không; đó là bản in thông tin hệ thống khi đăng nhập SSH mới. Lưu ý rằng lệnh này không có sẵn trên tất cả các hệ thống, landscape-common
gói sẽ cài đặt nó. ("Nhưng xin chờ chút nữa...")
Khởi động máy chủ ssh thứ hai trên một cổng khác trên máy gặp sự cố, làm như vậy trong chế độ gỡ lỗi, điều này sẽ không làm cho nó rẽ nhánh và sẽ in ra các thông báo gỡ lỗi:
sudo /usr/sbin/sshd -ddd -p 44321
kết nối với máy chủ đó từ một máy khác ở chế độ dài dòng:
ssh -vvv -p 44321 username@server
Khách hàng của tôi xuất ra các dòng sau ngay trước khi bắt đầu ngủ:
debug1: Entering interactive session.
debug1: pledge: network
Googling không thực sự hữu ích, nhưng nhật ký máy chủ tốt hơn:
debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051
Tôi nhận thấy rằng khi tôi thay đổi UsePAM yes
để UsePAM no
sau đó vấn đề này đã được giải quyết.
Không liên quan đến UseDNS
hoặc bất kỳ cài đặt nào khác, chỉ UsePAM
ảnh hưởng đến sự cố này trên hệ thống của tôi.
Tôi không có đầu mối tại sao, và tôi cũng không để lại UsePAM
tại no
, bởi vì tôi không biết được các tác dụng phụ là, nhưng điều này cho phép tôi tiếp tục điều tra.
Vì vậy, đừng coi đây là một câu trả lời, nhưng bước đầu tiên để bắt đầu tìm hiểu những gì sai.
Vì vậy, tôi tiếp tục điều tra, và chạy sshd
với strace
( sudo strace /usr/sbin/sshd -ddd -p 44321
). Điều này mang lại những điều sau đây:
sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385
Dòng này /etc/update-motd.d
làm tôi nghi ngờ, rõ ràng quá trình chờ kết quả của những thứ trong đó/etc/update-motd.d
Vì vậy, tôi cd
đã tham gia /etc/update-motd.d
và chạy một sudo chmod -x *
để ức chế PAM để chạy tất cả các tệp tạo ra động này Message Of The Day
, bao gồm tải hệ thống và nếu các gói cần được nâng cấp, và điều này đã giải quyết được vấn đề.
Đây là một máy chủ dựa trên CPU N3150 "tiết kiệm năng lượng", có rất nhiều việc phải làm 24/7, vì vậy tôi nghĩ rằng việc thu thập tất cả dữ liệu motd này là quá nhiều cho nó.
Tôi có thể bắt đầu kích hoạt các tập lệnh trong thư mục đó một cách chọn lọc, để xem cái nào ít gây hại hơn, nhưng gọi đặc biệt landscape-sysinfo
là rất chậm và 50-landscape-sysinfo
gọi lệnh đó. Tôi nghĩ đó là một trong những nguyên nhân gây ra sự chậm trễ lớn nhất.
Sau khi sử dụng lại hầu hết các tập tin, tôi đã đi đến kết luận đó
50-landscape-sysinfo
và 99-esm
là nguyên nhân cho những rắc rối của tôi. 50-landscape-sysinfo
mất khoảng 5 giây để thực hiện và 99-esm
khoảng 3 giây. Tất cả các tệp còn lại khoảng 2 giây hoàn toàn.
Không 50-landscape-sysinfo
và 99-esm
rất quan trọng. 50-landscape-sysinfo
in ra các số liệu thống kê hệ thống thú vị (và cả nếu bạn thiếu dung lượng!) và 99-esm
in ra các tin nhắn liên quan đếnUbuntu Extended Security Maintenance
Cuối cùng, bạn có thể tạo một tập lệnh với echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh
và nhận bản in đó theo yêu cầu.