Systemd: memulai unit setelah unit lain BENAR-BENAR dimulai

Dalam kasus khusus saya, saya ingin memulai remote-fsunit setelah semua glusterfsbenar - benar dimulai.

File systemd saya:

glusterfs target:

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 target:

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, semua daemon Gluster mulai berhasil dan saya ingin me-mount sistem file Gluster melalui NFS, tetapi bagian NFS Gluster bersiap-siap tidak segera setelah glusterfs.servicedimulai, tetapi beberapa detik kemudian, jadi biasanya remote-fstidak dapat me- mountnya bahkan mengenai Requiresdan Afterarahan.

Mari kita lihat log:

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...

Di sini semuanya OK, sistem file jarak jauh (/ stor) tampaknya akan dipasang setelah glusterfs dimulai, karena seharusnya sesuai dengan file unit ... Tetapi baris selanjutnya adalah:

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

Apa? GlusterFS bersiap-siap hanya untuk saat ini! Dan kemudian kita melihat:

//...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 gagal karena server NFS tidak siap ketika systemd mencoba me-mount penyimpanan.

Karena sifat non-deterministik dari proses boot sistem, terkadang (sekitar 1 dari 10 boot) pemasangan sistem file ini pada boot berhasil.

Jika onboot mount tidak berhasil, saya bisa masuk ke server dan secara manual me-mount direktori / stor, jadi layanan NFS Gluster sepertinya berfungsi dengan baik.

Jadi bagaimana memulai remote-fssetelah glusterfsd, yaitu setelah Started GlusterFS brick processesbaris muncul dalam log?

remote-fstampaknya menjadi salah satu target terakhir, jadi saya tidak bisa memulainya setelah target "penyelesaian" lain yang sebenarnya tidak diperlukan oleh remote-fs.

Anda dapat menganalisis urutan boot systemd dengan mengikuti perintah. Lihat file output dengan menggunakan browser web yang mendukung SVG.

systemd-analyze plot > test.svg

Plotting itu akan memberikan Anda statistik waktu boot terakhir, yang akan memberi Anda lebih banyak sudut pandang untuk masalah.

Saya memecahkan masalah pemasangan NFS saya dengan menambahkan mountperintah ke /etc/rc.local. Namun saya tidak yakin, apakah ini akan bekerja dengan integrasi glusterd, patut dicoba untuk perbaikan cepat. Untuk membuat systemd menjalankan rc.local Anda harus memenuhi ketentuan berikut:

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

Seperti yang sudah disarankan oleh orang lain; Saya tidak yakin apakah itu benar-benar ketergantungan pada 'glusterfsd', alih-alih penundaan umum dalam hal lain, misalnya pencarian DNS yang perlu berhasil agar dapat menyelesaikan 'node4' dan berhasil me-mount share NFS.

Kami mengalami keterlambatan ini karena sebagian besar pengaturan kami menggunakan penyelesai validasi lokal, yang harus tersedia sebelum layanan lain yang bergantung pada DNS dapat memulai dengan sukses.

Solusi untuk ini adalah memiliki skrip 'ExecStartPre' yang pada dasarnya menguji ketersediaan dependensi spesifik berulang-ulang, sampai berhasil (keluar 0) atau waktu mencoba (keluar 1).

Pastikan Anda menyesuaikan di luar direktori systemd lib utama, jika Anda bisa. Mengubah file paket akan berarti mereka kemungkinan akan ditimpa pada pembaruan berikutnya yang datang.

Mungkin Anda bisa menambahkan ini ke remote-fstarget:

[Unit]
...
ConditionPathExists=/stor

Mungkin beberapa polling bisa membantu. Ini tidak tergantung pada systemd. Sebagai contoh saya gunakan mysql -e ';'dalam satu lingkaran sebelum melakukan sesuatu yang berguna dengan mysql.