Sistemd ve süreç yumurtlama

Normalde buraya göndermeyin ama saçımı bu saçın üzerinden söküyorum. Ben başlatıldığında çatal ve diğer işlemler bir grup başlatmak için sorumlu bir Python komut dosyası var. Bu komut dosyası başlangıçta sysvinit aracılığıyla başlatıldı, ancak son zamanlarda Debian Jessie'ye geçtim, bu yüzden bunu systemd üzerinden başlatmak için uyarladım.

Ne yazık ki, çalışamayacağım bir sorunla karşılaşıyorum. Komut dosyasını doğrudan bir kullanıcı kabuğunda başlattığınızda, alt süreçlerini doğru bir şekilde başlatır ve komut dosyası çıkışlarında alt süreçler yetim kalır ve çalışmaya devam eder.

Systemd ile başlatıldığında, ana süreç çıkarsa, çocukların hepsi de çıkar (Evet, Ekranın başlattığı ve Ölü olarak göründüğü ???)

İdeal olarak ben tüm alt süreçleri öldürmeden ana komut dosyası yeniden başlatmak gerekir, eksik bir şey var mı?

Teşekkürler!

[Unit]
Description=Server commander
After=network.target

[Service]
User=serveruser
Type=forking
PIDFile=/var/Server/Server.pid

ExecStart=/var/Server/Server.py
ExecStop=/bin/kill -s TERM $MAINPID

[Install]
WantedBy=multi-user.target

Düzenleme: Muhtemelen benim için Python betiği temelde onun alt süreçleri için bir 'denetleyici' olduğunu işaret etmek önemlidir. Merkezi bir sunucudan istendiği gibi gnu ekranlarındaki sunucuları başlatır ve durdurur. Normalde her zaman çalışır, hizmet üretmez ve çıkmaz. Ancak süreçleri pid 1'e yetim kalsa bile, alt süreçleri öldürmeden komut dosyasını yeniden yükleyebileceğim durumlar var. Aslında, Python komut dosyasının işlemleri şu şekilde başlatması bile fark etmez hatta bir ebeveyn süreci.

Nasıl çalıştığına dair daha iyi bir açıklama:

• Systemd ortaya çıkar / Server.py
• Server.py, Systemd için pid dosyasını çatallar ve yazar
• Server.py daha sonra talimatlarını temel alarak gnu ekranında sunucu işlemlerini başlatır
• Server.py, sunucudan istenen tüm yeniden başlatmaları gerçekleştirmek için çalışmaya devam eder

Systemd olmadan başlatılırken, Server.py yeniden başlatılabilir ve başlattığı gnu ekranları etkilenmez. Systemd ile başlatılırken, Server.py kapatıldığında, bu ekran işlemleri pid 1'e yetim olmak yerine öldürülür.

Ben sadece kontrol grubu yerine varsayılan KillMode ayarlayarak düzeltmeyi başardı (varsayılan). Hepinize teşekkürler

Ben başlatıldığında çatal ve diğer işlemler bir grup başlatmak için sorumlu bir Python komut dosyası var.

Bu da yanlış yaptığınızı gösterir. Bir dakika içinde daha fazlası.

komut dosyası çıktığında alt işlemler artık kalmaz ve çalışmaya devam eder.

Bu doğru davranış değildir. "Ana" işlem - bu durumda, belirttiğinizden beri çatalladığınız çocuk Type=forkingçıkarsa, systemd hizmetin devre dışı bırakıldığını düşünür ve düzenli hale getirmek için devam eden diğer işlemleri (kontrol grubunda) sonlandırır .

Bazen System 5 rckomut dosyalarından systemd'ye dönüştürme basit değildir, çünkü systemd altında işleri yapmanın doğru yolu oldukça farklıdır. Systemd'de OpenVPN veya OpenStack veya OSSEC HIDS yapmanın (diyelim) doğru yolu, bir rckomut dosyasıyla aynı değildir . Çatallayan bir senaryoya sahip olmanız, daha sonra bir sürü torun sürecini ortaya çıkarmanız ve daha sonra bu torunların çalışmaya devam etmesini beklemekten çıkmanız, ossec-controldaha az iki çatal seviyesi ile de olsa aynı türden bir korkuyu sürdürdüğünüzü gösterir. Kendinizi "enable" işaretlerini kontrol eden ve sisteminizin "etkin" bölümleri için alt işlemleri çalıştıran bir "master" komut dosyası yazıyorsanız, o zaman korkunç olanla aynı hatayı yapıyorsunuz demektir ossec-control.

Sistemde böyle bir evde yetiştirilen mekanizmaya gerek yoktur. O zaten bir servis yöneticisi. Https://unix.stackexchange.com/a/200365/5132 uyarınca , systemd'de bunu yapmanın doğru yolu, "alt hizmetlere" sahip olmak için bazı tuhaf ve karışık girişimleri ortaya çıkaran bir hizmete sahip olmak değildir. Her çocuğun kendi başına tam teşekküllü bir sistem hizmeti olarak işlemesi gerekir. Daha sonra normal systemd kontrollerini kullanarak sistemin çeşitli kısımlarını etkinleştirir ve devre dışı bırakır ve başlatır ve durdurur. OSSEC HIDS durumunda görebileceğiniz gibi, basit bir şablon hizmet birimi neredeyse tüm seçenekleri kapsar (bir istisna /ubuntu//a/624871/43344 adresindedir ), systemctl enable ossec@agentlessd.serviceisteğe bağlı olarak etkinleştirmek gibi şeylerin yapılmasına izin veriragentlessdSistem 5 ile ihtiyaç duyulan korkunç "ana komut dosyası" mekanizmasına hiç ihtiyaç duymadan hizmet verebiliriz rc.

Belki de yeniden düşünmenin gerekli olduğu OSSEC HIDS kadar aşırı olmayan birçok durum vardır. Exim ve sendmail gibi MTS'ler böyledir. rcTam olarak çalıştırılmak üzere bir yapılandırma dosyasında bir grup ad hoc kabuk değişkeni bulunan bir kuyruk koşucusu, bir SMTP Gönderme dæmonu ve bir SMTP Geçiş dæmon'u oluşturan tek bir komut dosyası olabilir . Ancak bunu systemd ile yapmanın doğru yolu, üç uygun servis birimine (ikisi ilişkili soket birimlerine sahip ) ve hiç özel bir şeye sahip olmamaktır , sadece servis yöneticisinin düzenli mekanizmalarına sahip olmaktır.

Ebeveynini sadece uyuyabilir ve systemd'nin durma zamanında öldürmesini bekleyebilirsiniz.