Skip to content
Bloga dön
Teknoloji systemd Linux servis yönetimi daemon init Groq

Systemd ile Servis Yönetimi: Temel Kavramlar ve İleri Düzey Pratikler

Linux sistemlerde servis yönetiminin temelini oluşturan systemd hakkında kapsamlı bir rehber. Birim dosyalarının yapısı, servis kontrol komutları, güvenlik ayarları ve timer birimleri gibi konular adım adım açıklanıyor.

Caner Serbest

Sistem ve Altyapı

5 dk okuma

Systemd ile Servis Yönetimi: Temel Kavramlar ve İleri Düzey Pratikler

Giriş

Linux dağıtımlarının çoğunda init sisteminin yerini systemd almıştır. Geleneksel SysVinit’in sınırlı paralelleştirme yeteneği ve karmaşık betik yapısı, modern sunucu ortamlarında performans ve yönetilebilirlik sorunları yaratıyordu. Systemd, birim (unit) tabanlı bir yapı sunarak servislerin, mount noktalarının, timerların ve daha pek çok bileşenin tek bir çerçevede tanımlanmasını sağlar. Bu makalede, systemd’in temel bileşenlerini, birim dosyalarının nasıl oluşturulup düzenleneceğini ve gerçek dünyada sıkça karşılaşılan senaryolar için ileri düzey konfigürasyonları ele alacağız.

Systemd Nedir? Ve Neden Kullanılır?

Systemd, PID 1 (init) süreci olarak çalışan ve sistemin önyükleme, hizmet yönetimi, günlük toplama ve kaynak kontrolü gibi görevlerini yerine getiren bir çerçevedir. En önemli avantajları şunlardır:

  1. Paralel Başlatma – Bağımlılık grafiği sayesinde birimler aynı anda başlatılır, bu da önyükleme süresini önemli ölçüde kısaltır.
  2. Birim Dosyası Tabanlı Tanım – Servisler, .service dosyalarıyla tanımlanır; aynı mantık socket, timer, target gibi diğer birim türlerine de uygulanır.
  3. Günlük Yönetimi – journalctl ile birleşik ve ikili log tutma, filtreleme ve dışa aktarım imkanı sağlar.
  4. Güvenlik Entegrasyonu – CapabilityBoundingSet, PrivateTmp, ProtectSystem gibi seçeneklerle birim seviyesinde güvenlik politikaları uygulanabilir.
  5. Düşük Overhead – C dilinde yazıldığı ve merkezi bir daemon (systemd) üzerinden yönetildiği için bellek ve CPU tüketimi düşüktür.

Birim Dosyalarının Temel Yapısı

Systemd birimleri, /etc/systemd/system/, /usr/lib/systemd/system/ ve /run/systemd/system/ dizinlerinde *.service, *.socket, *.timer gibi uzantılarla bulunur. En yaygın birim türü service birimidir. Bir service biriminin temel bölümleri şunlardır:

[Unit]
Description=Örnek Servis Açıklaması
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/example --option
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
  • [Unit] bölümü, birimin diğer birimlere olan bağımlılıklarını ve açıklamasını içerir. After= ve Before= gibi direktiflerle başlatma sırası kontrol edilir.
  • [Service] bölümü, çalıştırılacak komut (ExecStart), yeniden başlatma politikası (Restart), çalışma tipi (Type) gibi servis davranışlarını tanımlar.
  • [Install] bölümü, birimin enable edildiğinde hangi hedefe (target) bağlanacağını belirtir. multi-user.target klasik runlevel 3 karşılığıdır.

Yaygın Kullanılan Systemd Birimleri

Birim TipiAçıklama
serviceUzun süre çalışan daemonları tanımlar.
socketSocket activation (socket üzerinden tetikleme) sağlar; systemd socket açar ve bir istek geldiğinde ilgili servisi başlatır.
timerCron benzeri zamanlanmış görevleri tanımlar; OnCalendar= veya OnBootSec= gibi seçeneklerle çalıştırma zamanları ayarlanır.
targetBir grup birimi bir araya getirir; graphical.target, multi-user.target gibi sistem seviyeleri tanımlar.
pathDosya veya dizin değişikliklerini izler, değişiklik olduğunda bir servisi tetikler.
mountDosya sistemlerinin otomatik bağlanmasını tanımlar.

Bu birim tipleri birbirleriyle etkileşim içinde çalışabilir. Örneğin bir socket birimi service birimine bağlanarak socket activation sağlar.

Servis Kontrol Komutları

Systemd yönetimi systemctl komutu üzerinden gerçekleştirilir. En sık kullanılan seçenekler:

# Servisi başlat
sudo systemctl start myservice.service

# Servisi durdur
sudo systemctl stop myservice.service

# Servisi yeniden başlat
sudo systemctl restart myservice.service

# Servisin durumunu göster
sudo systemctl status myservice.service

# Servisi etkinleştir (önyüklemeye ekle)
sudo systemctl enable myservice.service

# Servisi devre dışı bırak (önyüklemeden kaldır)
sudo systemctl disable myservice.service

# Servis dosyasındaki değişiklikleri yeniden yükle
sudo systemctl daemon-reload

status çıktısı, PID, bellek kullanımı, aktiflik süresi ve journal loglarının bir kısmını gösterir. Bu bilgiler, sorun giderme sırasında kritik öneme sahiptir.

Günlük (Log) Yönetimi – journalctl

Systemd, logları ikili bir formatta journal dosyalarında saklar. journalctl komutu ile bu loglara erişilir. Temel kullanım örnekleri:

# Tüm logları göster (sayfalandırma ile)
journalctl

# Son 30 dakikadaki logları göster
journalctl --since "30 minutes ago"

# Belirli bir birimin loglarını filtrele
journalctl -u myservice.service

# Hata seviyesine göre filtrele (örnek: err)
journalctl -p err

# Logları JSON formatında dışa aktar (diğer sistemlerle entegrasyon için)
journalctl -o json-pretty > myservice.log.json

Journal, varsayılan olarak /var/log/journal/ altında kalıcı olarak saklanır; Storage=volatile ayarıyla sadece RAM’de tutulabilir.

Örnek Bir Servis: Basit HTTP Sunucu

Aşağıda Python http.server modülünü kullanarak bir HTTP sunucu sağlayan bir service birimi örneği verilmiştir.

# /etc/systemd/system/simple-http.service
[Unit]
Description=Basit HTTP Sunucu
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 -m http.server 8080 --directory /var/www/html
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Bu birimi oluşturduktan sonra:

sudo systemctl daemon-reload
sudo systemctl enable simple-http.service
sudo systemctl start simple-http.service

Tarayıcıdan http://<sunucu_ip>:8080 adresine giderek sunucunun çalıştığını doğrulayabilirsiniz.

Yeniden Başlatma Politikaları ve Güvenlik

Servislerin beklenmedik bir şekilde kapanması durumunda otomatik yeniden başlatılması, üretim ortamlarında kritik bir gereksinimdir. Restart= direktifi aşağıdaki değerleri alabilir:

  • no – Yeniden başlatma yok (varsayılan).
  • on-success – Başarılı çıkış kodu (0) alındığında yeniden başlat.
  • on-failure – Başarısız çıkış kodu (non‑zero) veya sinyal alındığında yeniden başlat.
  • always – Her durumda yeniden başlat.

Ek olarak, RestartSec= ile yeniden başlatma arasındaki bekleme süresi ayarlanabilir.

Güvenlik açısından bir birime aşağıdaki seçenekler eklenebilir:

[Service]
# Sadece belirli yetkileri verir
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
# /tmp dizinini izole eder
PrivateTmp=true
# Sistem dosyalarını sadece okuma izni verir
ProtectSystem=full
# Ağ erişimini sınırlamak için
RestrictAddressFamilies=AF_INET AF_INET6

Bu ayarlar, bir hizmetin sisteme zarar vermesini önlemek için çekirdek seviyesinde kısıtlamalar getirir.

Timer Birimleri ile Cron Alternatifi

Systemd timer birimleri, klasik cron görevlerini daha esnek ve birim tabanlı bir yaklaşımla sunar. Örnek bir timer birimi aşağıdaki gibidir:

# /etc/systemd/system/backup.timer
[Unit]
Description=Günlük yedekleme timer'ı

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
Unit=backup.service

[Install]
WantedBy=timers.target

Bu timer, her gün saat 02:00’da backup.service birimini tetikler. Persistent=true ayarı, sistem kapalıyken kaçırılan çalışmaları bir sonraki açılışta hemen çalıştırır.

Timer birimini etkinleştirmek:

sudo systemctl enable --now backup.timer
sudo systemctl status backup.timer

systemctl list-timers komutu ile tüm aktif timer’ları görebilirsiniz.

SELinux ve AppArmor Entegrasyonu

Systemd, güvenlik modülleriyle uyumlu şekilde çalışır. SELinux politikaları birim dosyasında SELinuxContext= direktifiyle belirlenebilir. Örneğin:

[Service]
SELinuxContext=system_u:object_r:httpd_t:s0

AppArmor profilleri ise AppArmorProfile= ile ilişkilendirilebilir:

[Service]
AppArmorProfile=systemd-myservice

Bu tip entegrasyonlar, özellikle yüksek güvenlik gerektiren ortamlarda servislerin izole edilmesini sağlar.

En İyi Uygulamalar ve Sık Karşılaşılan Sorunlar

  1. Birimi Doğru Yerleştirin – Özelleştirilmiş birimler /etc/systemd/system/ içinde, paket tarafından gelen birimler ise /usr/lib/systemd/system/ içinde bulunur. Değişiklik yaptıysanız daemon-reload ile sistemi bilgilendirin.
  2. Bağımlılıkları Net Tanımlayın – After= ve Requires= kombinasyonunu doğru kullanarak servis çöküşlerinin zincir etkisini önleyin.
  3. Log Rotasyonu – journal logları zamanla büyür; SystemMaxUse= ve RuntimeMaxUse= ayarlarıyla sınırlama getirin.
  4. Kaynak Kısıtlamaları – CPUQuota=, MemoryLimit= gibi sınırlamalar, bir birimin sistem kaynaklarını aşmasını engeller.
  5. Durum Kontrolleri – systemctl is-active, systemctl is-enabled komutları script içinde kullanılabilir; otomasyon süreçlerinde faydalıdır.

Sonuç

Systemd, Linux sistem yöneticileri için sadece bir init sistemi olmanın ötesinde kapsamlı bir servis yönetim platformu sunar. Birim dosyalarının yapısını anlamak, doğru bağımlılıkları tanımlamak ve güvenlik/performans seçeneklerini etkin şekilde kullanmak, sistemin kararlılığını ve güvenliğini artırır. Timer birimleri sayesinde cron görevleri daha okunabilir ve kontrol edilebilir hâle gelirken, journal entegrasyonu log toplama sürecini merkezileştirir. Bu rehberde yer alan örnekler ve en iyi uygulamalar, hem yeni başlayanlar hem de deneyimli yöneticiler için pratik bir referans olacaktır.

Kaynaklar

  • man systemd.unit
  • man systemd.service
  • man systemd.timer
  • Red Hat Documentation – Systemd and Service Management
  • Arch Wiki – Systemd

Bu yazı Groq ile otomatik oluşturulmuştur.