systemctl nói systemd không phải PID 1: vậy tiếp theo?

Khi chạy systemctl start openvpn-client@office và nhận thông báo rằng hệ thống không được khởi động bằng systemd, ta thấy như một sự cố dịch vụ. Đó hoàn toàn không phải sự cố dịch vụ: systemctl mà bạn gọi không tìm thấy trình quản lý đang chạy để nói chuyện, nên không có gì về OpenVPN được kiểm tra. sudo không tạo ra trình quản lý, và việc cài một tệp unit cũng không tạo ra nó. Lệnh và máy đến từ hai thế giới khác nhau, và lỗi là nơi duy nhất cho thấy điều đó.

Hãy bắt đầu bằng câu hỏi tiến trình nào giữ PID 1 tại nơi lệnh chạy, vì câu trả lời đó quyết định unit có tồn tại hay không.

Lỗi gọi tên môi trường, không phải OpenVPN

systemctl là một ứng dụng khách, không phải trình quản lý. Nó kết nối tới trình quản lý hệ thống qua socket, và khi đầu bên kia không có trình quản lý, nó in ra thông báo mà mọi người dán lên diễn đàn. ps -p 1 -o pid=,comm= cho thấy cái gì thực sự chạy như PID 1, và câu trả lời thường là shell, lớp bọc init hoặc điểm vào của chính vùng chứa. Trong tình huống đó, tệp unit có thể hoàn toàn hợp lệ mà vẫn không bao giờ được đọc. Lặp lại lệnh bằng root chỉ thay đổi thông tin đăng nhập của ứng dụng khách.

Đọc toàn bộ thông báo trước dòng đầu tiên. Một lỗi từ chính trình quản lý, như thiếu unit hoặc điều kiện thất bại, nghĩa là bạn đã tới được nó; lỗi này nghĩa là bạn chưa tới.

WSL: bật systemd là một thay đổi cấu hình

WSL có hỗ trợ systemd ở các bản phát hành sau, nhưng tính năng này được bật cho từng bản phân phối và chỉ ở nơi phiên bản WSL đã cài hỗ trợ. wsl --version ở phía Windows cho biết bạn có gì, và tệp /etc/wsl.conf của bản phân phối chứa [boot] một phần với systemd=true. Hãy sửa tệp đó mà không xóa các phần đã có, rồi khởi động lại phiên WSL để thay đổi có hiệu lực. wsl --shutdown dừng mọi bản phân phối đang chạy, nên hãy lưu việc trước.

Sau khi mở lại, hãy xác nhận trình quản lý trước khi chạm vào unit của OpenVPN: ps -p 1 -o comm= nên hiển thị systemd. Bật systemd không cung cấp hồ sơ, thông tin đăng nhập hay tên phiên, nên lỗi tiếp theo sẽ liên quan tới một trong số đó chứ không phải PID 1.

Vùng chứa chạy điểm vào của chúng, không phải unit

Một vùng chứa bình thường khởi chạy thứ mà điểm vào hoặc lệnh của nó chỉ định, và nó không phải máy được khởi động bằng systemd, bất kể bạn cài gói nào. Thêm systemctl vào ảnh chỉ cho bạn một ứng dụng khách không có gì để kết nối. Với Community OpenVPN, mẫu được hỗ trợ thường là một tiến trình chạy ở tiền cảnh, openvpn --config /path/to/client.conf, do điểm vào khởi chạy và được giám sát từ bên ngoài. Chủ sở hữu đó xử lý việc khởi động, tín hiệu và tắt, và nó nên là thứ duy nhất quản lý đường hầm.

Đừng bao giờ chạy một bản sao tương tác bên cạnh một điểm vào đã quản lý đường hầm đó, vì hai tiến trình sẽ tranh nhau thiết bị và các tuyến. Một tiến trình init tối thiểu trong vùng chứa thu gom tiến trình con và chuyển tiếp tín hiệu; nó không biến ảnh thành máy chủ có unit.

Nếu một triển khai thực sự cần systemd trong vùng chứa, nó cần một ảnh được thiết kế có chủ đích cho việc đó, không phải thêm đặc quyền cho tới khi systemctl thôi phàn nàn.

Đọc lỗi tiếp theo khi đã có trình quản lý

Ngay khi một trình quản lý thật khởi chạy dịch vụ, những lỗi hữu ích bắt đầu. Lỗi quyền thiết bị, lỗi phân tích cấu hình, thiếu thông tin đăng nhập và đối tác không thể tới được là bốn vấn đề khác nhau mà thông báo về PID 1 chưa từng kiểm tra. Hãy đọc chúng theo thứ tự unit tạo ra, dùng journalctl -u openvpn-client@office -n 50 trên máy chủ systemd, hoặc chạy ứng dụng khách ở tiền cảnh nơi không có trình quản lý. Chạy ở tiền cảnh cũng là cách nhanh nhất để xác nhận rằng bản thân hồ sơ hoạt động.

Hãy giữ hai môi trường tách biệt trong ghi chú của bạn: máy chủ chạy đường hầm, và nơi bạn gõ lệnh.