service Komutu ile Linux Servis Yönetimi

yazar

service Komutu ile Linux Servis Yonetimi

Linux sistem yoneticilerinin en cok kullandigi komutlardan biri olan service, gunluk operasyonlarda vazgecilmez bir araca donusuyor. Ister bir web sunucusunu yeniden baslatmak, ister bir servisin durumunu kontrol etmek olsun, bu komut isimizi bir hayli kolaylastiriyor. Bu yazida service komutunu tum yonleriyle ele alacagiz ve gercek dunya senaryolariyla pekistirip sisteminizi daha etkin yonetmenize yardimci olacagiz.

service Komutu Nedir?

service komutu, Linux sistemlerde servisleri (daemon’lari) yonetmek icin kullanilan bir sarmalayici (wrapper) betiktir. Temelde /etc/init.d/ dizinindeki init scriptlerini calistirir. Ancak modern sistemlerde systemd’ye gecisle birlikte bu komut, arka planda systemctl‘e yonlendirme yapacak sekilde guncellenmistir.

Peki neden hala service komutu kullaniyoruz? Cunku:

  • Eski aliskanliklarin guclu olmasi: Yillarca service apache2 restart yazarak gelismis birine systemctl restart apache2 yazdirmak zor.
  • Tasinabilirlik: Hem SysVinit hem de systemd sistemlerde calisan scriptler yazarken service daha evrensel kalir.
  • Okunaklilik: Komut yapisi son derece sade ve anlasilirdir.

Temel Sozdizimi

service <servis_adi> <komut>

Temel komutlar sunlardir:

  • start – Servisi baslatir
  • stop – Servisi durdurur
  • restart – Servisi yeniden baslatir
  • reload – Yapilandirma dosyalarini yeniden yukler (servisi kesmeden)
  • status – Servisin mevcut durumunu gosterir
  • condrestart – Yalnizca servis zaten calisiyorsa yeniden baslatir
  • force-reload – Yapilandirmayi zorla yeniden yukler

Pratik Kullanim Ornekleri

1. Servis Durumunu Kontrol Etmek

En sik yapilan islem servisin calisip calismadigini kontrol etmektir. Ozellikle bir sorun bildirildiginde ilk yapilmasi gereken budur.

# Apache web sunucusunun durumunu kontrol et
service apache2 status

# MySQL veritabani sunucusunun durumunu kontrol et
service mysql status

# SSH daemon durumunu kontrol et
service ssh status

# Tum servislerin durumunu listele (SysVinit sistemlerde)
service --status-all

service --status-all komutu sizi gercekten sasirtabilir. Sistemde ne kadar cok servisin arka planda kostu veya durdu oldugunu gordugunuzde, “bunlarin hepsine ihtiyacim var mi?” diye sorgulamaya baslayabilirsiniz. Bu sorgu, gereksiz servisleri kapatarak sistem kaynaklarini geri kazanmak icin guzel bir baslangic noktasidir.

2. Servis Baslatma ve Durdurma

# Nginx servisini baslat
sudo service nginx start

# Nginx servisini durdur
sudo service nginx stop

# Nginx servisini yeniden baslat (kesinti yaratir)
sudo service nginx restart

# Nginx yapilandirmasini test edip yeniden yukle (kesintisiz)
sudo service nginx reload

Burada restart ile reload arasindaki fark cok onemlidir. Production ortaminda calisirken bir web sunucusunu restart etmek, o anda baglanan kullanicilar icin kisa bir kesinti yaratabilir. Oysa reload, mevcut baglantilari kesmeden yeni yapilandirmayi devreye alir. Mumkun oldugunda reload tercih edin.

3. Koşullu Yeniden Baslama

# MySQL zaten calisiyorsa yeniden baslat, degilse dokunma
sudo service mysql condrestart

# Postfix posta sunucusu icin ayni islem
sudo service postfix condrestart

Bu ozellik ozellikle cron joblarinda ve otomatik bakiyici scriptlerde cok isine yarar. “Servis calisiyorsa yeniden baslat, yoksa hata verme” mantigini tek satirda sagliyorsunuz.

Gercek Dunya Senaryolari

Senaryo 1: Gece Yarim Acil Cagri – Web Sunucu Cevap Vermiyor

Sabah 2:30’da telefonunuz caliyor. Bir musteri “site cevap vermiyor” diyor. Hemen baglaniyor ve ilk kontrollerinizi yapiyorsunuz:

# Once Apache'nin durumunu kontrol et
sudo service apache2 status

# Cevap alamadinizsa loglara bak
sudo tail -n 50 /var/log/apache2/error.log

# Servisi yeniden baslatmayı dene
sudo service apache2 restart

# Yeniden baslatma basarisiz olduysa force-reload dene
sudo service apache2 force-reload

# Hala cevap vermiyorsa PHP-FPM gibi bagimliliklari kontrol et
sudo service php8.1-fpm status
sudo service php8.1-fpm restart

Cogunlukla bu adimlar yeterli olur. Ama yeniden baslatma basarisiz oluyorsa bu genellikle yapilandirma dosyasinda bir syntax hatasi olduguna isaret eder. apache2ctl configtest veya nginx -t ile yapilandirmayi once test edin.

Senaryo 2: Uygulama Guncelleme Sonrasi Servis Yonetimi

Bir uygulama guncelleme scripti yaziyorsunuz ve guncelleme sirasinda servisleri kontrol altinda tutmaniz gerekiyor:

#!/bin/bash

APP_NAME="myapp"
SERVICE_NAME="gunicorn"

echo "Guncelleme basliyor..."

# Servisin calistigini dogrula
if service $SERVICE_NAME status > /dev/null 2>&1; then
    echo "$SERVICE_NAME servisi aktif, durdurulyor..."
    sudo service $SERVICE_NAME stop
else
    echo "$SERVICE_NAME zaten durmus durumda."
fi

# Uygulama guncellemesini yap
cd /var/www/$APP_NAME
git pull origin main
pip install -r requirements.txt

# Veritabani migrasyonlarini calistir
python manage.py migrate

# Statik dosyalari topla
python manage.py collectstatic --noinput

# Servisi yeniden baslat
echo "Servis yeniden baslatiliyor..."
sudo service $SERVICE_NAME start

# Servisin basarili baslayip baslamadigini kontrol et
sleep 3
if service $SERVICE_NAME status > /dev/null 2>&1; then
    echo "Guncelleme basarili! $SERVICE_NAME servisi calisiyor."
else
    echo "HATA: $SERVICE_NAME servisi baslamiyor! Loglar kontrol edilmeli."
    exit 1
fi

Bu tarz scriptler production ortaminda gunluk operasyonlarin vazgecilmez parcasidir.

Senaryo 3: Coklu Servis Saglik Kontrolu

Bir monitoring scripti hazirlayalim. Kritik servislerin durumunu kontrol edip sorunlari tespit edelim:

#!/bin/bash

# Kontrol edilecek servisler
SERVICES=("nginx" "mysql" "redis-server" "memcached" "postfix")
FAILED_SERVICES=()

echo "=== Servis Saglik Kontrolu ==="
echo "Tarih: $(date)"
echo "----------------------------"

for SERVICE in "${SERVICES[@]}"; do
    if service "$SERVICE" status > /dev/null 2>&1; then
        echo "[OK]   $SERVICE calisiyor"
    else
        echo "[HATA] $SERVICE DURDU!"
        FAILED_SERVICES+=("$SERVICE")
    fi
done

echo "----------------------------"

if [ ${#FAILED_SERVICES[@]} -gt 0 ]; then
    echo "UYARI: Asagidaki servisler calismıyor:"
    for FAILED in "${FAILED_SERVICES[@]}"; do
        echo "  - $FAILED"
        # Otomatik yeniden baslatma dene
        echo "  Yeniden baslatma deneniyor: $FAILED"
        sudo service "$FAILED" start
        sleep 2
        if service "$FAILED" status > /dev/null 2>&1; then
            echo "  $FAILED basarıyla yeniden baslatildi!"
        else
            echo "  $FAILED yeniden baslatılamadi! Manuel mudahale gerekiyor."
            # Buraya email veya Slack bildirimi eklenebilir
        fi
    done
else
    echo "Tum servisler normal calisıyor."
fi

Bu scripti cron’a koyarsaniz her 5 dakikada bir otomatik kontrol yapabilirsiniz:

# crontab -e ile ekle
*/5 * * * * /opt/scripts/servis_kontrol.sh >> /var/log/servis_kontrol.log 2>&1

service ile systemctl Arasindaki Fark

Modern sistemlerde (Ubuntu 16.04+, CentOS 7+, Debian 8+) service komutu arkadan systemctl‘e yonlendirme yapar. Ama bazi onemli farklar var:

| Islem | service komutu | systemctl komutu | |—|—|—| | Baslatma | service nginx start | systemctl start nginx | | Durdurma | service nginx stop | systemctl stop nginx | | Durum | service nginx status | systemctl status nginx | | Otostartı etkinlestir | (desteklemez direkt) | systemctl enable nginx | | Tum servisler | service --status-all | systemctl list-units |

Kritik not: service komutu servisin sistem acilisinda otomatik baslamasini saglamaz. Bunun icin systemctl enable veya eski sistemlerde update-rc.d / chkconfig kullanmaniz gerekir.

# Servisi hem hemen baslat hem de otostarta al
sudo systemctl enable --now nginx

# Sadece service komutu kullaniyorsaniz ve otostart gerekiyorsa
sudo service nginx start
sudo systemctl enable nginx   # otostart icin systemctl kullanmak gerekiyor

Servis Log Takibi

Bir sorunu cozmeye calisirken servis loglarini takip etmek sart. service komutu dogrudan log gostermez, ancak asagidaki kombinasyonla etkili bir hata ayiklama yapabilirsiniz:

# Systemd loglarinda servisi filtrele (gercek zamanli)
journalctl -u nginx -f

# Son 100 satir
journalctl -u mysql -n 100

# Belirli bir zaman araliginda
journalctl -u apache2 --since "2024-01-15 10:00:00" --until "2024-01-15 12:00:00"

# Sadece hatalari goster
journalctl -u postgresql -p err

# Servis yeniden baslatildiktan sonra logları izle
sudo service redis-server restart && journalctl -u redis-server -f

Sikca Yapilan Hatalar ve Cozumleri

“Failed to start” Hatasi

# Yapilandirma hatasini kontrol et
sudo service nginx configtest
# veya
sudo nginx -t

# Sistemd detayli bilgi icin
sudo systemctl status nginx -l

Port Zaten Kullanimda Hatasi

# Hangi proses portu kullaniyor bul
sudo ss -tlnp | grep :80
# veya
sudo lsof -i :80

# Eger eski proses kalmissel oldurebilirsin
sudo kill -9 <PID>
sudo service nginx start

Servis Basliyor ama Hemen Duruyor

Bu durum genellikle yapilandirma dosyasinda bir hata oldugunun isarettir. Ayrintili log kontrolu yapmaniz gerekir:

# Servisi elle baslat ve ciktisini izle
sudo service myapp start
sudo journalctl -u myapp -n 20 --no-pager

Ipuclari ve En Iyi Uygulamalar

  • Production’da her zaman reload tercih edin: restart yerine reload kullanmak aktif baglantilari korur.
  • Degisiklik oncesi durum kaydet: service --status-all > /tmp/servis_durumu_$(date +%F).txt ile anlık durumu kaydedin.
  • Scriptlerinizde cikis kodlarini kontrol edin: service komutu basarisiz olursa sifir olmayan cikis kodu dondurur. Scriptlerinizde set -e kullanin.
  • Log rotation unutmayin: Servis loglarinin sonsuz buyumemesi icin logrotate yapilandirin.
  • Test ortaminda deneyin: Kritik bir servisi production’da ilk kez yeniden baslatmadan once test ortaminda deneyin.

Sonuc

service komutu, Linux sistem yoneticilerinin arac kutusundaki en temel ve guvenilir araclardan biri olmaya devam ediyor. Sistemd’nin yaygınlasmasiyla birlikte systemctl daha fazon hale gelse de service komutunun sadeligi ve evrensel kullanimi onu hala guncel ve degerli kilıyor.

Gunluk operasyonlarda, acil mudahalelerde veya otomasyona yonelik scriptler yazarken service komutunu etkin kullanmak size ciddi zaman kazandirır. Burada paylastığimiz senaryo ve ornekleri kendi ortaminiza uyarlayarak hem guvenilirlik hem de operasyonel olgunluk kazanabilirsiniz.

En onemli nokta su: Bir servisi yeniden baslatmak sorunu gecici olarak cozebilir, ama kök nedeni bulmak icin loglara bakmak zorundasiniz. service komutunuzu ogrenin, ama loglarinizi da okumayı ihmal etmeyin.

Yorum yapın