service Komutu ile Linux Servis Yönetimi

`service` Komutu ile Linux Servis Yönetimi

Linux sistem yöneticiliğine yeni başlayanların kafasını en çok karıştıran konulardan biri servis yönetimi. Kim ne zaman service kullanmalı, kim ne zaman systemctl kullanmalı, bunların farkı ne? Bu yazıda service komutunu baştan sona ele alacağız, gerçek hayat senaryolarıyla pekiştireceğiz.

`service` Komutu Nedir?

service komutu, Linux sistemlerinde servisleri (daemon’ları) başlatmak, durdurmak, yeniden başlatmak ve durumlarını kontrol etmek için kullanılan bir araçtır. Aslında service komutu bir wrapper’dır. Yani arka planda sisteminizin init sistemine göre ya SysVinit script’lerini (/etc/init.d/), ya Upstart komutlarını, ya da systemd’yi çağırır.

Kısaca şöyle düşün: service komutu, hangi init sistemini kullandığınızdan bağımsız olarak tutarlı bir arayüz sunar. Ubuntu 20.04’te de, CentOS 7’de de, eski Debian 8’de de service nginx restart yazarsın ve iş görür.

Hangi Sistemlerde Çalışır?

Debian/Ubuntu tabanlı dağıtımlar
Red Hat/CentOS/Fedora tabanlı dağıtımlar
openSUSE ve türevleri
SysVinit kullanan eski sistemler
systemd kullanan modern sistemler

Temel Kullanım

Komutun genel sözdizimi şu şekilde:

service <servis_adi> <komut>

En sık kullanılan komutlar şunlar:

start – Servisi başlat
stop – Servisi durdur
restart – Servisi yeniden başlat
reload – Konfigürasyonu yeniden yükle (servisi durdurmadan)
status – Servisin durumunu göster
enable – Sistem açılışında otomatik başlat (bazı sistemlerde)
disable – Otomatik başlatmayı kapat

Temel Örnekler

# Apache web sunucusunu başlat
sudo service apache2 start

# Nginx'i durdur
sudo service nginx stop

# MySQL'i yeniden başlat
sudo service mysql restart

# SSH servisinin durumunu kontrol et
sudo service ssh status

# Konfigürasyon değişikliği sonrası reload (bağlantıları kesmeden)
sudo service nginx reload

`restart` mi `reload` mi? Fark Önemli!

Bu ayrımı iyi kavramak lazım. Canlı ortamda yanlış komut kullanmak can yakar.

restart: Servisi tamamen durdurur ve yeniden başlatır. Aktif bağlantılar kesilir. Yeni bir konfigürasyon dosyası eklediyseniz, servis binary’si güncellendiyse restart gerekir.

reload: Servisi durdurmadan sadece konfigürasyon dosyalarını yeniden okur. Aktif bağlantılar korunur. Nginx veya Apache’de SSL sertifikası yeniledikten sonra, yeni bir virtual host ekledikten sonra reload yeterlidir.

# Yeni bir nginx virtual host eklediniz
# Bağlantıları kesmek istemiyorsunuz
sudo nginx -t  # Once konfigürasyonu test et!
sudo service nginx reload  # Sonra reload yap

# Eğer nginx binary güncellendiyle
sudo service nginx restart  # Tam restart gerekli

Altın kural: Production ortamında önce -t veya benzeri test komutuyla konfigürasyonu doğrula, sonra reload/restart yap.

Tüm Servisleri Listeleme

# Sistemdeki tüm servisleri listele
sudo service --status-all

# Çıktı şu şekilde görünür:
# [ + ]  apache2        (çalışıyor)
# [ - ]  bluetooth      (durdurulmuş)
# [ ? ]  console-setup  (durum bilinmiyor)

Çıktıdaki semboller:

[ + ] – Servis çalışıyor
[ - ] – Servis durmuş
[ ? ] – Durum belirlenemiyor

Bu komutu bir sunucuya ilk bağlandığınızda çalıştırmak iyi bir alışkanlık. Hangi servislerin ayakta olduğunu hızlıca görürsünüz.

Gerçek Dünya Senaryoları

Senaryo 1: Web Sunucusu Yanıt Vermiyor

Gece 2’de telefon geliyor. Web sitesi erişilemez durumda. Sunucuya bağlanıyorsunuz:

# Önce nginx'in durumuna bak
sudo service nginx status

# Eğer durmuşsa başlat
sudo service nginx start

# Hata loglarına bak
sudo tail -f /var/log/nginx/error.log

# Konfigürasyonda sorun varsa test et
sudo nginx -t

# Sorunu giderdikten sonra restart
sudo service nginx restart

# Servisin gerçekten ayağa kalktığını doğrula
sudo service nginx status

Senaryo 2: MySQL Bağlantı Sorunları

Uygulama veritabanına bağlanamıyor:

# MySQL durumuna bak
sudo service mysql status

# Servis çalışıyor ama bağlantı olmuyorsa
# Önce log kontrol et
sudo tail -50 /var/log/mysql/error.log

# Konfigürasyon değişikliği yaptıysanız
sudo service mysql restart

# Restart sonrası status kontrol
sudo service mysql status

# Port dinleniyor mu kontrol et
sudo netstat -tlnp | grep 3306
# veya
sudo ss -tlnp | grep 3306

Senaryo 3: SSH Konfigürasyon Güncellemesi

SSH portunu veya konfigürasyonunu değiştirdiniz. Dikkatli olmak lazım, yoksa kendi kendinizi sunucudan atarsınız:

# SSH konfigürasyonunu düzenlediniz
# /etc/ssh/sshd_config

# Önce syntax kontrolü
sudo sshd -t

# Eğer hata yoksa reload (mevcut bağlantıyı kesmez!)
sudo service ssh reload

# YENİ bir terminal açıp bağlantıyı test et
# Mevcut terminali KAPATMA henüz!
# Yeni bağlantı başarılıysa mevcut terminali kapatabilirsin

Bu senaryo çok kritik. SSH reload sırasında mevcut bağlantınız korunur ama eğer konfigürasyonda hata varsa yeni bağlantılar kurulamaz. Bu yüzden her zaman mevcut terminal açıkken yeni terminal ile test edin.

`service` ile `systemctl` Arasındaki Fark

Modern sistemlerde (Ubuntu 16.04+, CentOS 7+) servis yönetimi systemd’ye geçti. systemctl daha güçlü ve detaylı bilgi sunar. Ama service komutu hala çalışır ve systemd sistemlerde systemctl‘e yönlendirir.

# Bu iki komut modern sistemlerde aynı işi yapar
sudo service nginx restart
sudo systemctl restart nginx

# Ama systemctl daha fazla bilgi sunar
sudo systemctl status nginx
# Çıktıda: aktif süre, son loglar, PID, memory kullanımı

# service ile sadece temel durum görürsünüz
sudo service nginx status

Ne zaman service kullan:

Birden fazla dağıtımda çalışan script yazıyorsanız
Eski alışkanlık ve hız için
SysVinit ve systemd arasında geçiş dönemindeyseniz

Ne zaman systemctl kullan:

Systemd tabanlı modern sistemlerde
Servis bağımlılıklarını yönetmek istiyorsanız
Detaylı log ve durum bilgisi gerekiyorsa
enable/disable ile boot-time yönetimi yapıyorsanız
Timer, socket activation gibi gelişmiş özellikler kullanacaksanız

Servis Scripti Nerede Duruyor?

service komutu arka planda /etc/init.d/ dizinindeki script’leri veya systemd unit dosyalarını kullanır:

# SysVinit script'lerini listele
ls /etc/init.d/

# Bir script'in içeriğine bak
cat /etc/init.d/nginx

# Servisin hangi init sistemini kullandığını anla
# systemd sistemde:
sudo service nginx status
# "Redirecting to /bin/systemctl restart nginx.service" gibi bir mesaj görürsünüz

Kendi Servisinizi Yazmak

Basit bir Python uygulamasını servis olarak çalıştırmak istiyorsunuz. SysVinit için basit bir script:

#!/bin/bash
# /etc/init.d/myapp
# Basit bir SysVinit servis scripti

### BEGIN INIT INFO
# Provides:          myapp
# Required-Start:    $network $local_fs
# Required-Stop:     $network $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: My Python Application
### END INIT INFO

APP_PATH="/opt/myapp/app.py"
PID_FILE="/var/run/myapp.pid"
LOG_FILE="/var/log/myapp.log"

case "$1" in
    start)
        echo "Starting myapp..."
        python3 $APP_PATH >> $LOG_FILE 2>&1 &
        echo $! > $PID_FILE
        echo "myapp started with PID $(cat $PID_FILE)"
        ;;
    stop)
        echo "Stopping myapp..."
        if [ -f $PID_FILE ]; then
            kill $(cat $PID_FILE)
            rm $PID_FILE
            echo "myapp stopped."
        else
            echo "myapp is not running."
        fi
        ;;
    restart)
        $0 stop
        sleep 1
        $0 start
        ;;
    status)
        if [ -f $PID_FILE ] && kill -0 $(cat $PID_FILE) 2>/dev/null; then
            echo "myapp is running (PID: $(cat $PID_FILE))"
        else
            echo "myapp is not running."
        fi
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 1
        ;;
esac

exit 0

Script’i aktif hale getirmek için:

# Script'i kopyala ve izin ver
sudo cp myapp /etc/init.d/myapp
sudo chmod +x /etc/init.d/myapp

# Sistem başlangıcında otomatik çalışsın
sudo update-rc.d myapp defaults  # Debian/Ubuntu
# veya
sudo chkconfig myapp on  # CentOS/RHEL

# Artık service komutuyla yönetebilirsiniz
sudo service myapp start
sudo service myapp status
sudo service myapp stop

Faydalı Ipuçlari ve Pratik Notlar

Sudo gereksinimi: Servis başlatma/durdurma işlemleri root yetkisi gerektirir. Script yazıyorsanız bunu unutmayın.

# Sudo olmadan calistirirsan hata alirsin
service nginx restart
# Failed to restart nginx.service: Access denied

# Dogru kullanim
sudo service nginx restart

Hata ayiklama ipucu: Servis baslamiyorsa önce log dosyasina bak, sonra manuel calistir:

# Servisi servis olarak degil, direkt calistir ve hatayi gör
sudo nginx -t
sudo php-fpm7.4 --test

# Sistem loglarindan hata bul
sudo journalctl -xe | grep nginx
sudo tail -100 /var/log/syslog | grep nginx

Cron ile servis izleme: Kritik servislerin calismaya devam edip etmedigini kontrol eden basit bir cron:

# /etc/cron.d/check-services
*/5 * * * * root /usr/local/bin/check-service.sh nginx
*/5 * * * * root /usr/local/bin/check-service.sh mysql

#!/bin/bash
# /usr/local/bin/check-service.sh
SERVICE=$1

if ! service $SERVICE status > /dev/null 2>&1; then
    echo "UYARI: $SERVICE servisi calismıyor! Yeniden başlatılıyor..." | 
        mail -s "Servis Alarmı: $SERVICE" [email protected]
    service $SERVICE start
    logger "check-service: $SERVICE yeniden başlatıldı"
fi

Sonuç

service komutu, Linux servis yönetiminde yılların getirdigi sade ve güvenilir bir araç. Modern systemd dünyasında systemctl daha güçlü özellikler sunsa da service komutu hala geçerliliğini koruyor. Özellikle karma ortamlarda, eski sistemlerde ve hızlı müdahale gerektiren durumlarda service komutunun sade sözdizimi büyük avantaj.

Önemli noktalari özetleyelim:

service --status-all ile sistemdeki tüm servislerin durumuna hızlıca bakın
Production’da önce test et, sonra reload/restart yap prensibini asla ihmal etme
SSH gibi kritik servislerde değişiklik yaparken mevcut bağlantıyı koru
restart ile reload arasındaki farkı iyi kavra, production’da yanlış seçim bağlantı kesintisine neden olur
Modern sistemlerde service komutları arka planda systemctl‘e yönlendiriliyor, bunu bil

Sysadmin işinde “servis çöktü, ne yapacağım?” sorusunun cevabı çoğu zaman basit: status bak, log bak, restart at, tekrar bak. service komutu bu döngünün tam ortasında, her zaman yanınızda.