OpenVPN đã khởi động nhưng không in ra gì: hãy kiểm tra log-append trước

Bạn khởi chạy OpenVPN từ shell với một tệp cấu hình, và terminal cứ đứng đó mà không có bất kỳ đầu ra nào. Không có biểu ngữ, không có lỗi, không có dấu nhắc. Bản năng mách rằng lần khởi chạy đã thất bại, nên bạn khởi chạy thêm một bản sao, rồi thêm một bản nữa, và cỗ máy kết thúc với vài phiên bản được cấu hình dở dang. Trước tất cả những điều đó, hãy kiểm tra trong hồ sơ một chỉ thị đã chuyển nhật ký sang nơi khác. Sự im lặng là thuộc tính của console, không phải của tiến trình.

Sự im lặng có hai lời giải thích rất khác nhau

Thứ nhất là tiến trình đang chạy tốt và ghi vào một tệp mà bạn không theo dõi. Thứ hai là nó thoát ngay lập tức với một lỗi được ghi trong chính tệp đó.

Cả hai đều để lại một terminal trống, và một câu hỏi phân biệt chúng: hiện có tiến trình không, và trong tệp mà nó được lệnh ghi có gì. Hãy trả lời điều đó trước khi chạm lại vào cấu hình. Khởi chạy lại để lấy đầu ra chính là cách hai phiên bản bắt đầu tranh nhau một thiết bị đường hầm và cùng một cổng, điều này tạo ra những lỗi không liên quan gì đến vấn đề ban đầu.

Hãy tìm chỉ thị, rồi tìm tiến trình.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Hãy tìm đích mà tiến trình đang chạy sử dụng

Đọc hồ sơ mà tiến trình thực sự được khởi chạy cùng, không phải hồ sơ bạn đã sửa. Một phiên bản do dịch vụ quản lý thường nạp một đường dẫn khác và chạy trong một thư mục làm việc khác, nên một tên tệp tương đối được phân giải ở nơi bạn không ngờ.

Một chỉ thị cd rõ ràng làm cho sự khác biệt đó sắc nét hơn, vì đường dẫn tương đối di chuyển theo thay đổi thư mục. Nếu bạn thừa hưởng cấu hình này, tệp có thể nằm ở một nơi mà giờ không ai tìm đến.

Hãy so sánh thời gian sửa đổi của tệp với thời điểm bạn khởi chạy. Nhật ký của tuần trước là bằng chứng về tuần trước. Sau đó đọc những dòng cuối của tệp đã thay đổi, và coi bất cứ thứ gì ở đó là thông điệp khởi động mà bạn đã bỏ lỡ.

log so với log-append: bằng chứng và việc xóa

log-append thêm vào những gì đã có trong tệp. log mở tệp để ghi và cắt ngắn nó, vì vậy chuyển đổi giữa hai cách có thể xóa lần chạy mà bạn sắp đọc.

Nếu ai đó đã đổi chỉ thị trong khi gỡ lỗi, bằng chứng trước đó đã biến mất và kích thước tệp sẽ trông nhỏ một cách đáng ngờ. Điều đó đáng biết trước khi bạn so sánh hai lần chạy và kết luận rằng có gì đó đã thay đổi. Hãy xóa nhật ký một cách có chủ đích hoặc giữ nó lại, nhưng biết mình đã làm cách nào. Bằng chứng bạn cố ý gỡ bỏ dễ lý giải hơn bằng chứng bạn vô tình đánh mất.

Không lựa chọn nào tạo ra các thư mục cha còn thiếu, và không lựa chọn nào cấp quyền truy cập qua quyền của hệ thống tệp hay hộp cát của dịch vụ. Một đường dẫn trông đúng trong cấu hình vẫn có thể không ghi được bởi tài khoản mà daemon chạy dưới đó, và khi ấy daemon có thể thất bại trước khi kịp báo cáo bất cứ điều gì. Hãy kiểm tra thư mục có tồn tại không và ai là chủ sở hữu trước khi cho rằng tên tệp là vấn đề.

Khi một trình bao bọc dịch vụ bắt lấy đầu ra

Dưới systemd, đầu ra chuẩn và lỗi đi vào nhật ký trừ khi một chỉ thị tệp rõ ràng được ưu tiên, và trình bao bọc của nhà cung cấp có thể bắt chúng ở một nơi hoàn toàn khác.

Đó là lý do cùng một hồ sơ hành xử khác nhau từ shell và từ một unit. Môi trường của unit, thư mục làm việc và các luồng chuẩn của nó đều khác với shell tương tác của bạn. Một đường dẫn tương đối có thể được phân giải trong ngữ cảnh này và không đến được đâu trong ngữ cảnh kia. Khi hai bên không đồng ý, hãy đọc định nghĩa của unit, không phải hồ sơ.

Hãy so sánh hai cách bố trí khởi chạy thay vì kết luận rằng một trong hai bị hỏng. Đọc dòng lệnh của unit và môi trường của nó, rồi đọc nhật ký cho cùng khoảng thời gian. Nếu trình bao bọc chuyển đầu ra sang tệp riêng của nó, tệp đó giờ là nhật ký của bạn, và các chỉ thị OpenVPN không còn liên quan đến nơi các thông điệp đã đi.

Chỉ tăng mức độ chi tiết sau khi bạn có thể đọc nó

Tăng mức độ chi tiết trước khi tìm ra đích chỉ tạo ra nhiều văn bản hơn ở một nơi bạn không nhìn.

Khi bạn biết đầu ra đáp ở đâu, một mức vừa phải sẽ cho thấy hồ sơ đang được phân tích và kết nối đang được thử. Hai hoặc ba là đủ cho một vấn đề khởi động. Các mức cao hơn có chỗ đứng khi thất bại là một chi tiết thương lượng, và chúng cũng làm tệp lớn lên nhanh chóng.

Sau đó đọc lỗi thực sự. Một terminal im lặng không chứng minh gì về việc đường hầm đã lên hay chưa, và thất bại được ghi trong tệp mới là thứ đáng sửa.