systemd yazılım paketi, bir Linux işletim sistemi için temel yapı taşları sağlar. Kullanıcı alanını önyüklemek ve kullanıcı süreçlerini yönetmek için kullanılan bir init sistemi olan “System and Service Manager” sistemini içerir.

Systemd, servis yapılandırmasını ve davranışını Linux dağıtımları arasında birleştirmeyi amaçlar. UNIX System V ve BSD init sistemlerinin yerini alır. 2015’ten bu yana, Linux dağıtımlarının çoğunluğu systemd’i benimsemiştir ve fiilî bir standart olarak kabul edilmektedir.

Systemd adı, d harfini ekleyerek Unix’in adlandırma kurallarına uymasını sağlar. Ayrıca bir kişinin hızlı bir şekilde adapte olma yeteneğini ve problemleri çözmede doğaçlama yapmayı ifade eden “System D” terimiyle de oynuyor.

Tasarım

Başlangıçta systemd geliştiren Red Hat için çalışan yazılım mühendisleri olan Lennart Poettering ve Kay Sievers, init daemon’unun verimliliğini birkaç şekilde aşmaya çalıştı. Bağımlılıkları ifade etmek için yazılm çerçevesini geliştirmek, aynı zamanda sistem önyüklemesi sırasında aynı anda veya paralel olarak daha fazla işlem yapılmasını sağlamak ve kabuğun hesaplama yükünü azaltmak istediler.

Poettering, systemd geliştirmeyi “asla bitmedi, asla tamamlanmadı ancak teknolojinin ilerlemesini takip ediyor” olarak tanımlamaktadır. Poettering Mayıs 2014’te aşağıdaki üç genel işlevi sağlayarak systemd’i “dağılımlar arasındaki anlamsız farklılıkları” birleştirmek olarak tanımladı:

  • Bir sistem ve servis yöneticisi (çeşitli yapılandırmaları ve servislerini uygulayarak hem sistemi yönetir)
  • Bir yazılım platformu (diğer yazılımların geliştirilmesinde temel olarak kullanılır)
  • Uygulamalar ve çekirdek arasındaki yapıştırıcı (çekirdek tarafından sağlanan işlevleri ortaya çıkaran çeşitli arayüzler sağlar)

Systemd yalnızca init daemon’unun adı değildir, aynı zamanda systemd init daemon’una ek olarak journald daemon’u, logind ve networkd ve diğer birçok düşük seviye bileşenlerini içeren tam yazılım paketini ifade eder. Ocak 2013’te Poettering; systemd’i tek bir program değil, 69 ayrı ikili dosya içeren büyük bir yazılım paketi olarak tanımladı. Entegre bir yazılım paketi olan systemd, kontrol altında yürütülen kabuk komut dosyalarının yanı sıra geleneksel init daemon tarafından kontrol edilen başlangıç dizilerini ve çalışma seviyelerini değiştirir. Systemd ayrıca kullanıcı sistemlerini, sistem konsolunu, cihaz hotplugging (bkz. udev), zamanlanmış çalıştırma (cron yerine), logging, ana bilgisayar adları ve yerel ayarları kullanarak Linux sistemlerinde yaygın olan diğer birçok hizmeti birleştirir.

Init daemon gibi systemd, systemd de dâhil olmak üzere arka plan işlemleri olan diğer daemon’ları yöneten bir servistir. Systemd; önyükleme sırasında başlayacak ilk arka plan programı ve kapanma sırasında sonlanan son arka plan programıdır. Systemd daemon, kullanıcı alanının işlem ağacının kökü olarak işlev görür; ilk işlem (PID 1), orijinal üst öge sona erdiğinde bir sürecin üst ögesi yerine geçtiğinden Unix sistemlerinde özel bir role sahiptir. Bu nedenle ilk süreç, özellikle günlükleri izlemek amacıyla çok uygundur; systemd, belirli bir alanda geleneksel yaklaşıma göre gelişmeye çalışır; bu da genellikle otomatik olarak yeniden başlatma işlemine başlamaz ancak daha fazla izleme yapılmadan yalnızca bir kez başlatır.

Systemd, başlatma sırasının ögelerini paralel olarak yürütür; bu, geleneksel başlatma sırasının sıralı yaklaşımından daha hızlıdır. İşlemler arası iletişim için (IPC), systemd Unix alan soketlerini ve D-Bus’u çalışan servis çalışanlarına açık hâle getirir. Systemd’in kendisinin durumu, gelecekteki hatırlama için anlık görüntüde de korunabilir.

Çekirdek Bileşenler ve Kütüphaneler

Entegre yaklaşımını takiben systemd ayrıca başlangıç kabuğu komut dosyaları, pm-utils, inetd, acpid, syslog, watchdog, cron ve atd dâhil olmak üzere çeşitli servis araçları ve yardımcı programların yerine geçer. systemd’in çekirdek bileşenleri aşağıdakileri içerir:

  • systemd, Linux işletim sistemleri için bir sistem ve servis yöneticisidir.
  • systemctl, sistemin ve servis yöneticisinin durumunu denetlemek ve kontrol etmek için kullanılabilir.
  • systemd-analyze, sistem açılış performans istatistiklerini belirlemek ve sistemden ve servis yöneticisinden diğer durum ve izleme bilgilerini almak için kullanılabilir.

systemd, işlem tanmlayıcılarını (PID’leri) kullanmak yerine Linux çekirdeğinin cgroups alt sistemini kullanarak işlemleri izler; bu nedenle daemon’lar iki çatalla bile değil, systemd’den “kaçamaz”. Systemd sadece cgroups kullanmaz, aynı zamanda Linux konteynerlerinin oluşturulmasını ve yönetimini kolaylaştıran iki yardımcı program olan systemd-nspawn ve machinectl ile onları güçlendirir. 205 sürümünden bu yana systemd ayrıca Linux çekirdek gruplarına bir API olan ControlGroupInterface’yi de sunar. Linux çekirdek cgroups’u çekirdekleri destekleyecek şekilde uyarlanmıştır ve birleşik bir hiyerarşiyi destekleyecek şekilde değiştirilmektedir.

Yardımcı Bileşenler

Bir Linux init sistemi sağlamadaki birincil amacının yanı sıra systemd takımı aşağıdaki bileşenler de dâhil olmak üzere ek işlevler sağlayabilir:

journald

systemd-journald; olay günlüğünden sorumlu bir servistir, yalnızca günlük kütüğü olarak kullanılan ikili dosyalar eklenmiştir. Sistem yöneticisi, sistem olaylarını systemd-journald, sysloging veya rsyslog ile kaydetmeyi seçebilir. İkili formatın bozulma potansiyeli çok fazla hararetli tartışmalara neden oldu.

logind

systemd-logind, kullanıcı girişlerini ve oturumlarını çeşitli şekillerde yöneten bir servistir. Çoklu oturum iyileştirmeleri sunan ve artık bakımı yapılmayan ConsoleKit’in yerini alan entegre bir oturum açma yöneticisidir. X11 ekran yöneticileri için oturum açmak için anahtar minimum miktarda taşıma gerektirir. Systemd sürümü 30’da entegre edildi.

networkd

networkd, ağ arayüzlerinin yapılandırmasını gerçekleştiren bir servistir: 209 sürümünde ilk entegre edildiğinde destek, statik olarak atanmış adreslerle ve köprüleme yapılandırması için temel destekle sınırlıydı. Temmuz 2014’te IPv4 ana bilgisayarları için DHCP sunucusu ve VXLAN desteği gibi yeni özellikler eklenerek systemd sürümü 215 yayımlandı.

tmpfiles

systemd-tmpfiles; geçici dosya ve dizinlerin oluşturulmasını ve temizlenmesini sağlayan bir yardımcı programdır. Normalde başlangıçta bir kez ve ardından belirli aralıklarla çalıştırılır.

timedated

systemd-timedated; sistem saati, sistem saat dilimi veya UTC ile yerel saat dilimi sistem saati arasındaki seçim gibi saatle ilgili ayarları kontrol etmek için kullanılabilecek bir servistir. D-Bus üzerinden erişilebilir. Systemd sürümü 30’da entegre edildi.

udevd

udev; Linux çekirdeği için bir aygıt yöneticisidir ve /dev dizinini ve aygıt yazılımı yükleme de dâhil olmak üzere aygıt eklerken / çıkarırken tüm kullanıcı alanı eylemlerini işler. 2012 yılının Nisan ayında udev için kaynak ağacı systemd kaynak ağacına birleştirildi.

libudev

Üçüncü taraf uygulamaların udev kaynaklarını sorgulamasını sağlayan udev kullanımı için standart kütüphanedir.

systemd-boot

systemd-boot, eskiden gummiboot olarak bilinen bir önyükleme yöneticisidir. Kay Sievers, revizyon 220 ile sisteme birleştirdi.

Systemd Yapılandırması

Systemd, yalnızca düz metin dosyaları aracılığıyla yapılandırılmıştır.

Systemd, her daemon için başlatma talimatlarını geleneksel olarak kullanılan her gün başına kullanılan başlangıç kabuğu komut dosyalarının yerine bir bildirim dili kullanan bir yapılandırma dosyasında (“birim dosyası (unit file)” olarak adlandırılır) kullanır. Birim dosyası (unit-file) türleri şunları içerir:

  • .service
  • .socket
  • .device
  • .mount
  • .automount
  • .swap
  • .target
  • .path
  • .timer (bir cron benzeri iş çizelgeleyicisi olarak kullanılabilir)
  • .snapshot
  • .slice (süreçleri ve kaynakları gruplamak ve yönetmek için kullanılır)
  • .scope

Yapılandırma Dosyaları Hiyerarşisi

man systemd.unit yapılandırma dosyalarının hiyerarşisini açıklar. Yolları derleme sırasında tanımlanır.

Tarihçe

Lennart Poettering ve Kay Sievers 2010 yılında systemd geliştirme projesine başladı.

Mayıs 2011’de Fedora, varsayılan olarak sisteme izin veren ilk büyük Linux dağıtımı oldu.

Ekim 2013 ile Şubat 2014 arasında Debian e-posta listesinde Debian Teknik Komitesi arasında uzun bir tartışma meydana geldi, hangi init sisteminin Debian 8 “jessie”de varsayılan olarak kullanılacağını ve systemd’in lehine bir kararla sonuçlandığını tartıştı. Tartışma geniş çapta duyuruldu ve kararın ardından tartışmalar Debian posta listesinde devam etti. Şubat 2014’te Debian’ın kararının alınmasından sonra Mark Shuttleworth, blog’unda Ubuntu’nun systemd’i uygulamak için takip edeceğini açıkladı.

Kasım 2014’te Debian Geliştirici Joey Hess; Debian Teknik Komitesi üyeleri Russ Allbery ve Ian Jackson ve systemd’deki paket koruyucu Tollef Fog Heen görevlerinden istifa etti. Dördü de kamuya açık Debian posta listesindeki ve kişisel blog’lardaki kararlarını düzenli bir bakımı neredeyse imkânsız kılan Debian ve açık kaynak topluluğu içerisinde systemd entegrasyonu konusundaki devam eden ihtilaflarla ilgili olağanüstü stres seviyelerine maruz kalmalarıyla haklı buldu.

Ağustos 2015’te systemd, machinectl kabuğu ile çağrılabilen bir giriş kabuğu sağlamaya başladı.

Eylül 2016’da ayrıcalıklı olmayan bir kullanıcının systemd’e karşı hizmet reddi saldırısı gerçekleştirmesine izin veren bir güvenlik hatası tespit edildi. Musl geliştiricisi Rich Felker, bu hatanın büyk bir “sistem geliştirme tasarım kusuru” ortaya çıkardığını belirtti. 2017’de “kötü amaçlı bir DNS sunucusu” tarafından “hizmetin aksamasına izin veren” CVE-2017-9445 sistemindeki başka bir güvenlik hatası tespit edildi.

Benimseme

Çoğu dağıtım systemd’i varsayılan olarak önyüklerken bazıları diğer init sistemlerinin kullanılmasına izin verir: Bu durumda init sisteminin değiştirilmesi uygun paketleri kurarak mümkündür. Devuan adında bir Debian çatalı, systemd’den uzak durmak için geliştirildi ve kararlı kullanım için 2.0 sürümüne ulaştı.

Diğer Yazılımlarla Entegrasyon

Systemd ve GNOME masaüstü ortamı arasındaki birlikte çalışabilirliği artırmak amacıyla systemd ortak yazarı Lennart Poettering, GNOME Projesi’nden sistemi GNOME 3.2’nin dışsal bir bağımlılığı hâline getirmesini istedi.

Kasım 2012’de GNOME Projesi, temel GNOME işlevselliğinin systemd’e dayanmaması gerektiği sonucuna vardı. Bununla birlikte GNOME 3.8 logind ile ConsoleKit API arasında bir derleme zamanı seçeneği sundu, birincisi o zaman sadece systemd tarafından sağlandı. Ubuntu ayrı bir logind binary’i sağladı ancak systemd çoğu Linux dağıtımları için GNOME’un fiilî bir bağımlılığı hâline geldi, özellikle ConsoleKit artık aktif olarak korunmuyor ve upstream bunun yerine systemd logind kullanımını tavsiye ediyor. Gentoo Linux geliştiricileri ayrıca OpenRC’deki bu değişiklikleri uyarlamaya çalıştı ancak uygulama çok fazla hata içeriyordu ve bu da dağıtımın systemd’i GNOME bağımlılığı olarak işaretlenmesine neden oldu.

GNOME, logind ile daha fazla entegre oldu. Mutter sürüm 3.13.2’den itibaren logind, Wayland oturumları için bir bağımlılıktır. Systemd yalnızca Linux’u desteklediğinden ve Linux çekirdek API’lerinin yoğun kullanımı nedeniyle diğer işletim sistemlerine kolayca taşınamadığından OpenBSD gibi diğer işletim sistemlerinde uyumlu API’ler sunma ihtiyacı vardır.

Eleştiri

Systemd’in tasarımı, özgür yazılım topluluğu içindeki tartışmaları ateşledi. Eleştirmenler; systemd’in Unix felsefesini ihlal ettiğini iddia ederek systemd’i aşırı karmaşık ve sürekli olarak acı çeken bir özellik olarak görüyorlar. Aynı zamanda birbirine bağlı bir bağımlılık sistemi oluşturduğuna dair endişeler vardır, bu nedenle dağıtımlara çok az seçenek sunmakla kalmaz, daha fazla kullanıcı alanı yazılımı bileşenlerine bağlı olarak sistemi benimsemeyi tercih eder.

2012 röportajında Slackware’nin lideri Patrick Volkerding, tasarımının dar tanımlanmış işlevselliklere sahip birbirine bağlı yardımcı yazılımların Unix felsefesine aykırı olduğuna inandığını belirterek systemd mimarisi hakkındaki çekincelerini dile getirdi. Ağustos 2018’den itibaren Slackware systemd’i desteklemiyor veya kullanmıyor ancak Volkerding buna geçme olasılığını reddetmedi.

Ocak 2013’te Lennart Poettering, En Büyük Efsaneler (The Biggest Myths) adlı bir blog yazısında systemd hakkındaki endişeleri gidermeye çalıştı.

Mart 2014’te Eric S. Raymond; systemd’in tasarım hedeflerinin misyon sürünürlüğü ve yazılım şişmesine eğilimli olduğunu belirtti. 2014 yılının Nisan ayında Linus Torvalds; kilit bir sistem geliştiricisi olan Kay Sievers’in kullanıcılara karşı tutumu ve Sievers tarafından Linux çekirdeğinin kendisine gönderdiği değişiklikler konusunda hata raporları olduğunu dile getirdi. Nisan 2014’ün sonlarında kabul edilmesine karşı çeşitli nedenler içeren bir web sitesiyle systemd’i boykot etme kampanyası başlatıldı.

InfoWorld‘de yayınlanan Ağustos 2014 tarihli bir makalede Paul Venezia; systemd tartışması hakkında yazdı ve tartışmayı Unix felsefesinin ihlal edilmesine ve “kesinlikle yanlış yapamayacağına inanan muazzam egolara” bağladı. Bu makale ayrıca Microsoft Windows’ta geniş bir işlevsel kapsamı olan kritik bir sistem bileşeni olan svchost.exe’ninkine benzer bir systemd mimarisini karakterize ediyor.

Eyll 2014’te ZDNet röportajında önde gelen Linux çekirdeği geliştiricisi Theodore Ts’o; systemd’in merkezî tasarım felsefesi konusundaki anlaşmazlığın teknik kaygılardan çok, Linux ekosistemini düzene sokma, açık kaynak topluluğunun parçalarını yabancılaştırma ve marjinalleştirme yönünde tehlikeli bir genel eğilime işaret ettiğini ve alternatif projeler için çok az yer bıraktığını belirtti. GNOME projesinde standart dışı yapılandırmalara karşı tutumu ile benzerlikler gösterdi. Sosyal medyada Ts’o daha sonra Sievers ile ortak geliştiricisi Lennart Poettering’in de GNOME’nin geliştiricilerinin tutumlarını karşılaştırdı.

6 Temmuz 2015 tarihinde systemd GitHub sayfasında systemd kodundaki DNS sunucularının kodlanmasıyla ilgili endişeleri dile getiren bir sorun gündeme getirildi. Systemd geliştiricisi Lennart Poettering; gerçek DNS olmadığını, daha ziyade kodu doğrudan programın içine gömülmüş yedek DNS olduğunu söyledi. Yedek DNS’nin yalnızca “… hiç kimsenin bir şeyi yapılandırma…” yapamadığı ve yapılandırma dosyalarındaki yıkıcı hatalar veya ağdaki DHCP eksikliğinden kaynaklanan bağlantı sorunlarını önlemek için kullanıldığını ekledi. Poettering’in açıkladığı gibi sistem “… doğru olanı yapmalı…” eğer örnek olarak /etc dizini eksik veya boşsa. Poettering ayrıca systemd ile kurulu olan /etc/systemd/resolved.conf dosyasının yedek DNS ile tam olarak aynı DNS sunucularını içerdiğini ve böylece /etc dizininin boş veya mevcut olmasına bakılmaksızın aynı işlemi gerçekleştirdiğini de not etmiştir.

Çatallar ve Alternatif Uygulamalar

eudev

2012 yılında Gentoo Linux projesi, systemd mimarisine bağımlılığı önlemek için bir udev çatalı oluşturdu. Ortaya çıkan çatala eudev denir ve systemd olmadan udev işlevselliği yapar. Projenin belirtilen bir hedefi, eudev’i herhangi bir Linux dağıtımından veya init sisteminden bağımsız tutmaktır.

elogind

Elogind, systemd projesinin “logind”idir, bağımsız bir daemon olarak çıkarılmıştır. Bir sistemde oturum açan kullanıcı grubunu ve grafiksel olarak konsolda mı yoksa uzaktan mı oturum açtıklarını öğrenmek için PAM ile bütünleşir. Elogind; bu bilgiyi standart org.freedesktop.login1 D-Bus arabirimi aracılığıyla ve ayrıca systemd’in standart /run/systemd düzenini kullanarak dosya sistemi aracılığıyla sunar. Elogind, “libsogd” tarafından sunulan olanakların bir alt kümesi olan “libelogind” de sağlar. Ayrıca bir “libelogind.pc” pkg-config dosyası var.

uselessd

2014 yılında uselessd hafif bir sistem çatalı olarak oluşturuldu. Proje; bir init sistemi için gereksiz kabul edilen özelliklerin ve programların kaldırılmasını ve diğer algılanan hataların giderilmesini amaçlamıştır. Projenin geliştirilmesi, Ocak 2015’te sona ermiştir.

Uselessd; musl ve µClibc kütüphanelerini destekledi, bu yüzden gömülü sistemlerde kullanılmış olabilir, systemd sadece glibc’yi destekler. Uselessd projesi; platformlar arası uyumluluğun yanı sıra ileride Linux yapısı için mimari revizyonlar ve yeniden yapılanma konusunda daha fazla iyileştirme planlamıştı.

systembsd

2014 yılında OpenBSD için bu API’lerın alternatif uygulamalarını sağlamak amacıyla “systembsd” adlı bir Google Summer of Code projesi başlatıldı. Orijinal proje geliştiricisi, Linux’tan OpenBSD’ye geçişini kolaylaştırmak için başladı. Projenin gelitirilmesi, Temmuz 2016’da durduruldu.

Systembsd projesi; bir init değişimi sağlamamıştır ancak OpenBSD’yi hostnamed, timedated, localed ve logind için uyumlu daemon’lar ile sunmayı amaçlamıştır. Proje, yeni systemd benzeri işlevler oluşturmadı ve yalnızca yerel OpenBSD sistemi üzerinde bir sarıcı işlevi görüyordu. Geliştiricinin sistem tabanının bir ana sistemin bir parçası olarak değil, port sisteminin bir parçası olarak kurulabilmesi amaçlandığını belirterek “systemd ve *BSD’nin temel olarak felsefe ve geliştirme uygulamaları açısından farklılık gösterdiğini” belirtti.

consolekit2

ConsoleKit; Ekim 2014’te Xfce geliştiricilerinin Linux dışındaki işletim sistemlerinde hâlâ muhafaza edilmeleri ve mevcut özelliklerinin sunulmasını istemek üzere çatallandırdı. Orijinal depoyu uzun vadede yeniden canlandırma olasılığını ortadan kaldırmazken ana geliştirici ConsoleKit2’yi sistematik olarak olgunlaşana kadar geçici bir gereklilik olarak görmektedir.

Geliştirme; Aralık 2017’de sona erdi ve proje geçersiz olabilir.

loginkit

LoginKit, belirli bir init sistemine bağımlı olmadan sistemd-logind’e bağımlı olan paketlere izin veren bir logind (systemd-logind) shim’i uygulama girişimiydi.

Proje, Şubat 2015’ten beri geçersizdir.

notsystemd

Notsystemd, tüm systemd’in herhangi bir init sisteminde çalışan özelliklerini uygulamayı amaçlamaktadır. Systemd-nspawn’ı çalıştırmak için Systemd’in yüklü olması gerekmeden Parabola GNU/Linux-libre geliştiricileri tarafından geliştirme araçlarıyla paketler oluşturulmak istendi.

Ayrıca Bakınız

Free and open-source software portal

Linux portal

References