it-swarm-tr.com

Upstart ve systemd'nin artıları / eksileri nelerdir?

Görünüşe göre systemd , bloktaki sıcak yeni init sistemi, pstart ile aynı birkaç yıl önceydi. Her biri için artıları/eksileri nelerdir? Ayrıca, her biri diğer init sistemleriyle nasıl karşılaştırılır?

187
tshepang

Hem start up hem de systemd, geleneksel SysV init sisteminin sınırlamaları ile ilgili bazı problemleri çözme girişimidir. Örneğin, bazı hizmetlerin diğer hizmetlerden sonra başlaması gerekir (örneğin, ağ çalışana kadar NFS dosya sistemlerini bağlayamazsınız), ancak SysV'de rc # .d dizinindeki bağlantıları ayarlamanın tek yolu öyle ki biri diğerinden önce. Buna ek olarak, bağımlılıklar eklendiğinde veya değiştirildiğinde, her şeyi daha sonra yeniden numaralandırmanız gerekebilir. Upstart ve Systemd, gereksinimleri tanımlamak için daha akıllı ayarlara sahiptir. Ayrıca, her şeyin bir tür Shell betiği olması ve herkesin en iyi başlangıç ​​komut dosyalarını yazmaması sorunu var. Bu aynı zamanda başlangıç ​​hızını da etkiler.

Görebildiğim bazı systemd avantajları:

  • Başlatılan her işlem kendi grubunu veya belirli bir grubunu alır.
  • Hizmetler için yuvaların ve dosya tanıtıcılarının önceden oluşturulması, xinetd'nin hizmetleri için yaptığı gibi, bağımlı hizmetlerin daha hızlı başlamasına izin verir. Örneğin, systemd syslog için/dev/log dosya tanıtıcısını açık tutacaktır ve/dev/log'a gönderilen sonraki hizmetler syslogd devralmaya hazır olana kadar iletilerinin arabelleğe alınmasını sağlar.
  • Bir hizmeti başlatmak için daha az işlem yürütülür. Bu, hizmetinizi başlatmak için bir Shell betiği yazmadığınız anlamına gelir. Bu bir hız artışı ve (IMO) ilk etapta daha kolay kurulabilecek bir şey olabilir.

Bildiğim bir dezavantaj, systemd'nin soketi/FH ön konumlandırmasından faydalanmak için, FH'nin systemd tarafından kendilerine geçmesi için birçok cinlemenin yamalanması gerekecek olmasıdır.

68
jsbillings

Arch General ML tarihinde bahsedilen systemd ifadesini gördüm. Öyleyse okuyun. H Online her zamanki gibi Linux Teknolojisi için harika bir kaynak ve araştırmaya başlamak için yerimi bulduğum yer SysV Init ve Upstart alternatifi olarak Systemd . Bununla birlikte, H Online makalesi (bu durumda) çok yararlı bir okuma değildir, arkasındaki gerçek kullanım, yararlı okumalara bağlantılar verir.

Gerçek cevap systemd duyurus . Bu, SysV initd ile neyin yanlış olduğu ve yeni sistemlerin ne yapması gerektiğine dair bazı önemli noktaları verir

  • Daha az başlamak için.
  • Ve daha paralel olarak başlamak için.

Bunu yapmanın başlıca planı, hizmetleri yalnızca gerektiği gibi başlatmak ve bu hizmet için bir soket başlatmaktır, böylece ihtiyacı olan hizmet, arka plan programı tamamen çevrimiçi olmadan önce oluşturulan sokete bağlanabilir. Görünüşe göre, bir soket gecikmeli veri kaybı olmayacaktır, bu da gecikme sırasında hiçbir veri kaybı olmayacaktır, bu daemon çevrimiçi olur olmaz ele alınacaktır.

Planın başka bir parçası da dosya sistemlerini serileştirmemek, bunun yerine talep üzerine bunları da monte etmek gibi görünüyor, bu şekilde /home/, Vb. Beklemiyorsunuz (/etc) bağlayabilir ve/veya fsck, / ve /var/ vb. Bu amaçla autofs kullanacağını söyledi.

Ayrıca, komut dosyalarının yerine .desktop Stil başlangıç ​​tanımlayıcıları oluşturma hedefi de vardır. Bu, Kabuk komut dosyalarında sıklıkla kullanılan sh ve sed gibi şeylerden tonlarca yavaş grep işlemi ve hatta daha fazla süreç çatalını önleyecektir.

Ayrıca, istenmedikçe bazı hizmetleri başlatmamayı planlıyorlar ve belki de artık ihtiyaç duyulmadıklarında onları kapatıyorlar, bluetooth modülü ve arka plan programı yalnızca örneğin bir bluetooth cihazı kullanırken gereklidir. Verilen başka bir örnek ssh daemon'udur. Bu inetd'in yapabileceği bir şeydir. Şahsen bunu sevdiğimden emin değilim, çünkü onlara ihtiyacım olduğunda gecikme anlamına gelebilir ve ssh durumunda, inetd'im tüm sistemin tehlikeye girmesi durumunda olası bir güvenlik açığı anlamına geldiğini düşünüyorum. Bununla birlikte, bu sistemi ihlal etmek için bunu kullanmanın mümkün olmadığı ve istersem bu özelliği hizmet başına ve diğer yollarla devre dışı bırakabileceğim konusunda bilgilendirildim.

Başka bir özellik, düzenli olarak programlanmış bir aralıkta veya belirli bir zamanda zaman olaylarına dayanarak başlama yeteneği olacaktır. Bu, crond ve atd'nin şimdi yaptığı şeye benzer. Bana "cron" kullanıcı desteklemeyecek söylendi rağmen. Şahsen bu en anlamsız şey gibi geliyor. Bunun çok kullanıcılı ortamlarda çalışmayan insanlar tarafından yazıldığını/düşündüğünü düşünüyorum, sistemde tek kullanıcıysanız, kök olarak çalıştırılmaktan başka kullanıcı cronunun pek bir amacı yoktur. Her gün çok kullanıcılı sistemlerde çalışıyorum ve kural her zaman kullanıcı komut dosyalarını kullanıcı olarak çalıştırıyor. Ama belki de yaptıkları öngörü yok ve hiçbir şekilde bunu yapmayacak, böylece crond veya atd çalıştıramam. sanırım geliştiriciler.

Systemd'ın en büyük dezavantajı, bazı cinlerin tam olarak yararlanmak için değiştirilmeleri gerekecek olmasıdır. Şimdi çalışacaklar, ancak özellikle soket modeli için yazılmış olsaydı daha iyi çalışırlardı.

Görünüşe bakılırsa, systemd halkının uptart ile ilgili problemi olay sistemi ve bunun mantıklı olmadığına veya gereksiz olmadığına inanıyorlar. Belki de kelimeleri en iyisidir.

Veya daha basit bir ifadeyle: kullanıcının D-Bus'ı yeni başlatmış olması hiçbir şekilde NetworkManager'ın da başlatılması gerektiğini göstermez (ancak Upstart'ın yapacağı şey budur). Diğer taraftan doğru: kullanıcı NetworkManager'ı istediğinde, bu kesinlikle D-Bus'ın da başlatılması gerektiğinin bir göstergesidir (bu kesinlikle çoğu kullanıcının beklediği şeydir, değil mi?).
İyi bir başlangıç ​​sistemi sadece ihtiyaç duyulan şeylere ve talep üzerine başlamalıdır. Ya tembel ya da paralel ve önceden. Ancak, gerekenden daha fazla başlamamalıdır, özellikle de bu hizmeti kullanabilen her şey kurulmamalıdır.

Daha önce de söylediğim gibi, bu systemd'nin duyurus bölümünde çok daha kapsamlı bir şekilde tartışılmıştır.

29
xenoterracide

Çoğunuzun unuttuğu bir şey de cgroups içindeki süreçlerin organizasyonu.

Yani eğer sistemd bir şey başlatırsa, bu şeyi kendi grubuna koyar ve sürecin o gruptan kaçması için (ayrıcalıklı olmayan) bir araç yoktur. İşte bunun sonuçları:

  • Birçok kullanıcılı büyük bir sistemin yöneticisi kötü niyetli kullanıcıları/işlemleri tanımlamak için etkili yeni yöntemlere sahiptir.
  • CPU zamanlaması için öncelikler "Wonder autocgroup patch" ile yapıldığı gibi daha iyi belirlenebilir.
11
enaut

İlk tasarım taslaklarından (ve uptart da dahil olmak üzere mevcut init sistemlerinin ayrıntılı bir eleştirisinden ve systemd'nin bunları nasıl düzeltmeyi önerdiğinden) başlayarak systemd'ye çok ayrıntılı bir bakış için ana sayfa adresine gidin. Zamanla, başlangıçta LWN . Sadece orada systemd (veya pulseaudio) herhangi bir söz asla flamewars tetikler tavsiye edilir.

IMVHO (ve bir Fedora kullanıcısı olarak) çok memnunum . Bu satırdaki bir şey, mevcut Linux sistemlerinin karmaşıklığını ele almak için çoktan gecikmişti. Fedora bir süre uptart kullandı, ancak hiçbir zaman değişmeyen init komut dosyaları çalıştıran sysvinit için süslü bir yedek olma aşamasından hiç çıkmadı. Önyükleme yapılandırmasını basitleştirme sözü, tekrar karşılıklı bağımlılıkların manuel olarak ayarlanması pahasına gelir ve bu işe yaramaz. systemd bağımlılıkları kendiliğinden belirler (veya sadece bağımlılıklara bakılmaksızın bir şeyler başlatmaya izin verir, kendilerini sıralarlar). Bir başka büyük avantaj (bazıları ciddi bir dezavantaj olduğunu söylüyor) Linux'a özgü özellikleri kabzaya kadar kullanmasıdır (özellikle gruplar, bir arka plan programının ve tüm torunlarının izole edilmesine izin verir, bu nedenle kaynakları izlemek, sınırlamak veya onları öldürmek kolaydır. bir grup; diğerleri var).

8
vonbrand

Günlük Kaydı - Systemd, günlük kaydı söz konusu olduğunda kelimenin tam anlamıyla WinSXS klasörü gibidir, sürücünüzde yemeye devam edeceği dosya boyutunu manuel olarak silmediğiniz veya küçültmediğiniz sürece kopyaların kopyalarını oluşturur. Ben buna boot loader cookies diyorum.

3
Bert