Mustafa Bektaş Tepe

systemd, Linux için bir sistem ve servis yöneticisidir ve SystemV ve Upstart’ın yerini almaktadır. systemd, servis yapılandırmasını ve davranışını Linux dağıtımları arasında birleştirmeyi amaçlar.
Systemd’nin amacı; bilgisayardaki sistem ve servislerin çalışmasını organize etmektir. Yani modern linux işletim sisteminde başlama (startup) ve sunucu (server) proseslerini yöneten sistem olarak systemd sistem kaynaklarının, arkaplan (daemon) ve diğer süreçlerin (process) etkinleştirilmesi için bir mekanizma sağlar. Bu yönetimi, systemctl, journalctl, notify, analyze, cgls, cgtop, loginctl ve nspawn olarak adlandırılan araçlar sayesinde gerçekleştirir.

Arkaplan süreçleri (daemons) adından da anlaşılabileceği gibi başlatıldıklarında görevlerini yürütmek üzere arka planda bekler veya çalışırlar. Bu süreçler tipik olarak işletim sistemi yüklenirken (boot) başlatılırlar ve sistem kapatılana ya da manuel olarak durdurulana kadar arkaplanda (background) çalışmayı sürdürürler. Genel bir ilke olarak arkaplan süreç adları genellikle d harfi ile sonlanır (sshd – ssd deamon gibi).

Systemd ortamında aşağıdaki kavramlar yaygın olarak kullanılır:
• Daemon: başlatıldıklarında görevlerini yürütmek üzere arka planda bekleyen veya çalışan süreçler.
• Socket: Bağlantıları dinlemek için arkaplan süreçleri tarafından kullanılır. Yerel ve uzak istemciler için ana iletişim kanalıdır. Süreçler tarafından yaratılırlar.
• Service: Genellikle bir ya da daha çok sayıda arkapan sürecine işaret eder Servisi başlatma/durdurma işlemi genellikle sistem durumunda (state) kalıcı bir değişikliğe neden olur.

Eskiden init dediğmiz ve işletim sistemi kernel yüklemesinden sonra çalışan ve PID (Process ID) 1 olan süreçlerle yönetilmekte idi. Çekirdek kendini başlattığı (belleğe yüklendiği, çalışmaya başladığı ve aygıt dosyaları, veri yapıları ve benzeri şeyleri başlattığı zaman) ve kullanıcı seviyeli bir program olan initsürecini başlattığında, kendi üstüne düşen açılış işlemlerini bitirmiş olur. Bundan dolayı init her zaman için ilk süreçtir ve süreç numarası da daima 1’dir. init süreci /etc/inittab dosyasını okuyup sistemin hangi Run Level’dan başlayacağına karar verirdi. Aşağıda /etc/inittab dosyasından bir kesit sunulmaktadır.

# Default runlevel. The runlevels used by RHS are:
# 0 – halt (Do NOT set initdefault to this)
# 1 – Single user mode
# 2 – Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 – Full multiuser mode
# 4 – unused
# 5 – X11
# 6 – reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

Buradaki id:3:initdefault: satırı bizim işletim sistemimizin RunLevel 3 ‘den başlayacağını göstermektedir. Red Hat sistemlerde RunLevel’lar

• 0 – halt (Sistemi kapatmak –poweroff veya halt- için kullanılan runlevel)
• 1 – Single user mode (Sistemi kurtarmak için kullanılan ve network ayarlarının aktive edilmediği tekli kullanıcı mode’u. Bazı yerlerde S veya s olarak da adlandırılır.
• 2 – Multiuser NFS olmadan çoklu kullanıcı mode’u (Bu runlevel 3. Runlevel ile genel olarak aynıdır. Tek fark network ayarlarını içermemesidir.)
• 3 – multiuser mode (Network ayarlarını nda aktive edildiği ve genellikle kullanılan RunLevel’dır.
• 4 – kullanılmıyor.
• 5 – X11 (Runlevel 3 e ek olarak görsel ekranın- ki biz buna X veya X11 de deriz- da başlatıldığı runlevel. Runlevel 3’den sonra en çok tercih edilen runlevel’dır.)
• 6 – reboot (Sistemin kapatılıp tekrar açıldığında kullanılan RunLevel’dır.

İnit süreci ön tanımlı runlevel’ı ayarladıktan sonra sistemde /etc/rc.d/init.d/ altında bulunan ve rpm paketleri içinde gelen servis scriptlerini (bunlar bir shell scripttir!) çalıştırır. Örnek olarak eğer runlevel 3 de isek ve sshd servisi çalışacaksa bunun başlangıç scripti /etc/rc.d/init.d/sshdaltında yer almakta. Bunun runlevel 3 de çalışmasını da /etc/rc.d/rc3.d/S55sshd scripti sağlamakta idi. Buradaki S harfi bunun start edilleceği, 55 ise başlangıç sırasını belirtmektedir.

# ls -la /etc/rc.d/rc3.d/S55sshd lrwxrwxrwx 1 root root 14 Jun  6  2011 /etc/rc.d/rc3.d/S55sshd -> ../init.d/sshd

Linux sistemlerde yaygın olarak kullanılmaya başlayan systemd 30 Mart 2010’da Lennart Poettering ve Kay Sievers tarafından init sisteminin alternatifi olarak yazıldı. Bu yapı yeni Linux sistemleri ile (RedHat tabanlı sistemlerde RHEL 7 ile, SLES’de SLES 12 de, Debian da Debian 8 ile) yerini systemd ye bıraktı. Her ne kadar systemd üzerinde tartışmalar devam etse ve bazıları UNIX felsefesine aykırı da bulsa systemd’nin önümüzdeki yıllarda daha fazla kabul göreceği de düşünürsek systemd’yi önyargısız olarak inceleyip,öğrenmekte fayda var.

systemd, işlemlerini derlenmiş binary programlarla yapar. Kullanıcının müdahalesine pek müsaade etmez. Bir takım parametreleri kontrol etmenize izin verilse de genelde işlemler önceden ayarlanmıştır. systemd öncesinde kullanılan hizmet programları (Upstart veya sysvinit), uyguladıkları prosedürleri kabuk -shell- aracılığıyla yaparlar. Bu sebeple, kullanıcıların, kabuk -shell- kullanarak kişisel ayarlamalar yapabilme imkanı vardır. systemd ise kabuk üzerinden işlem yapmaz. Bu nedenle, fayda ve mahzurları üzerinde çok tartışılmaktadır. Açık kaynak kodlu, özgür yazılım mantığına ters olduğu için kabul etmeyenler, systemd programının, windows svchost.exe olmaya aday olduğu belirtmektedir. Kullanılabilir bularak, tercihli veya varsayılan olarak dağıtımlara dahil edenler de bulunmaktadır.

Servis Yönetimi

Systemd için gerçekleştirilecek işlemlerin çoğu unit adı verilen elemanlarla ilgilidir. Unit elemanları, systemd nin anlayacağı şekilde yapılandırılmış dosyalardır. Her bir unit elemanı, sonuna . nokta işaretinden sonra verilen uzantı kullanılarak gruplandırılır. Bu sayede bir unit elemanının hangi işlev ile ilgili olduğu temsil edilir.

Unit file default olarak “/etc/systemd/system/” dizini altında bulunur. Bu dizinlerde birbirinden farklı uzantılara sahip bir çok dosya vardır. Bu uzantılar birbirinden farklı unit tiplerini gösterir. .service uzantısına sahip dosyalar servislere ait unit dosyaları tutar. .target uzantılı dosyalar site bir çok service unit’nin gruplanmış halini gösterir. .mount uzantılı dosyalar sisteme mount edilmesi istenilen disk bölümlerini için tanımlanmış configleri gösterirken. .swap uzantılı dosyalar ise swap alanları için yapılandırma dosyalarını içerir.

Örneğin, mysqld.service unit elemanı MySQL hizmeti ile ilgilidir. tmp.mount unite elemanı ise tmp disk bölümünün mount edilmesi ile ilgili bir elemandır. Komutları kullanırken sonu .service ile biten elemanların .service kısmını yazmasanız da systemd bunu anlayacaktır. Ancak .mount veya .path vb. unit elemanların uzantısını mutlaka yazmanız gerekir. Konvansiyonu takip etme açısından her zaman .service kısmını da yazmanızı tavsiye ediyoruz. TAB otomatik tamamlama işlevi zaten baş kısmını yazdığınız unit elemanının gerisini kendisi tamamlayacaktır.

[root@localhost ~]# systemctl -t help
Available unit types:
service
socket
busname
target
snapshot
device
mount
automount
swap
timer
path
slice
scope

Mevcut unit tiplerini listelemek için aşağıdaki komutu kullanın:

Servisleri Başlatma ve Durdurma

• Bir systemd servisini başlatmak ve o servise ait unit dosyasında bulunan kuralları çalıştırmak için start komutunu kullanıyoruz. Verdiğimiz komut sistemin çalışma durumunu etkileyeceğinden başına sudo eklemek gerekecektir. Zaten root kulanıcısı ile oturum açtıysanız sudo ifadesine gerek yoktur.

sudo systemctl start application.service

Yukarıda bahsettiğimiz konuyu tekrar hatırlatalım. Buradaki örnekte görülen application.serviceifadesindeki .service kısmını yazmasanızda komut çalışacaktır.

sudo systemctl start application

• Sisteminizde mevcut durumda halen çalışan bir servisi durdurmak için stop komutunu kullanıyoruz.

sudo systemctl stop application.service

• Bir servis mevcut durumda çalışıyorsa ve tekrar başlatmak istersek restart komutunu kullanabilirsiniz.

sudo systemctl restart application.service

Çalışan bir servis ile ilgili ayar dosyalarında bir değişiklik yaptınız ancak servisi tamamen yeniden başlatmaya gerek kalmadan, ayarların etkin olmasını isterseniz reload komutunu kulanabilirsiniz.

sudo systemctl reload application.service

• Yeniden başlatacağınız servisin reload kabiliyeti olmayabilir. Reload işe yaramaz ve restart yapmanız gerekebilir. Bu durumdan emin değilseniz reload-or-restart komutunu da kullanabilirsiniz. Bu durumda servis reload yapabiliyorsa yapar. Böyle bir durum yoksa o zaman otomatik olarak restart yapar.

sudo systemctl reload-or-restart application.service

• Bir servisin durumunu, çalışıp çalışmadığını status komutunu kullanarak kontrol edebilirsiniz.

systemctl status application.service

Bu komut size servisle ilgili durum bilgisi ve en son olay log bilgilerini verecektir. Herhangi bir problem varsa, yine bu çıktı sayesinde görebilirsiniz.

• Şu an çalışılan oturumda, bir servisin çalışıp çalışmadığını is-active parametresini kullanarak görebilirsiniz. Yukarıdaki status komutu kadar detaylı bilgi vermez.

systemctl is-active application.service

• Bir servisin hata verip vermediğini anlamak için is-failed parametresini de kullanmanız mümkündür.

systemctl is-failed application.service

Servisi Aktif ve Pasif Duruma Getirme

• Öncelikle, bir servisin sisteminiz açılırken başlamamaya ayarlandığını farz edelim. Bu servisi, bilgisayar her açıldığında başlayacak şekilde ayarlamak için enable komutu kullanabiliriz. Yani aktif hale getiririz. Aktif hale getirmek, her sistem açıldığında başlaması anlamına gelmektedir. Aşağıda bu duruma örnek verilmiştir.

sudo systemctl enable application.service

• Bir servisi, bilgisayar başlangıcında çalışmaması için ayarlamak istediğimizde ise disable komutunu kullanırız.

sudo systemctl disable application.service

NOT : Bu komut, enable komutu ile oluşturulan symbolic link dosyasını silecek ve servisi pasif hale getirecektir.
• Bir servisin, bilgisayar açılırken başlayıp başlamadığını öğrenmek isterseniz is-enabled parametresini kullanabilirsiniz.

systemctl is-enabled application.service

Sistem Genel Durumunu Gözden Geçirme

• Sistemimizde şu an için çalışan ve yüklenmiş servisleri görmek için aşağıdaki komutu kullanabilirsiniz.

systemctl list-units

Bu komut ile, systemd tarafından başlatılmış olan hizmetlerin özet bilgisini görebilirsiniz. Aşağıda örnek çıktı ve sütun açıklamaları bulunmaktadır.

UNIT                                      LOAD   ACTIVE SUB     DESCRIPTION
atd.service                               loaded active running ATD daemon
avahi-daemon.service                      loaded active running Avahi mDNS/DNS-SD Stack
dbus.service                              loaded active running D-Bus System Message Bus
dcron.service                             loaded active running Periodic Command Scheduler
dkms.service                              loaded active exited  Dynamic Kernel Modules System
getty@tty1.service                        loaded active running Getty on tty1
. . .

NOT : Yukarıdaki komut (systemctl list-units) sadece aktif halde olan servisleri gösterdiğinden doğal olarak LOAD sütunu daima loaded bilgisini gösterecektir. Loaded yani yüklenmiş servisler haricinde diğer servisleri görmek için demek ki ayrıca bir takım parametreler daha belirtmemiz gerekmektedir. Bunun için ayrı parametre belirtmek gerektiğinden aslında varsayılan durum list-units parametresini kullanmaya gerek bile yoktur. Sadece systemctl komutunu vermek ile systemctl list-units komutunu vermek aynı işe yarar.

• systemctl komutuna sistemimizde bulunan, ister çalışsın ister çalışmasın, systemd tarafından işlem yapılan tüm ünite elemanlarını listelemesini söylemek için –all parametresini verebiliriz.

systemctl list-units --all

Karşımıza gelecek çıktıyı filtrelemek için bir kaç parametre daha kullanabiliriz. Bunlardan bir tanesi –state filtresidir. Aşağıdaki örnekte, state yani durum bilgisi inactive (pasif) olan tüm elemanlar gösterilmektedir. –state parametresine, LOAD, ACTIVE ve SUB sütunlarının alabildiği durumları kriter olarak girebilirsiniz. Burada –all kriterinin daima var olduğuna dikkat edin. Önce hepsi ele alınıp bu liste üzerinden filtreleme yapılmaktadır.

systemctl list-units --all --state=inactive
systemctl list-units --all --state=active
systemctl list-units --all --state=running
systemctl list-units --all --state=exited

• Başka bir filtreleme yöntemi ise –type filtresidir. Tipi service olan ünite elemanları listelemek için –type=service kriteri girilebilir.

systemctl list-units --type=service

• Bir servise bağlı bağımlılıkları görmek isterseniz aşağıdaki komutu kullanabilirsiniz.

root# systemctl list-dependencies sshd
 
sshd.service
├─sshd-keygen.service
├─system.slice
└─basic.target
  ├─firewalld.service
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
  │ ├─-.slice  

• Aşağıdaki komut kullanarak bir servise ait konfigurasyon dosyasının içeriğinin bir listesini görebilirsiniz. Bir başka seçenek ise konfigurasyon dosyalarını bulup cat komutu ile bakabilirsiniz.

root# systemctl show sshd.service

Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=sshd-keygen.service system.slice
WantedBy=multi-user.target
ConsistsOf=sshd-keygen.service
Conflicts=shutdown.target
ConflictedBy=sshd.socket
Before=shutdown.target multi-user.target 

NOT 1: Sistem servislerini yönetmek için kullanılan komutlar eskiden (RHEL 7 öncesi) chkconfig ve service komutları idi. Chkconfig bir servisi enable/disable etmek için kullanılırken, service komutu ilgili servisi start/stop/restart işlemleri için kullanılırdi. Yani ilgili runlevel’da bir servisi açıp,kapamak için chkconfig komutu kullanılırken ayrıca bir de service komutu ile servisi start etmek gerekiyordu. Systemd ile gelen tek bir komutla yanı systemctl komutu ile artık bu iki işlev birleştirildi. Yani artık servislerin enable,disable edilmesi ve stop/start işlemleri systemctl komutu ile yapılabilir hale geldi.
Eski yapı ile yenisini karşılaştırırsak benim gibi eskiyi bilenler için anlaması daha kolay olacaktır.

NOT 2 : System yapısı ile artık runlevel’lar yeni bir isim aldı. Değişik servislerin birleşmesi ile oluşan runlevel’lara artık target ismi verilmektedir. Bu runlevel’ların geriye dönük isimlendirilmeler korunsa da uzun vadede bu takma adlar (aliaslar) kaldırılacaktır. Eskiden 0-6 arası runlevel’lar varken yeni yapıdaki target’lar şu şekildedir.

Öntanımlı sistemin çalıştığı target’I sorgulamak için:

# systemctl get-default
graphical.target

Reboot sırasında sistemin sıfırdan açıldığı target değiştirmek için (aslında yapılan bir link işlemi)
systemctl set-default multi-user.target

Sistem çalışırken bir anda farklı bir target’a geçmel için ( eskiden init 3 ile yapılan işlem)
systemctl isolate multi-user.target
Ayrıca bunlara ek olarak systemctl poweroff, systemctl reboot , systemctl halt komutları da kullanılmaktadır. Zaten bu 3 komutta artık systemctl komutuna bir linktir.

Referanslar
https://www.freedesktop.org/wiki/Software/systemd/
http://linux.yorenet.com/?hn=668
https://sudo.ubuntu-tr.net/systemd-kilavuzu-1
https://www.cozumpark.com/linux-sistemlerde-systemd-nedir/

Yazar : Mustafa Bektaş Tepe
Java & Oracle