RHEL neden systemd’ye geçti?

Daha önce tartıştığımız gibi, systemd bir sistem ve süreç yöneticisidir ve RHEL 7’de, iyi bilinen Upstart programının yerini almaktadır. RHEL bu kararı neden aldı? Bunun için çok iyi sebepler var, o yüzden hızlıca bir göz atalım.

Paralel hizmet başlatma

SysV initprogramını beğenmez, systemd hizmetleri paralel olarak başlatma yeteneğine sahiptir. init Program, aksine, lansmanlar hepsini tek tek. Mobil cihazların bile çok çekirdekli CPU’lara sahip olduğu bir çağda, paralel başlatmanın olmaması büyük bir sorun.

Dinamik (sıcak) servis yönetimi

USB sürücülerinin Ubuntu ve benzeri dağıtımlarda otomatik olarak açılırken önceki Fedora sistemlerine açıkça takılması gerektiğini fark ettiyseniz, bunun nedeni şudur systemd. Donanımdaki canlı değişiklikleri tespit edebilir ve gerektiğinde hizmetleri sonlandırabilir / başlatabilir. Bazıları bunun gereksiz olduğunu iddia edebilir, ancak çoğu için bilişsel yükü azaltan her şey en çok hoş karşılanır.

Ertelenmiş hizmet başlatma

systemd hizmetin başlamasını gerçekten ihtiyaç duyulduğu zamana erteleyebildiği için önyükleme sürelerini kısaltır. Basit bir örnek, ağ dosya sistemi ile ilgili hizmetlerdir. Ağa bağlı disk yoksa, bir hizmetin çalışır durumda olması mantıklı değildir.

Daha hızlı süreç iletişimi

systemd Süreçler arası iletişime geçişin paralel yetenekleri . systemd soketlere ve sistem veri yoluna paralel erişim sunarak iletişim kaynakları için işlem bekleme sürelerini önemli ölçüde azaltır.

Otomatik yeniden başlatma

Bir hizmet çökerse, systemd bunu tespit edebilir ve yeniden başlatmayı deneyebilir. Çoğu zaman, daha temel sorunlar olmadıkça, bir uygulamanın yeniden çalışmaya başlaması için gereken tek şey basit bir yeniden başlatma işlemidir.

Her neyse, systemd burada bir sistem yöneticisinin hayatını kolaylaştırır.

RHEL7’de systemd – Sistem yöneticileri için ne gibi değişiklikler var?

Tamamen systemd çıngırak olmayan bir dırdır duygusu yaşıyorsanız, haklısınız. RHEL sistem yöneticisini şaşırtarak yakalayabilecek birkaç önemli uyumsuzluk vardır. Hızlıca bir göz atalım.

Sınırlı çalışma seviyesi desteği

systemd çalışma seviyeleri için oldukça başarısız bir tanıma ve desteğe sahiptir. Tüm çalışma seviyeleri desteklenmez ve bazı hedefler için hiç olmayabilir. Bu gibi durumlarda,  komutlara systemd yanıt olarak “N” döndürür runlevelve bu hedefe karşılık gelen çalışma seviyesinin olmadığını belirtir. Sonuç olarak, Red Hat bize runlevel komutları kullanmamamızı (!) Tavsiye ediyor.

Özel komut yok

Bu acıtacak. SysV ile büyük bir artı, süreçleri yönetmek için daha iyi işlevsellik sağlamak için özel komutlar tanımlama yeteneğiydi. İle systemd, orada böyle bir seçenektir ve saplanmışsın start, stop, status, restart, vb

Yalnızca aileye özel ve etkileşimli değil

systemd (elbette) başlattığı süreçlerin kaydını tutar ve PID’lerini saklar. Ancak zorluk, systemd kendisi tarafından başlatılmayan süreçlerin üstesinden gelemeyecek olmasıdır. Ayrıca, bir kullanıcının başlattığı bir işlemle etkileşime girmesi mümkün değildir systemd. Tüm çıktı /dev/null, çıktı yakalama konusunda sahip olabileceğiniz umutları etkin bir şekilde durdurarak gider .

Bağlam yok

init Hizmetlerin aksine , tarafından başlatılanlar systemd sistemdeki herhangi bir kullanıcıdan herhangi bir ortamı devralmaz. Başka bir deyişle, PATH ve diğer sistem değişkenleri gibi bilgiler mevcut değildir ve her yeni süreç boş bir bağlamda başlatılır.

Bu sınırlamalar listesi sizi ağlatıyorsa, yine yalnız değilsiniz. systemd Linux dünyasında kutuplaştırıcı bir güç olmuştur ve “systemd sucks” da Google’da araştırma yapmak pek çok okuma materyali ortaya çıkaracaktır. 

Kapalı Olduğunda Hizmet Nasıl Otomatik Olarak Başlatılır?

İşte dağıtımlarda oldukça yaygın bir kullanım örneği. Bir programı uzun süre çalışan süreçleri olmayan bir dilde daemonize etmemiz gerekiyor: PHP! Gelen websocket bağlantılarını işlemek için bir PHP komut dosyası yazdığımı (sonuçta bir sohbet uygulaması oluşturduk!) Ve komut dosyasının konumuna yerleştirildiğini varsayalım /home/ankush/chat_server/index.php.

Websocket bağlantıları sunucuya her an ulaşabileceğinden, bu işlemin her zaman açık olması ve gelen bağlantıları izlemesi gerekir. Burada geleneksel PHP yaşam döngüsüne sahip olamayız çünkü WebSockets durum bilgili bağlantılardır ve komut dosyası ölürse bağlantı bir listedir. Her neyse, websockets için yeterli; bu betiği aracılığıyla daemonlaştırmaya nasıl gideceğimizi görelim systemd.

Tüm systemd hizmetler / etc / systemd / system içinde bulunur, bu yüzden websocket sunucu scriptimizi açıklamak için orada bir dosya oluşturalım. Kök kullanıcı olarak oturum açtığınızı varsayarsak.

# vi /etc/systemd/system/chat_server.service

ve sonra aşağıdakilere ihtiyaç vardır.
[Unit] Description=Chat Server Service After=network.target [Service] Type=simple User=ankush ExecStart=php /home/ankush/chat_server/index.php Restart=on-abort [Install] WantedBy=multi-user.target

Dosyayı kaydedin ve sonraki adım systemd daemon'u yeniden yüklemektir.

# systemctl daemon-reload

ve az önce oluşturduğumuz hizmeti başlatmak için:
 # systemctl start chat_server

Hiç hata görmüyorsanız, işte bu!
Dosyadaki çeşitli direktiflerin ne anlama geldiğine de hızlıca bir göz atalım:

[Unit] Bölüm için yeni bir hizmet birimini tanımlar 
systemd. 
In 
systemd tabiriyle, bütün hizmetler hizmet birimleri olarak bilinir.

After Yönergesi (tahmin) söyler 
systemd (soket bağlantılarının ?! taşınması alt düzey yapacak aksi takdirde) ağ hizmetleri başlatılır sonra bu hizmeti başlatmak için.

Type=simple Söyler 
systemd bu hizmet kendini çatal gerekiyordu olmadığını söyledi. 
Başka bir deyişle, herhangi bir zamanda yalnızca bir örnek çalışacaktır.
User=ankush bu hizmetin "ankush" kullanıcısı olarak çalışacağı anlamına gelir. 
Bunu "kök" olarak değiştirebiliriz, ancak güvenlik açısından kesinlikle tavsiye edilmiyor.
ExecStartanlayabileceğiniz gibi, çalıştırılacak asıl komuttur.
Restart=on-abort hizmetin iptal edildiğinde yeniden başlatılması gerektiği anlamına gelir. 
PHP'de, uzun süre çalışan işlemler bellek sızdırır ve sonunda patlar, bu nedenle buna ihtiyaç vardır.

WantedBy= Yönerge söyler 
systemd hangi hedefe (gruplar düşünün) Bu hizmet bir parçasıdır. 
Bu, hizmete işaret etmek için bu hedef içinde sembolik bağlantıların oluşturulmasına neden olur.
Genel olarak bu kadarı, 
systemd RHEL 7'de 
arka plan işlemlerini çalıştırmak için yeterlidir 
.
Yeniden başlatma mantığı için daha fazla seçenek
Yukarıdaki örnekte, yapılandırdım 
Restart=on-abortama tek seçenek bu değil. 
Daha fazlası var ve ihtiyaca göre seçim yapın.
başarısızlık - temiz olmayan çıkış kodu veya sinyali olduğunda yeniden başlatılacaktır
her zaman - aşağı, temiz veya kirli sinyal bulunduğunda yeniden başlatın
anormal - kirli sinyal, bekçi köpeği veya zaman aşımı
başarılı - yalnızca temiz bir sinyal veya çıkış kodu ile durdurulduğunda
Hizmeti Önyüklemede Başlayacak Şekilde Yapılandırma
Komut dosyasından memnun kaldığınızda ve çalıştığından emin olduktan sonra, bunu önyükleme ve başlatma sırasında tetiklenecek şekilde yapılandırmak istersiniz.
/ Etc / systemd / system'e gidin  
ve aşağıdaki enable komutunu çalıştırın (.service dosya adını sahip olduğunuz adla değiştirmeyi unutmayın)
# systemctl enable chat_server.service
Bir sembolik bağlantı oluşturduğuna dair bir onay göreceksiniz.
 Created symlink from /etc/systemd/system/multi-user.target.wants/chat_server.service to /etc/systemd/system/chat_server.service.
Sunucunuzu yeniden başlatın ve hizmetin önyüklemede başladığını görmelisiniz.