0Pricing
DevOps Bootcamp · Ders

systemd Hizmetlerini Denetleme ve Unit Dosyaları Yazma

Hizmetleri systemctl ile yönetin ve betiklerle çalıştırılan arka plan hizmetleri için özel unit ve zamanlayıcı dosyaları yazın.

systemd Hizmetlerini Denetleme ve Unit Dosyaları Yazma, CoddyKit'te ücretsiz bir DevOps Bootcamp dersidir. Bu, 4 dersinin 2. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, DevOps Bootcamp öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. DevOps Bootcamp kursu toplamda 4 dersten oluşur.

systemd ve systemctl'e Giriş

systemd, modern Linux dağıtımlarının çoğunda kullanılan başlangıç sistemi ve hizmet yöneticisidir. Sistem hizmetlerini başlatmaktan, durdurmaktan ve yönetmekten; ayrıca önyükleme sıralarını ve sistem durumunu ele almaktan sorumludur.

systemd ile etkileşim kurmanın temel aracı systemctl'dir. Bununla şunları yapabilirsiniz:

  • Hizmetleri başlatmak ve durdurmak
  • Önyükleme sırasında hizmetleri etkinleştirmek veya devre dışı bırakmak
  • Hizmet durumunu ve günlük kayıtlarını incelemek
  • Yeniden başlatmadan yapılandırmayı yeniden yüklemek

systemd tarafından yönetilen tüm hizmetler, bildirimsel yapılandırma dosyaları olan birim dosyaları ile tanımlanır. Bu dosyalar sistem genelinde /etc/systemd/system/ altında veya kullanıcı bazında ~/.config/systemd/user/ altında saklanır.

Temel systemctl Komutları

Bunlar, günlük hizmet yönetiminde en sık kullanılan systemctl komutlarıdır. Her komut, nginx.service veya yalnızca nginx gibi bir birim adı üzerinde çalışır.

  • systemctl start <unit> — bir hizmeti hemen başlatır
  • systemctl stop <unit> — çalışan bir hizmeti durdurur
  • systemctl restart <unit> — durdurur, ardından başlatır (tam yeniden başlatma)
  • systemctl reload <unit> — durdurmadan yapılandırmayı yeniden yüklemek için SIGHUP gönderir
  • systemctl enable <unit> — birimin açılışta başlaması için sembolik bağlantılar oluşturur
  • systemctl disable <unit> — bu sembolik bağlantıları kaldırır
  • systemctl status <unit> — durumu, PID değerini ve güncel günlük satırlarını gösterir
#!/usr/bin/env bash
# Quick reference: inspect and control an nginx service
# (Requires nginx to be installed; run as root or with sudo)

systemctl status nginx
systemctl start nginx
systemctl enable nginx
systemctl reload nginx
systemctl restart nginx
systemctl stop nginx
systemctl disable nginx

Hizmet Durumunu Ayrıntılı Olarak Denetleme

systemctl status, birimin ayrıntılı bir anlık görüntüsünü sunar. Sorunları hızlıca teşhis etmek için çıktısını anlamak büyük önem taşır.

  • Loaded: birim dosyasının yolu ve açılışta etkin olup olmadığı
  • Active: geçerli durum — active (running), inactive (dead), failed
  • Main PID: hizmetin ana işleminin işlem tanımlayıcısı
  • CGroup: hizmete ait tüm alt işlemler
  • Log lines: bu birime ait en güncel günlük girdileri

Ayrıca etkin durumunu systemctl is-active, etkinleştirilmiş durumunu ise systemctl is-enabled ile sorgulayabilirsiniz. Bu komutlar betiklerde kullanım için idealdir.

#!/usr/bin/env bash
# Script-friendly service health check
SERVICE="sshd"

if systemctl is-active --quiet "$SERVICE"; then
    echo "$SERVICE is running."
else
    echo "$SERVICE is NOT running. Attempting restart..."
    systemctl restart "$SERVICE"
fi

if systemctl is-enabled --quiet "$SERVICE"; then
    echo "$SERVICE is enabled at boot."
else
    echo "WARNING: $SERVICE is not enabled at boot."
fi

Birimleri Listeleme ve Filtreleme

Çok sayıda hizmeti yönetirken birimleri verimli biçimde listeleyip filtrelemenin yollarına ihtiyaç duyarsınız. systemctl list-units o anda yüklenmiş tüm birimleri, list-unit-files ise yüklenmiş tüm birim dosyalarını ve etkinleştirilme durumlarını gösterir.

Yararlı filtreleme seçenekleri:

  • --type=service — yalnızca hizmet birimlerini gösterir
  • --state=failed — yalnızca başarısız birimleri gösterir
  • --state=active — yalnızca etkin birimleri gösterir
  • --all — etkin olmayan birimleri de listeye dahil eder

Bu filtreleri grep ile birleştirerek bakım betiklerinde güçlü inceleme işlem hatları oluşturabilirsiniz.

#!/usr/bin/env bash
# List all failed services and report them
echo "=== Failed Services ==="
systemctl list-units --type=service --state=failed --no-legend

echo ""
echo "=== Services Enabled at Boot ==="
systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'

Bir systemd Hizmet Birimi Dosyasının Yapısı

Hizmet birimi dosyası, bölümlerden oluşan düz metin biçiminde, INI tarzı bir dosyadır. Her bölüm, birimin yaşam döngüsünün farklı bir yönünü yönetir.

  • [Unit] — üst veriler: açıklama ve sıralama bağımlılıkları (After=, Requires=, Wants=)
  • [Service] — işlemin nasıl başlatılıp durdurulacağı: ExecStart, ExecStop, Restart, User, WorkingDirectory
  • [Install] — bu birimin ne zaman etkinleştirileceği: WantedBy=multi-user.target, normal çok kullanıcılı açılış sırasında etkinleştirileceği anlamına gelir

/etc/systemd/system/ altında birim dosyası oluşturduktan veya düzenledikten sonra, systemd'nin değişiklikleri algılaması için systemctl daemon-reload komutunu çalıştırmanız gerekir.

İlk Hizmet Birimi Dosyanızı Yazma

Özel bir Python HTTP sunucusu betiği için basit bir hizmet birimi dosyası oluşturalım. Birim dosyası, systemd'ye bu işlemi diğer tüm sistem hizmetleri gibi tam olarak nasıl yöneteceğini bildirir.

Burada kullanılan temel [Service] yönergeleri:

  • Type=simple — systemd, ExecStart işlemini ana işlem olarak kabul eder
  • User=www-data — güvenlik amacıyla kök olmayan bir hesapla çalıştırır
  • WorkingDirectory — işlemin çalışma dizinini belirler
  • Restart=on-failure — işlem sıfır olmayan bir kodla sonlanırsa otomatik olarak yeniden başlatır
  • RestartSec=5 — yeniden başlatma denemeleri arasında 5 saniye bekler
#!/usr/bin/env bash
# Create a custom service unit file for a simple HTTP server
# Run as root

cat > /etc/systemd/system/mywebserver.service << 'EOF'
[Unit]
Description=My Custom Python Web Server
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/mysite
ExecStart=/usr/bin/python3 -m http.server 8080
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now mywebserver.service
systemctl status mywebserver.service

Hizmet Türleri ve İşlem Yaşam Döngüsü

[Service] içindeki Type= yönergesi, systemd'ye bir hizmetin başlatılmasının ne zaman tamamlandığını nasıl izleyeceğini bildirir. Yanlış türü seçmek, sıralama hatalarının yaygın nedenlerinden biridir.

  • Type=simple — varsayılan türdür; systemd, ExecStart başlatılır başlatılmaz hizmeti başlatılmış kabul eder. Hazır olma sinyali gerekmez.
  • Type=forking — ExecStart işlemi çatallanır ve sonlanır; gerçek artalan işlemi bir alt işlem olarak çalışır. systemd'nin bunu izleyebilmesi için PIDFile= kullanın.
  • Type=notify — işlem gerçekten hazır olduğunda sd_notify(READY=1) gönderir. Karmaşık artalan işlemleri için en güvenilir seçenektir.
  • Type=oneshot — bir kez çalışır ve sonlanır; sonraki birimler tamamlanmasını bekler. Kurulum betikleri için idealdir.
  • Type=idle — simple türü gibidir, ancak yürütme tüm etkin işler tamamlanana kadar ertelenir.
#!/usr/bin/env bash
# Example: oneshot service for a database migration script
# /etc/systemd/system/db-migrate.service

cat > /etc/systemd/system/db-migrate.service << 'EOF'
[Unit]
Description=Run Database Migrations
After=postgresql.service
Requires=postgresql.service

[Service]
Type=oneshot
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/scripts/migrate.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl start db-migrate.service

Ortam Değişkenleri ve Güvenliği Güçlendirme

Hizmet birimi dosyaları, ortam değişkenlerini aktarmak ve güvenlik kısıtlamaları uygulamak için çeşitli yönergeleri destekler. Üretim sistemlerinde her ikisi de önemlidir.

Ortam yönergeleri:

  • Environment="KEY=value" — tek bir değişkeni satır içinde ayarlar
  • EnvironmentFile=/etc/myapp/env — değişkenleri bir dosyadan yükler (her satırda bir KEY=value)

Yaygın güvenlik güçlendirme yönergeleri:

  • NoNewPrivileges=true — işlemin setuid aracılığıyla ek ayrıcalıklar kazanmasını önler
  • ProtectSystem=strict — /usr, /boot ve /etc dizinlerini salt okunur olarak bağlar
  • PrivateTmp=true — hizmete yalıtılmış bir /tmp dizini verir
  • CapabilityBoundingSet= — tüm Linux yeteneklerini kaldırır
#!/usr/bin/env bash
# Hardened service unit with environment file

cat > /etc/systemd/system/secureapp.service << 'EOF'
[Unit]
Description=Secure Application Daemon
After=network.target

[Service]
Type=simple
User=secureapp
Group=secureapp
WorkingDirectory=/opt/secureapp
EnvironmentFile=/etc/secureapp/env
ExecStart=/opt/secureapp/bin/server
Restart=on-failure
RestartSec=10

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
CapabilityBoundingSet=
ReadWritePaths=/var/lib/secureapp /var/log/secureapp

[Install]
WantedBy=multi-user.target
EOF

# Create the environment file separately so secrets stay out of the unit file
install -m 600 -o secureapp /dev/null /etc/secureapp/env
echo 'APP_PORT=9000' >> /etc/secureapp/env
echo 'DB_URL=postgresql://localhost/mydb' >> /etc/secureapp/env

systemctl daemon-reload

systemd Zamanlayıcı Birimlerine Giriş

systemd zamanlayıcısı, başka bir birimi (genellikle bir .service birimini) bir zamanlamaya göre etkinleştiren bir birimdir. Geleneksel cron işlerinin yerini, daha bütünleşik, günlük kaydı tutulabilen ve denetlenebilen bir mekanizmayla alır.

Her zamanlayıcı birimi (foo.timer), gerçek işi yapan ve aynı temel ada sahip bir hizmet birimiyle (foo.service) eşleştirilir. Doğrudan hizmeti değil, zamanlayıcıyı etkinleştirip başlatırsınız.

Zamanlayıcı türleri:

  • Gerçek zamanlı (takvim) zamanlayıcılar — OnCalendar= ifadelerini kullanarak daily, weekly veya Mon *-*-* 02:00:00 gibi duvar saati zamanlarında tetiklenir
  • Monotonik zamanlayıcılar — OnBootSec=, OnActiveSec= veya OnUnitActiveSec= kullanarak bir sistem olayına göre tetiklenir

Bir Zamanlayıcı Birimi Dosyası Yazma

Her gün saat 02:00'de bir yedekleme betiği çalıştıran eksiksiz bir zamanlayıcı ve hizmet çifti oluşturalım. [Timer] bölümünün kendine ait .timer dosyasında, işin ise eşleşen .service dosyasında bulunduğuna dikkat edin.

Temel [Timer] yönergeleri:

  • OnCalendar= — zamanlama için takvim ifadesi
  • Persistent=true — zamanlayıcının tetiklenmesi gereken sırada sistem kapalıysa sonraki açılışta hemen çalıştırır
  • RandomizedDelaySec= — birçok makine aynı zamanlamayı paylaştığında aşırı eşzamanlı yükü önlemek için N saniyeye kadar rastgele gecikme ekler
  • Unit= — açıkça belirtilen hedef birim (adlar eşleşiyorsa isteğe bağlıdır)
#!/usr/bin/env bash
# Create a daily backup timer pair
# Run as root

# 1. The service that does the work
cat > /etc/systemd/system/daily-backup.service << 'EOF'
[Unit]
Description=Daily Database Backup
After=network.target postgresql.service

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup-db.sh
StandardOutput=journal
StandardError=journal
EOF

# 2. The timer that schedules it
cat > /etc/systemd/system/daily-backup.timer << 'EOF'
[Unit]
Description=Run Daily Database Backup at 02:00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now daily-backup.timer

# Verify
systemctl list-timers daily-backup.timer

Günlükleri İnceleme ve Birimlerde Sorun Giderme

systemd, tüm hizmet çıktılarını günlük defterine yönlendirir; bu günlükleri journalctl ile sorgularsınız. Bu yöntem, tüm birimlerin günlüklerini aranabilir tek bir depoda merkezileştirir.

Hizmetlerde sorun giderme için temel journalctl seçenekleri:

  • -u <unit> — birim adına göre filtreler
  • -f — günlüğü gerçek zamanlı olarak izler (tail -f gibi)
  • -n 50 — yalnızca son 50 satırı gösterir
  • --since "1 hour ago" — zaman aralığına göre sınırlar
  • -p err — yalnızca hata önceliğindeki ve daha yüksek öncelikli girdileri gösterir
  • -b — yalnızca mevcut açılıştaki günlükleri gösterir

Bir birim başlatılamadığında çalıştırılacak ilk komut journalctl -u <unit> -n 30 --no-pager olmalıdır; ardından güncel hata bağlamını yakalamak için systemctl status <unit> komutunu çalıştırın.

#!/usr/bin/env bash
# Troubleshooting helper: dump unit status and recent logs
# Usage: ./service-debug.sh <unit-name>

UNIT="${1:-nginx.service}"

echo "=============================="
echo "STATUS: $UNIT"
echo "=============================="
systemctl status "$UNIT" --no-pager -l

echo ""
echo "=============================="
echo "RECENT LOGS (last 50 lines): $UNIT"
echo "=============================="
journalctl -u "$UNIT" -n 50 --no-pager

echo ""
echo "=============================="
echo "ERRORS ONLY (current boot)"
echo "=============================="
journalctl -u "$UNIT" -b -p err --no-pager

Bilgi Kontrolü: systemd Birim Dosyaları

systemd hizmeti ve zamanlayıcı birimi yapılandırmasını ne kadar anladığınızı sınayın.

Ders Özeti: systemd Hizmetlerini Denetleme ve Birim Dosyaları Yazma

Bu derste systemd hizmet yönetiminin ve birim dosyası yazımının temel kavramlarını profesyonel düzeyde incelediniz. Ele alınan konuların özeti aşağıdadır:

  • systemctl temelleri — betik dostu denetimler için start, stop, restart, reload, enable, disable, status, is-active ve is-enabled
  • Listeleme ve filtreleme — başarısız veya etkinleştirilmiş hizmetleri ayırmak için list-units ve list-unit-files ile --type ve --state seçenekleri
  • Birim dosyasının yapısı — [Unit], [Service] ve [Install] olmak üzere üç bölüm ve bunların temel yönergeleri
  • Hizmet türleri — simple, forking, notify, oneshot ve her birinin ne zaman kullanılacağı
  • Ortam ve güvenlik — güçlendirilmiş artalan işlemleri için EnvironmentFile, NoNewPrivileges, ProtectSystem ve PrivateTmp
  • Zamanlayıcı birimleri — .timer ve .service dosyalarını eşleştirme, OnCalendar ifadeleri ve Persistent ile kaçırılan çalıştırmaları telafi etme davranışı
  • Journalctl — arızaları verimli biçimde teşhis etmek için birime, zamana, açılışa ve önceliğe göre filtreleme

Bu becerilerle tüm sistem hizmetlerini yönetebilir, yinelenen görevleri güvenilir biçimde zamanlayabilir ve kendi artalan işlemleriniz için üretim kalitesinde birim dosyaları yazabilirsiniz.

Sıkça Sorulan Sorular

“systemd Hizmetlerini Denetleme ve Unit Dosyaları Yazma” dersi ücretsiz mi?

Evet — “systemd Hizmetlerini Denetleme ve Unit Dosyaları Yazma” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve DevOps Bootcamp kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. DevOps Bootcamp kursu toplamda 4 dersten oluşur.

“systemd Hizmetlerini Denetleme ve Unit Dosyaları Yazma” dersinde ne öğreneceğim?

Hizmetleri systemctl ile yönetin ve betiklerle çalıştırılan arka plan hizmetleri için özel unit ve zamanlayıcı dosyaları yazın. DevOps Bootcamp ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

DevOps Bootcamp öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te DevOps Bootcamp, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 2. dersidir.

“systemd Hizmetlerini Denetleme ve Unit Dosyaları Yazma” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu DevOps Bootcamp dersinde kod yazıp çalıştırabilir miyim?

Evet. Her DevOps Bootcamp dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. Kullanıcı ve Grup Sağlamayı Otomatikleştirme
  2. systemd Hizmetlerini Denetleme ve Unit Dosyaları Yazma
  3. Disk, Dosya Sistemi ve Bağlama Otomasyonu
  4. Sistem Durumu Denetimi ve Uyarı Betikleri Oluşturma
← DevOps Bootcamp Sayfasına Dön