Systemd: bir birimi GERÇEKTEN başka bir birim başlattıktan sonra başlatın


20

Benim özel durumumda, tamamen başladıktan remote-fssonra üniteyi başlatmak istiyorum glusterfs.

Sistem dosyalarım:

glusterfs hedef:

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

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

Tamam, tüm Gluster artalanları başarılı bir şekilde başlıyor ve Gluster dosya sistemini NFS aracılığıyla bağlamak istiyorum, ancak Gluster'ın NFS paylaşımı hemen glusterfs.servicebaşlatıldıktan hemen sonra değil, birkaç saniye sonra hazırlanıyor, bu yüzden genellikle remote-fsilgili Requiresve Afteryönergeler arasında bile bağlanamıyor .

Günlüğü görelim:

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

Burada her şey yolunda, uzak dosya sistemi (/ stor) glusterfs başladıktan sonra, birim dosyalara göre olması gerektiği gibi monte edilmiş gibi görünüyor ... Ama sonraki satırlar:

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

Ne? GlusterFS sadece bu an için hazırlandı! Ve sonra görüyoruz:

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

Sistem depolama birimini takmaya çalıştığında NFS sunucusu hazır olmadığı için bağlama başarısız oldu.

Systemd önyükleme işleminin deterministik olmayan doğası nedeniyle, bazen bu dosya sistemini önyükleme üzerine monte etmek başarılı olur.

Açılışta bağlanma başarısız olursa, sunucuya giriş yapabilir ve / stor dizinini el ile bağlayabilirim, böylece Gluster'ın NFS hizmeti iyi çalışıyor gibi görünüyor.

Peki remote-fssonra nasıl başlanır glusterfsd, yani Started GlusterFS brick processesgünlükte satır görüntülendikten sonra ?

remote-fsson hedeflerden biri gibi görünüyor, bu yüzden aslında gerekli olmayan başka bir "geçici çözüm" hedefinden sonra başlayamıyorum remote-fs.


5
Glusterfs hazır olana kadar engellenecek bir komutu yürüten ExecStartPre=<command>Birim bölümüne bir özellik ekleyebilir misiniz glusterfsd.service? Bu, glusterfsd.servicebaşarıyı göstermesini ve etkinleştirilmesini engelleyebilir remotefs.target.
Ben Campbell

2
glusterfsd.serviceBirim dosyanızla gerçekten kafam karıştı . Aslında herhangi bir hizmet başlatmıyor gibi görünüyor ve aslında herhangi bir işlemi öldürüyorglusterfsd . Gluster ile ilgili başka bir birim dosyası var mı?
GregL

stor.mountBirimi de gösterebilir misiniz ?
Brian Redbeard

Yanıtlar:


3

Komutu izleyerek systemd önyükleme sırasını analiz edebilirsiniz. Çıktı dosyasını SVG destekli bir web tarayıcısı kullanarak görüntüleyin.

systemd-analyze plot > test.svg

Bu çizim size son önyüklemenin zamanlama istatistiklerini sağlayacaktır, bu da size soruna daha açık bir bakış açısı sağlayacaktır.

İçine mountkomutlar ekleyerek NFS montaj sorunumu çözdüm /etc/rc.local. Ancak emin değilim, hızlı bir düzeltme için denemeye değer, glusterd entegrasyonu ile çalışacak mı? Systemd'yi rc.local çalıştırmak için aşağıdaki koşulu yerine getirmelisiniz:

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

1

Başkaları tarafından önerildiği gibi; Ben aslında 'glusterfsd' bağımlılığı olup olmadığını, başka bir şey genel bir gecikme yerine emin değilim, örneğin 'node4' çözmek ve NFS paylaşımını başarılı bir şekilde bağlamak için başarılı olması gereken bir DNS arama.

Kurulumlarımızın çoğunda, DNS'ye bağımlı olan diğer hizmetlerin başarıyla başlayabilmesi için mevcut olması gereken yerel bir doğrulama çözümleyicisi kullanıldığından bu gecikmeyi yaşadık.

Bunun çözümü, başarılı bir şekilde (çıkış 0) veya denemenin (çıkış 1) zaman aşımına kadar temel bağımlılıkların kullanılabilirliğini test eden bir 'ExecStartPre' betiğine sahip olmaktı.

Mümkünse ana systemd lib dizininin dışında özelleştirdiğinizden emin olun. Paket dosyalarının değiştirilmesi, birlikte gelen bir sonraki güncellemede bunların üzerine yazılacakları anlamına gelir.


0

Belki bunu remote-fshedefe ekleyebilirsiniz :

[Unit]
...
ConditionPathExists=/stor

0

Belki bazı anketler yardımcı olabilir. Bu sistemd'den bağımsızdır. Örneğin mysql -e ';'mysql ile yararlı bir şey yapmadan önce bir döngüde kullanın .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.