Sunucu yönetiminde en sık kullanacağın araçlardan biri olan systemctl, Ubuntu’da servisleri başlatmaktan, durdurmaktan, otomatik başlatma ayarlarına kadar her şeyi kontrol etmeni sağlar. Eğer hala service komutunu kullanıyorsan ya da servislerle ilgili sorunlarda ne yapacağını bilemiyorsan, bu yazı tam sana göre. Gelin systemctl’i gerçek dünya senaryolarıyla birlikte derinlemesine inceleyelim.
systemctl Nedir ve Neden Önemlidir?
Ubuntu 15.04 sürümünden itibaren varsayılan init sistemi olarak systemd kullanılmaktadır. Daha önce Upstart veya SysVinit ile çalışanlar için bu bir geçiş süreciydi, ancak artık modern Ubuntu sunucularında systemd her yerde karşımıza çıkıyor.
systemctl, systemd’nin kontrol arayüzüdür. Servis başlatma, durdurma, yeniden başlatma gibi temel işlemlerin yanı sıra sistem durumunu inceleme, logları okuma ve servis birimlerini (unit) yönetme gibi gelişmiş özellikleri de sunar.
Eski service komutu hala çalışıyor gibi görünse de arka planda zaten systemctl’e yönlendirme yapıyor. Dolayısıyla systemctl’i doğrudan kullanmayı öğrenmek hem daha temiz hem de daha güçlü bir yönetim deneyimi sunar.
Temel Servis Komutları
Servis Başlatma, Durdurma ve Yeniden Başlatma
En sık kullanacağın komutlardan başlayalım:
# Servisi başlat
sudo systemctl start nginx
# Servisi durdur
sudo systemctl stop nginx
# Servisi yeniden başlat (kısa kesinti olur)
sudo systemctl restart nginx
# Servisi yeniden yükle (kesinti olmadan, config yeniden okunur)
sudo systemctl reload nginx
# Önce reload dene, olmadıysa restart yap
sudo systemctl reload-or-restart nginx
Burada reload ile restart arasındaki fark kritik. Örneğin Nginx konfigürasyonunu değiştirdiğinde reload kullanırsan aktif bağlantılar kesilmez. Nginx yeni config’i okuyup uygulamaya devam eder. Ancak restart kullanırsan servis tamamen durur ve yeniden başlar, bu da kısa süreli bir kesintiye yol açar. Üretim ortamında mümkün olduğunca reload tercih et.
Servis Durumunu Kontrol Etme
# Servisin mevcut durumunu göster
sudo systemctl status nginx
# Sadece aktif/pasif bilgisi al (scripting için ideal)
systemctl is-active nginx
# Servis enabled mi değil mi?
systemctl is-enabled nginx
# Servis başarısız mı?
systemctl is-failed nginx
systemctl status komutu sana çok değerli bilgiler verir. Çıktıda şunları görürsün:
- Loaded: Servis birimi yüklü mü ve dosya yolu nerede
- Active: Şu an çalışıyor mu, ne zamandır çalışıyor
- Main PID: Ana sürecin process ID’si
- CGroup: Hangi control group altında çalışıyor
- Son log satırları
Bir örnek çıktı şuna benzer:
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2024-01-15 09:23:41 UTC; 2h 14min ago
Docs: man:nginx(8)
Process: 1234 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 1235 (nginx)
Tasks: 3 (limit: 4915)
Memory: 6.8M
CPU: 234ms
CGroup: /system.slice/nginx.service
Otomatik Başlatma Ayarları
Sunucunuzu yeniden başlattığınızda servislerin otomatik olarak ayağa kalkmasını istiyorsanız enable ve disable komutlarını kullanmanız gerekiyor.
# Sunucu açılışında otomatik başlat
sudo systemctl enable nginx
# Otomatik başlatmayı devre dışı bırak
sudo systemctl disable nginx
# Hem enable et hem de hemen başlat
sudo systemctl enable --now nginx
# Hem disable et hem de hemen durdur
sudo systemctl disable --now nginx
enable komutu aslında arka planda bir sembolik link oluşturur. /etc/systemd/system/multi-user.target.wants/ dizinine servis birimi dosyasına işaret eden bir symlink ekler. disable ise bu symlink’i siler.
mask ve unmask
Bazen bir servisi sadece durdurmak yetmez, tamamen erişilemez hale getirmek isteyebilirsin. Örneğin güvenlik açısından çalışmamasını istediğin bir servis var:
# Servisi maskele (start edilemez hale getir)
sudo systemctl mask bluetooth
# Maskelemeyi kaldır
sudo systemctl unmask bluetooth
mask komutu, servis birim dosyasını /dev/null‘a symlink ederek hem manual hem de otomatik başlatmayı tamamen engeller. Bu çok daha güçlü bir engelleme yöntemidir.
Sistem Durumunu İnceleme
Tüm Servisleri Listeleme
# Tüm yüklü birimleri listele
systemctl list-units
# Sadece servis türündeki birimleri listele
systemctl list-units --type=service
# Başarısız servisleri listele
systemctl list-units --state=failed
# Tüm birimleri (aktif olmayan dahil) listele
systemctl list-units --all
# Enable edilmiş servisleri listele
systemctl list-unit-files --type=service --state=enabled
Bir sunucuyu devraldığında ya da sorun giderme yaparken systemctl list-units --state=failed komutu altın değerinde. Hangi servislerin çöktüğünü anında görürsün.
Bağımlılıkları İnceleme
# Bir servisin bağımlılıklarını göster
systemctl list-dependencies nginx
# Bir servise bağlı olanları göster (ters bağımlılık)
systemctl list-dependencies --reverse nginx
Gerçek Dünya Senaryoları
Senaryo 1: Nginx Konfigürasyon Değişikliği Sonrası
Diyelim ki bir sanal host ekledin ve nginx.conf dosyasını düzenledin. Production sunucusunda doğru yaklaşım şu:
# Önce konfigürasyonu test et
sudo nginx -t
# Hata yoksa reload et (kesintisiz)
sudo systemctl reload nginx
# Durumu kontrol et
sudo systemctl status nginx
Asla konfigürasyonu test etmeden reload veya restart yapma. nginx -t komutu sana syntax hatası varsa bildirerek servisi boş yere kesintiye uğratmanı önler.
Senaryo 2: MySQL Servis Çöktüğünde
Gece 3’te bir alarm geldi, MySQL çalışmıyor. İlk adımlar:
# Durumu kontrol et
sudo systemctl status mysql
# Logları incele (son 50 satır)
sudo journalctl -u mysql -n 50
# Belirli zaman aralığındaki loglar
sudo journalctl -u mysql --since "2024-01-15 02:00:00" --until "2024-01-15 03:30:00"
# Servisi yeniden başlatmayı dene
sudo systemctl restart mysql
# Başarılı olduysa enable durumunu kontrol et
systemctl is-enabled mysql
journalctl systemd’nin log yönetim sistemidir ve systemctl ile çok iyi entegre çalışır. -u parametresi belirli bir unit’e ait logları filtrelemenizi sağlar.
Senaryo 3: Özel Bir Uygulama için Servis Oluşturma
Diyelim ki Python ile yazdığın bir web uygulaması var ve bunu servis olarak çalıştırmak istiyorsun:
# Servis birim dosyası oluştur
sudo nano /etc/systemd/system/myapp.service
Dosya içeriği:
[Unit]
Description=My Python Web Application
After=network.target postgresql.service
Requires=postgresql.service
[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/myapp
Environment="PATH=/var/www/myapp/venv/bin"
Environment="FLASK_ENV=production"
ExecStart=/var/www/myapp/venv/bin/python app.py
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Servisi aktive et:
# systemd'ye yeni birimi tanıt
sudo systemctl daemon-reload
# Servisi başlat ve enable et
sudo systemctl enable --now myapp
# Durumu kontrol et
sudo systemctl status myapp
Bu servis dosyasındaki önemli direktiflere dikkat et:
- After: Hangi servislerden sonra başlaması gerektiğini belirtir
- Requires: Bağımlı olduğu servisleri tanımlar (o servis dursa bu da durur)
- Restart=always: Uygulama çökerse otomatik yeniden başlar
- RestartSec=5: Yeniden başlamadan önce 5 saniye bekler
- StandardOutput/StandardError=journal: Loglar journald’ye gider
Senaryo 4: Servis Başlamıyorsa Hata Ayıklama
# Detaylı durum bilgisi
sudo systemctl status myapp.service -l
# Son logları gerçek zamanlı takip et
sudo journalctl -u myapp -f
# Tüm boot loglarına bak
sudo journalctl -u myapp -b
# Belirli bir priority seviyesindeki loglar (error ve üstü)
sudo journalctl -u myapp -p err
journalctl parametreleri:
- -f: Follow modu, yeni logları gerçek zamanlı gösterir
- -b: Bu boot’a ait loglar
- -b -1: Bir önceki boot’a ait loglar
- -n 100: Son 100 satır
- -p err: Sadece error seviyesi ve üstü loglar
- –since “1 hour ago”: Son 1 saatteki loglar
systemctl ile Sistem Yönetimi
systemctl sadece servis yönetimi için değil, sistem geneli işlemler için de kullanılır.
# Sistemi yeniden başlat
sudo systemctl reboot
# Sistemi kapat
sudo systemctl poweroff
# Sistemi askıya al (suspend)
sudo systemctl suspend
# Hibernate
sudo systemctl hibernate
# Mevcut runlevel'i (target) göster
systemctl get-default
# Default target'ı değiştir
sudo systemctl set-default multi-user.target
# Grafik arayüze geç (geçici)
sudo systemctl isolate graphical.target
Target kavramı, eski SysVinit’teki runlevel’lerin systemd karşılığıdır:
- poweroff.target: Kapatma (runlevel 0)
- rescue.target: Tek kullanıcı modu (runlevel 1)
- multi-user.target: Çok kullanıcılı, ağ var, grafik yok (runlevel 3)
- graphical.target: Grafik arayüz (runlevel 5)
- reboot.target: Yeniden başlatma (runlevel 6)
Servis Birim Dosyalarını İnceleme
# Servis birim dosyasının içeriğini görüntüle
systemctl cat nginx
# Servis birim dosyasını düzenle (override)
sudo systemctl edit nginx
# Tüm override dahil birleşik görünüm
sudo systemctl edit --full nginx
systemctl edit komutu çok kullanışlı. Paket yöneticisi tarafından kurulan servislerin birim dosyalarını doğrudan değiştirmek yerine, /etc/systemd/system/nginx.service.d/ altında bir override dosyası oluşturur. Böylece paket güncellendiğinde özelleştirmelerini kaybetmezsin.
Örneğin Nginx’in timeout süresini artırmak istiyorsan:
sudo systemctl edit nginx
Açılan editöre şunu yaz:
[Service]
TimeoutStopSec=60
Kaydedince systemd otomatik olarak daemon-reload yapar ve ayar devreye girer.
Pratik İpuçları ve Sık Yapılan Hatalar
daemon-reload’u unutma: Bir birim dosyası oluşturduktan veya değiştirdikten sonra mutlaka sudo systemctl daemon-reload çalıştır. Yoksa systemd eski konfigürasyonu kullanmaya devam eder.
enable ile start’ı karıştırma: enable servisi hemen başlatmaz, sadece boot’ta başlaması için ayarlar. start ise hemen başlatır ama sunucu yeniden açıldığında çalışmaz. İkisini birlikte kullanmak için enable --now kullanabilirsin.
sudo gereksinimleri: Bazı systemctl komutları sudo gerektirmez (status, is-active gibi okuma işlemleri), ancak start/stop/restart gibi değişiklik yapan komutlar sudo ister.
# Bu sudo gerektirmez
systemctl status nginx
systemctl is-active nginx
systemctl list-units
# Bunlar sudo gerektirir
sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl daemon-reload
Servis dosyası syntax kontrolü:
# Birim dosyasında hata var mı kontrol et
systemd-analyze verify /etc/systemd/system/myapp.service
# Boot süresini analiz et
systemd-analyze
# Hangi servis ne kadar sürüyor
systemd-analyze blame
# Kritik yol analizi
systemd-analyze critical-chain
systemd-analyze blame özellikle yavaş boot süreleri için harika bir teşhis aracı. Hangi servisin başlatılmasının ne kadar sürdüğünü sıralı olarak gösterir.
Güvenlik Odaklı Servis Yapılandırması
Kendi servis dosyalarını yazarken güvenlik direktiflerini de eklemeyi alışkanlık haline getir:
[Service]
# Root ile çalışmayı önle
User=appuser
Group=appgroup
# Dosya sistemi erişimini kısıtla
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/myapp
# Yeni ayrıcalık kazanımını engelle
NoNewPrivileges=true
# Geçici dosya sistemi kullan
PrivateTmp=true
# Ağ erişimini kısıtla (sadece localhost)
IPAddressAllow=localhost
IPAddressDeny=any
Bu direktifler sayesinde uygulamanın güvenlik açığından yararlanılsa bile saldırganın sistem üzerindeki etkisi minimize edilmiş olur.
Sonuç
systemctl, modern Ubuntu sunucu yönetiminin vazgeçilmez bir parçası. Temel start/stop/restart komutlarından servis birim dosyası yazmaya, hata ayıklamadan güvenlik sertleştirmesine kadar geniş bir yelpazede kullanabilirsin.
Özellikle şu alışkanlıkları edinmeni öneririm: Üretim ortamında her zaman reload önce dene, servis dosyalarını değiştirdikten sonra daemon-reload yapmayı unutma, sorun çıktığında journalctl ile log incele ve kendi servislerini yazarken güvenlik direktiflerini ihmal etme.
systemd başta karmaşık gelebilir ama zamanla neden bu kadar güçlü bir araç olduğunu anlayacaksın. Bağımlılık yönetimi, log entegrasyonu, otomatik yeniden başlatma ve güvenlik sandboxing gibi özellikleriyle eski init sistemlerine göre çok daha yetenekli bir yapı sunuyor. Bu yazıdaki komutları ve senaryoları kendi test ortamında denemen, systemctl’i gerçek anlamda kavramanın en hızlı yolu olacak.