systemd Nedir? Linux Sunucularda Servis Yönetimi Rehberi

Son Güncelleme: Eylül 2026

systemd, modern Linux dağıtımlarında servislerin başlatılması, izlenmesi, yeniden başlatılması ve sistem açılış sırasının yönetilmesi için kullanılan temel sistem ve servis yöneticisidir. Özellikle Linux sunucu yönetimi, VPS, VDS, uygulama sunucuları ve kurumsal hosting ortamlarında systemd bilgisi; kesinti sürelerini azaltmak, servisleri güvenli çalıştırmak ve sorunları hızlı teşhis etmek için kritik öneme sahiptir.

İçindekiler

• systemd Nedir?
• systemd Neden Sunucularda Önemlidir?
• Unit Dosyaları ve Temel Kavramlar
• systemctl ile Servis Yönetimi
• Özel systemd Servis Dosyası Oluşturma
• journalctl ile Log İnceleme
• systemd Güvenlik ve İzolasyon Ayarları
• Performans, Otomasyon ve Kullanım Senaryoları
• Yaygın Sorunlar ve Çözüm Yöntemleri
• Sıkça Sorulan Sorular
• Sonuç

systemd Nedir?

systemd, Linux işletim sistemlerinde ilk çalışan kullanıcı alanı süreci olarak görev yapan bir init sistemi ve servis yöneticisidir. Sunucu açıldığında hangi servislerin hangi sırayla başlayacağını, hangi servislerin bağımlı olduğunu, servislerin başarısızlık durumunda nasıl davranacağını ve sistem kaynaklarının nasıl sınırlandırılacağını yönetir. Geleneksel init betiklerinden farklı olarak systemd; paralel başlatma, bağımlılık çözümleme, soket tabanlı aktivasyon, zamanlayıcılar ve merkezi günlükleme gibi gelişmiş özellikler sunar.

Bir Linux sunucuda web sunucusu, veritabanı, kuyruk işleyici, önbellek servisi, yedekleme aracı veya özel bir Node.js, Python, Go ya da Laravel worker süreci çalıştırıyorsanız, büyük olasılıkla bu servislerin yönetiminde systemd kullanırsınız. Bu nedenle systemd yalnızca sistem yöneticileri için değil, geliştiriciler ve DevOps ekipleri için de bilinmesi gereken temel bir bileşendir.

Örneğin bir Sanal Sunucu üzerinde Nginx, MariaDB, Redis ve uygulama worker servisleri çalıştırıldığında, bu servislerin açılışta otomatik başlaması, hata aldığında yeniden başlatılması ve loglarının düzenli izlenmesi gerekir. systemd bu ihtiyaçların tamamını merkezi ve standart bir yapı içinde karşılar.

systemd Neden Sunucularda Önemlidir?

Sunucu ortamlarında servislerin kararlı çalışması, web sitelerinin erişilebilirliği ve uygulamaların sürekliliği açısından doğrudan etkilidir. systemd, servis yönetimini rastgele komutlardan veya elle başlatılan süreçlerden çıkararak tanımlı, izlenebilir ve otomasyona uygun hale getirir.

• Otomatik başlatma: Sunucu yeniden başladığında web sunucusu, veritabanı veya özel uygulama servisleri otomatik olarak devreye alınabilir.
• Bağımlılık yönetimi: Bir servis başlamadan önce ağın hazır olması, veritabanının çalışması veya belirli bir mount noktasının erişilebilir olması sağlanabilir.
• Hata sonrası toparlanma: Servis çökerse Restart=always veya Restart=on-failure gibi ayarlarla otomatik yeniden başlatma yapılabilir.
• Merkezi loglama: journalctl ile servis logları, sistem olayları ve hata kayıtları tek noktadan incelenebilir.
• Güvenlik sınırları: Servisin hangi kullanıcıyla çalışacağı, hangi dizinlere yazabileceği ve sistem kaynaklarını ne kadar kullanabileceği kısıtlanabilir.

Bu özellikler özellikle üretim ortamlarında önemlidir. Trafik alan bir e-ticaret sitesi, API servisi veya kurumsal panelde servislerin elle başlatılması kabul edilebilir bir yöntem değildir. Bunun yerine systemd ile servis tanımı yapılmalı, otomatik başlatma etkinleştirilmeli ve log yönetimi düzenli takip edilmelidir.

Unit Dosyaları ve Temel Kavramlar

systemd, yönetilen her bileşeni unit adı verilen yapılandırma dosyalarıyla tanımlar. Unit dosyaları genellikle /etc/systemd/system/, /lib/systemd/system/ veya /usr/lib/systemd/system/ dizinlerinde bulunur. Yönetici tarafından oluşturulan özel servisler için çoğunlukla /etc/systemd/system/ dizini tercih edilir.

Yaygın Unit Türleri

Temel Bölümler

Bir .service dosyası genellikle [Unit], [Service] ve [Install] bölümlerinden oluşur. [Unit] bölümü açıklama ve bağımlılıkları, [Service] bölümü çalıştırma komutunu ve davranışı, [Install] bölümü ise servisin hangi hedef altında etkinleşeceğini belirtir.

systemctl ile Servis Yönetimi

systemctl, systemd servislerini yönetmek için kullanılan ana komuttur. Bu komutla servis başlatabilir, durdurabilir, yeniden başlatabilir, açılışta otomatik başlatmayı etkinleştirebilir veya servis durumunu kontrol edebilirsiniz.

Temel Servis Komutları

systemctl status nginx
systemctl start nginx
systemctl stop nginx
systemctl restart nginx
systemctl reload nginx

restart komutu servisi tamamen kapatıp yeniden açarken, reload genellikle yapılandırmayı kesinti oluşturmadan yeniden yüklemeye çalışır. Her servis reload desteği sunmayabilir; bu nedenle üretim ortamlarında komutun etkisi önceden test edilmelidir.

Açılışta Otomatik Başlatma

systemctl enable nginx
systemctl disable nginx
systemctl is-enabled nginx

enable komutu servisi hemen başlatmaz; yalnızca sistem açılışında otomatik çalışacak şekilde ayarlar. Servisi hem başlatmak hem de açılışta etkinleştirmek için şu komut kullanılabilir:

systemctl enable --now nginx

Servisleri Listeleme

systemctl list-units --type=service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service

Bu komutlar özellikle yoğun servis çalıştıran Kiralık Sunucu ortamlarında hızlı envanter çıkarmak için yararlıdır. Hangi servislerin aktif, devre dışı veya başarısız durumda olduğunu görmek, bakım operasyonlarının ilk adımlarından biridir.

Özel systemd Servis Dosyası Oluşturma

Kendi uygulamanızı veya arka plan görevinizi systemd ile yönetmek için özel bir servis dosyası oluşturabilirsiniz. Örneğin bir Node.js API, Python bot, Laravel queue worker veya Go tabanlı mikroservis için systemd servis dosyası yazmak yaygın bir yöntemdir.

Örnek Servis Dosyası

Aşağıdaki örnekte /var/www/app dizininde çalışan basit bir uygulama servisi tanımlanmıştır:

[Unit]
Description=Corelux Ornek Uygulama Servisi
After=network.target

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/app
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Bu içeriği /etc/systemd/system/ornek-uygulama.service dosyasına kaydettikten sonra systemd yapılandırmasını yeniden yüklemek gerekir:

systemctl daemon-reload
systemctl enable --now ornek-uygulama
systemctl status ornek-uygulama

Laravel Queue Worker Örneği

Laravel projelerinde kuyruk işleyicilerin sürekli çalışması gerekir. Bunu ekranda açık bir terminalle yapmak yerine systemd kullanmak daha doğru ve güvenlidir.

[Unit]
Description=Laravel Queue Worker
After=network.target mysql.service redis.service

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/laravel
ExecStart=/usr/bin/php artisan queue:work --sleep=3 --tries=3 --timeout=90
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Bu yapılandırma sayesinde worker süreci beklenmedik şekilde kapanırsa yeniden başlatılır. Ayrıca sunucu yeniden başladığında Laravel kuyruk işleme süreci otomatik olarak devreye girer.

journalctl ile Log İnceleme

journalctl, systemd günlüklerini görüntülemek için kullanılan güçlü bir araçtır. Geleneksel log dosyaları hâlâ birçok uygulamada kullanılsa da systemd ile çalışan servislerin standart çıktı ve hata kayıtları çoğunlukla journal içinde tutulur.

Servis Loglarını Görüntüleme

journalctl -u nginx
journalctl -u nginx -n 100
journalctl -u nginx -f

-u parametresi belirli bir servise ait kayıtları filtreler. -n 100 son 100 satırı gösterir, -f ise logları canlı olarak takip eder. Bu özellik, servis başlatma hatalarını, izin problemlerini veya yapılandırma sorunlarını hızlıca tespit etmek için çok değerlidir.

Zamana Göre Filtreleme

journalctl --since "2026-09-08 10:00:00"
journalctl --since "1 hour ago"
journalctl -u ornek-uygulama --since today

Zamana göre filtreleme, özellikle kesinti yaşanan bir saat aralığında hangi olayların gerçekleştiğini anlamak için kullanılır. Bir uygulama belirli bir deploy sonrası hata vermeye başladıysa, deploy saatinden itibaren logları incelemek sorunun kaynağını belirlemeyi kolaylaştırır.

systemd Güvenlik ve İzolasyon Ayarları

systemd yalnızca servis başlatmak için değil, aynı zamanda servisleri sınırlandırmak ve güvenli hale getirmek için de kullanılabilir. Özellikle internete açık çalışan uygulamalarda, servisin gereksiz sistem kaynaklarına erişimini kısıtlamak saldırı yüzeyini azaltır.

Güvenli Servis Çalıştırma İlkeleri

• Root kullanıcısından kaçının: Servisleri mümkün olduğunca root yerine özel ve yetkisi sınırlı kullanıcılarla çalıştırın.
• Çalışma dizinini belirleyin: WorkingDirectory ile uygulamanın doğru dizinden çalışmasını sağlayın.
• Yazılabilir alanları kısıtlayın: Servisin yalnızca ihtiyaç duyduğu dizinlere yazmasına izin verin.
• Ortam değişkenlerini kontrol edin: Hassas bilgileri gelişigüzel dosyalarda tutmayın, izinleri sınırlandırılmış yöntemler kullanın.
• Kaynak limitleri uygulayın: Hatalı çalışan bir servis tüm CPU veya belleği tüketmemelidir.

Örnek Güvenlik Parametreleri

[Service]
User=appuser
Group=appuser
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
ReadWritePaths=/var/www/app/storage
MemoryMax=512M
CPUQuota=80%

NoNewPrivileges=true, servisin yeni ayrıcalıklar kazanmasını engeller. PrivateTmp=true, servise özel geçici dizin alanı sağlar. ProtectSystem=full, sistem dizinlerine yazmayı sınırlandırır. MemoryMax ve CPUQuota ise kaynak tüketimini kontrol altında tutar. Bu ayarlar her uygulama için doğrudan kopyalanmamalı; uygulamanın ihtiyaçlarına göre test edilerek uygulanmalıdır.

Güvenlik açısından kritik uygulamalar için SSL Sertifikası, güvenli yedekleme politikaları, firewall kuralları ve güncel yazılım sürümleriyle birlikte systemd izolasyon ayarları da bütünsel güvenlik yaklaşımının parçası olmalıdır.

Performans, Otomasyon ve Kullanım Senaryoları

systemd, yalnızca servisleri açık tutmakla kalmaz; otomasyon ve operasyonel verimlilik için de güçlü olanaklar sunar. Doğru yapılandırılmış servisler, bakım süreçlerini kolaylaştırır ve insan hatasını azaltır.

Pratik Kullanım Senaryoları

1. Web uygulaması çalıştırma: Node.js, Python, Go veya PHP tabanlı uzun çalışan süreçleri systemd ile servis haline getirebilirsiniz.
2. Queue worker yönetimi: Laravel, Symfony Messenger veya benzeri kuyruk işleyiciler için otomatik yeniden başlatma tanımlanabilir.
3. Yedekleme görevi tetikleme: systemd timer ile belirli saatlerde yedekleme scriptleri çalıştırılabilir.
4. Servis bağımlılığı kurma: Uygulamanın veritabanı veya Redis hazır olmadan başlaması engellenebilir.
5. Kaynak tüketimini sınırlama: Tek bir servisin tüm belleği tüketerek sunucuyu kilitlemesinin önüne geçilebilir.

systemd Timer ile Basit Yedekleme Örneği

Cron yerine systemd timer kullanarak daha izlenebilir zamanlanmış görevler oluşturabilirsiniz. Önce servis dosyası hazırlanır:

[Unit]
Description=Gunluk Yedekleme Gorevi

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Ardından timer dosyası oluşturulur:

[Unit]
Description=Gunluk Yedekleme Zamanlayicisi

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Timer etkinleştirme komutları:

systemctl daemon-reload
systemctl enable --now gunluk-yedekleme.timer
systemctl list-timers

Yedekleme operasyonları için systemd timer kullanılabilir; ancak kritik verilerde merkezi, izlenebilir ve düzenli test edilen bir strateji gerekir. Bu noktada Yedekleme Hizmeti gibi çözümler, uygulama verilerinin daha güvenli korunmasına yardımcı olur.

Yaygın Sorunlar ve Çözüm Yöntemleri

systemd servislerinde yaşanan hatalar genellikle yanlış dosya yolu, eksik izin, hatalı kullanıcı, ortam değişkeni eksikliği veya bağımlılık problemlerinden kaynaklanır. Sorun giderirken rastgele komutlar çalıştırmak yerine sistematik ilerlemek gerekir.

Servis Başlamıyorsa

systemctl status ornek-uygulama
journalctl -u ornek-uygulama -n 100

Öncelikle servis durumuna ve son log kayıtlarına bakılmalıdır. ExecStart içinde belirtilen komutun tam yolu doğru olmalı, uygulama dizini mevcut olmalı ve servis kullanıcısının gerekli dosyalara erişim izni bulunmalıdır.

Unit Dosyası Değiştiği Halde Etki Etmiyorsa

systemd unit dosyalarında değişiklik yaptıktan sonra daemon-reload çalıştırılmazsa yeni yapılandırma algılanmayabilir.

systemctl daemon-reload
systemctl restart ornek-uygulama

Servis Sürekli Yeniden Başlıyorsa

Restart=always veya Restart=on-failure ayarları hatalı çalışan uygulamayı sürekli yeniden başlatabilir. Bu durumda loglar incelenmeli, uygulamanın bağımlılıkları kontrol edilmeli ve gerekirse RestartSec değeri artırılmalıdır.

Kaynak Tüketimi Yüksekse

systemctl status ornek-uygulama
systemd-cgtop

systemd-cgtop, servislerin kontrol grupları üzerinden kaynak tüketimini izlemeye yardımcı olur. Bellek sızıntısı veya CPU yoğunluğu olan servislerde MemoryMax, CPUQuota ve uygulama içi optimizasyon birlikte değerlendirilmelidir.

Yoğun trafik alan projelerde doğru servis yapılandırmasının yanında uygun sunucu kaynağı da önemlidir. Trafiği artan uygulamalar için Türkiye VDS Sunucu veya yüksek kaynak ihtiyacı olan projeler için dedicated çözümler tercih edilebilir.

Sıkça Sorulan Sorular

Sonuç

systemd, modern Linux sunucularda servis yönetiminin temelidir. Web sunucularından veritabanlarına, Laravel queue worker süreçlerinden özel uygulama servislerine kadar pek çok bileşen systemd ile daha güvenli, izlenebilir ve otomasyona uygun şekilde çalıştırılabilir. Doğru yazılmış unit dosyaları, düzenli log takibi, otomatik yeniden başlatma kuralları ve güvenlik kısıtlamaları; sunucu kararlılığını doğrudan artırır.

Üretim ortamında çalışan projeler için yalnızca uygulama kodu değil, uygulamanın nasıl servisleştirildiği de önemlidir. Servislerin açılışta doğru sırayla başlaması, hatalarda hızlı toparlanması, kaynak kullanımının sınırlandırılması ve loglarının takip edilebilir olması profesyonel sunucu yönetiminin ayrılmaz parçalarıdır.

Corelux üzerinde barındırılan projeleriniz için ihtiyaçlarınıza göre Linux Hosting, Sanal Sunucu, Kiralık Sunucu ve Bulut Sunucu seçeneklerini değerlendirebilirsiniz. Doğru altyapı ile iyi yapılandırılmış systemd servisleri bir araya geldiğinde, uygulamalarınız daha kesintisiz, güvenli ve yönetilebilir hale gelir.