Vì sao một unit VPN khởi động trước mạng rồi chết

Khởi động máy, đăng nhập và biết rằng đường hầm đã lên rồi chết vài giây sau đó. Hồ sơ đều ổn, chứng chỉ đều ổn, và dấu vết duy nhất còn lại là nhật ký của lần khởi động đó. Điều thường xảy ra là một cuộc đua: unit khởi động trước khi máy có địa chỉ, và thứ tự mà nó khai báo không mang nghĩa như vẻ ngoài. Mọi thứ dưới đây nói về việc chứng minh cuộc đua đó từ bằng chứng và đóng nó lại cho đúng.

Mục tiêu là điểm hẹn, không phải người quản lý

network-online.target không biết mạng là gì. Đó là một điểm phối hợp tập hợp dịch vụ lẽ ra phải trì hoãn việc khởi động cho đến khi liên kết dùng được, và nó giao định nghĩa cho trình quản lý mạng sở hữu máy. Trên hầu hết máy tính để bàn và máy chủ, điều đó nghĩa là một dịch vụ chờ do NetworkManager hoặc systemd-networkd cung cấp. Nếu không bật cái nào, mục tiêu không có gì để chờ, nên nó hoàn tất ngay khi có thứ gì đó kéo nó vào, và điều đó có thể xảy ra rất lâu trước khi DHCP trả lời. Dòng thứ tự trong unit của bạn trung thực và vẫn vô dụng.

Vì vậy câu hỏi đầu tiên không phải là unit của bạn khai báo gì. Mà là liệu có thứ gì trên máy này thực sự đang làm việc chờ.

Đọc lần khởi động cuối thay vì tệp unit

Các tệp unit mô tả ý định, còn nhật ký mô tả điều đã xảy ra. Chỉ yêu cầu lần khởi động đó, với dấu thời gian đơn điệu để mỗi thông điệp nằm trên một đồng hồ. Sau đó tìm hai dòng: thời điểm unit đường hầm bắt đầu khởi động và thời điểm địa chỉ xuất hiện hoặc dịch vụ chờ kết thúc. Sắp xếp hai con số đó và cuộc đua hoặc được xác nhận hoặc bị loại trừ.

Khung nhìn phụ thuộc xác nhận điều này. Nếu một chuỗi quan trọng cho unit đường hầm không chứa dịch vụ chờ, thì không có gì trên đường đó trì hoãn việc khởi động, và mục tiêu đã không làm công việc bạn giả định. Hai khung nhìn, một kết luận.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Thêm việc chờ, rồi thêm lần thử lại

Dùng drop-in thay vì sửa một unit đã đóng gói, để bản cập nhật gói không âm thầm bỏ thay đổi. Hai chỉ thị quan trọng: unit phải được sắp xếp sau mục tiêu, và phải kéo mục tiêu vào cùng giao dịch. Chỉ thứ tự thì không gọi mục tiêu; mong muốn mới làm điều đó.

Unit đã đóng gói của ứng dụng OpenVPN đã mang cả hai. Các unit viết tay thường mang một hoặc không, điều đáng kiểm tra trước khi thêm bất cứ thứ gì.

[Service]
Restart=on-failure
RestartSec=15

Vì sao một giấc ngủ cố định là bẫy

Một giấc ngủ trong ExecStartPre có cảm giác như sửa thứ tự và hành xử như một sự trì hoãn với các bước thêm. Nó làm chậm mọi lần khởi động, kể cả những lần khỏe mạnh, và vẫn thua khi liên kết mất nhiều thời gian hơn con số bạn chọn.

Tệ hơn, nó che giấu việc dịch vụ chờ có hoạt động hay không, nên lần hỏng tiếp theo hiện ra như một vấn đề hoàn toàn mới thay vì cùng vấn đề với thời điểm khác. Một độ trễ khởi động lại ngắn là công cụ tốt hơn: nó không tốn gì trong lần khởi động khỏe mạnh và biến cuộc đua thua thành một lần thử nữa. Giữ khoảng nghỉ khiêm tốn và để unit thành công. Nếu nó khởi động lại mãi, hồ sơ đã hỏng và bao nhiêu lần thử cũng không đổi được điều đó, nên hãy đọc nhật ký thay vì tăng khoảng nghỉ.

Khi thứ tự đúng mà tên vẫn hỏng

Một unit đang hoạt động với tuyến đường hầm nghĩa là thứ tự đã làm xong việc của nó và lỗi còn lại nằm ở tầng trên. Dạng thường gặp là một thiết lập trình phân giải do script up của đường hầm áp dụng trước khi liên kết hoặc trình phân giải sẵn sàng giữ nó. Hãy so trạng thái trình phân giải trong lúc hỏng với trạng thái sau khi khởi động lại unit đường hầm.

Nếu việc khởi động lại sửa được tra cứu, bạn có lỗi thứ tự khởi động chứ không phải máy chủ DNS sai, và hai thứ đó cần cách sửa khác nhau. Sau đó chứng minh toàn bộ bằng khởi động lạnh thay vì khởi động lại dịch vụ, vì khởi động lại chạy trên mạng đã lên và sẽ che đúng lỗi bạn đang đuổi theo. Lặp lại với liên kết cố tình chậm, và coi một unit chỉ chạy khi mạng nhanh là vẫn hỏng.