Systemd: bắt đầu một đơn vị sau khi một đơn vị khác THỰC SỰ bắt đầu

Trong trường hợp cụ thể của tôi, tôi muốn bắt đầu remote-fsđơn vị sau khi tất cả glusterfsbắt đầu hoàn toàn.

Tập tin systemd của tôi:

glusterfs Mục tiêu:

node04:/usr/lib/systemd/system # cat glusterfsd.service 
[Unit]
Description=GlusterFS brick processes (stopping only)
After=network.target glusterd.service

[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes
ExecStop=/bin/sh -c "/bin/killall --wait glusterfsd || /bin/true"
ExecReload=/bin/sh -c "/bin/killall -HUP glusterfsd || /bin/true"

[Install]
WantedBy=multi-user.target

remote-fs Mục tiêu:

node04:/usr/lib/systemd/system # cat remote-fs.target 
[Unit]
Description=Remote File Systems
Documentation=man:systemd.special(7)
Requires=glusterfsd.service
After=glusterfsd.service remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target

[Install]
WantedBy=multi-user.target

OK, tất cả các trình tiện ích của Gluster bắt đầu thành công và tôi muốn gắn hệ thống tập tin Gluster thông qua NFS, nhưng chia sẻ NFS của Gluster đã sẵn sàng không ngay lập tức sau khi glusterfs.servicebắt đầu, nhưng một vài giây sau, do đó thường remote-fskhông thể gắn kết nó ngay cả về chỉ thị Requiresvà Afterchỉ thị.

Hãy xem nhật ký:

Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS, a clustered file-system server.
Apr 14 16:16:22 node04 systemd[1]: Starting GlusterFS brick processes (stopping only)...
Apr 14 16:16:22 node04 systemd[1]: Starting Network is Online.
Apr 14 16:16:22 node04 systemd[1]: Reached target Network is Online.
Apr 14 16:16:22 node04 systemd[1]: Mounting /stor...

Ở đây mọi thứ đều ổn, hệ thống tập tin từ xa (/ repository) dường như được gắn kết sau khi glusterfs bắt đầu, vì nó có nghĩa là theo các tập tin đơn vị ... Nhưng các dòng tiếp theo là:

//...skipped.....
Apr 14 16:16:22 node04 systemd[1]: Started GlusterFS brick processes (stopping only).

Gì? GlusterFS đã sẵn sàng chỉ cho thời điểm này! Và sau đó chúng ta thấy:

//...skipped.....
Apr 14 16:16:23 node04 mount[2960]: mount.nfs: mounting node04:/stor failed, reason given by server: No such file or directory
Apr 14 16:16:23 node04 systemd[1]: stor.mount mount process exited, code=exited status=32
Apr 14 16:16:23 node04 systemd[1]: Failed to mount /stor.
Apr 14 16:16:23 node04 systemd[1]: Dependency failed for Remote File Systems.
Apr 14 16:16:23 node04 systemd[1]: Unit stor.mount entered failed state.

Mount không thành công vì máy chủ NFS chưa sẵn sàng khi systemd cố gắn kết bộ lưu trữ.

Do tính chất không xác định của quy trình khởi động systemd, đôi khi (khoảng 1 trong 10 lần khởi động) gắn hệ thống tập tin này khi khởi động thành công.

Nếu việc gắn kết onboot không thành công, tôi có thể đăng nhập vào máy chủ và tự gắn thư mục / repository, vì vậy dịch vụ NFS của Gluster dường như hoạt động tốt.

Vậy làm thế nào để bắt đầu remote-fssau glusterfsd, tức là sau khi Started GlusterFS brick processesdòng xuất hiện trong nhật ký?

remote-fsdường như là một trong những mục tiêu cuối cùng, vì vậy tôi không thể bắt đầu nó sau một mục tiêu "giải pháp" khác mà thực tế không bắt buộc remote-fs.

Bạn có thể phân tích trình tự khởi động systemd bằng lệnh sau. Xem tệp đầu ra bằng cách sử dụng trình duyệt web hỗ trợ SVG.

systemd-analyze plot > test.svg

Âm mưu đó sẽ cung cấp cho bạn số liệu thống kê thời gian khởi động lần cuối, điều này sẽ cung cấp cho bạn quan điểm rõ ràng hơn về vấn đề.

Tôi đã giải quyết vấn đề gắn NFS của mình bằng cách thêm mountcác lệnh vào /etc/rc.local. Tuy nhiên tôi không chắc chắn, nó có hoạt động với tích hợp glusterd hay không, đáng để thử để khắc phục nhanh. Để làm cho systemd chạy RC.local, bạn nên đáp ứng điều kiện sau:

# grep Condition /usr/lib/systemd/system/rc-local.service
ConditionFileIsExecutable=/etc/rc.d/rc.local

Như đã được đề xuất bởi những người khác; Tôi không chắc liệu đó có thực sự là một sự phụ thuộc vào 'glusterfsd' hay không, thay vì sự chậm trễ chung trong một điều gì khác, ví dụ như việc tra cứu DNS cần thành công để có thể giải quyết 'node4' và thành công chia sẻ NFS.

Chúng tôi đã gặp phải sự chậm trễ này vì hầu hết các thiết lập của chúng tôi sử dụng trình phân giải xác thực cục bộ, cần có sẵn trước khi các dịch vụ khác phụ thuộc vào DNS có thể bắt đầu thành công.

Giải pháp cho vấn đề này là có một tập lệnh 'ExecStartPre', về cơ bản kiểm tra tính khả dụng của các phụ thuộc cụ thể nhiều lần, cho đến khi thành công (thoát 0) hoặc hết thời gian thử (thoát 1).

Hãy chắc chắn rằng bạn tùy chỉnh bên ngoài thư mục lib hệ thống chính, nếu bạn có thể. Thay đổi các tệp gói sẽ có nghĩa là chúng có thể sẽ bị ghi đè lên bản cập nhật tiếp theo.

Có lẽ bạn có thể thêm điều này vào remote-fsmục tiêu:

[Unit]
...
ConditionPathExists=/stor

Có lẽ một số bỏ phiếu có thể giúp đỡ. Điều này là độc lập với systemd. Ví dụ tôi sử dụng mysql -e ';'trong một vòng lặp trước khi làm điều gì đó hữu ích với mysql.