systemd ile servis yönetimi

systemd neden Linux'ta hizmet yönetiminin standardıdır?

Bir Linux sunucusunu yönettiyseniz, neredeyse kesin olarak systemd ile karşılaşmışsınızdır. Bu sistem, Ubuntu, Debian, CentOS ve Rocky Linux gibi modern dağıtımların çoğunda hizmet ve süreç yöneticisi (init sistemi) olarak SysVinit'in yerini almıştır. Basit betikleri çalıştıran eski yöntemlerin aksine, systemd hizmetleri paralel olarak başlatmanıza, bağımlılıkları yönetmenize, her hizmetin durumunu ayrıntılı olarak görmenize ve journalctl ile birleşik logları incelemenize olanak tanır.

Bu makalede teoriyi açıklamak yerine doğrudan pratik komutlara geçiyoruz. Bir hizmeti nasıl başlatacağınızı, durduracağınızı, etkinleştirip devre dışı bırakacağınızı, durumunu kontrol edeceğinizi ve logları okuyarak yaygın sorunları nasıl gidereceğinizi öğreneceksiniz. Bu bilgi, web sunucuları, veritabanları veya özel uygulamalarla çalışan her sunucu yöneticisi için gereklidir.

systemctl ile Başlarken: Temel Komutlar

systemd'yi yönetmenin ana aracı systemctl komutudur. Bu komut, systemd birimleri (units) ile çalışmanıza olanak tanır; birimler hizmetler (.service), soketler (.socket), zamanlayıcılar (.timer) ve daha fazlası olabilir. Bu bölümde hizmetlere odaklanacağız.

Hizmeti Başlatma ve Durdurma

Bir hizmeti başlatmak için start alt komutunu kullanın:

sudo systemctl start nginx

Bu komut nginx hizmetini hemen çalıştırır, ancak açılışta yeniden başlatılması için etkinleştirmez. Hizmeti durdurmak için:

sudo systemctl stop nginx

Hizmet yanıt vermiyorsa ve zorla durdurmanız gerekiyorsa, SIGKILL sinyali gönderen kill komutunu kullanabilirsiniz:

sudo systemctl kill -s SIGKILL nginx

Önemli Not: stop komutu hizmeti düzgün (graceful) bir şekilde durdurur ve kaynakları serbest bırakması için zaman tanır. kill komutunu yalnızca hizmet gerçekten kilitlendiğinde kullanın.

Hizmeti Açılışta Etkinleştirme ve Devre Dışı Bırakma

Hizmetin sunucu açılışında otomatik olarak çalışması için onu enable etmeniz gerekir:

sudo systemctl enable nginx

Bu komut, /etc/systemd/system/multi-user.target.wants/ dizininde bir sembolik bağlantı oluşturur. Devre dışı bırakmak için:

sudo systemctl disable nginx

Hizmeti hem şimdi başlatmak hem de açılışta etkinleştirmek istiyorsanız, iki komutu birleştirebilirsiniz:

sudo systemctl enable --now nginx

Bu yöntem oldukça verimlidir ve otomasyon betiklerinde de yaygındır.

Hizmet Durumunu Kontrol Etme

status komutu hizmet hakkında kapsamlı bilgi sağlar:

systemctl status nginx

Bu komutun çıktısı şunları içerir:

• Güncel durum (active, inactive, failed)
• İşlem kimliği (PID) ve çalışma süresi
• Kullanılan bellek
• Hizmetin son logları
• Birim dosyasının (unit file) yolu

Hizmetin aktif olup olmadığını hızlıca kontrol etmek için is-active seçeneğini kullanın:

systemctl is-active nginx

Bu komutun çıktısı active, inactive veya failed olur. Bu komut izleme betiklerinde oldukça kullanışlıdır.

journalctl ile Log Okuma

systemd'nin eski yöntemlere göre en büyük avantajlarından biri logların birleştirilmesidir. /var/log/ içindeki ayrı dosyalarda arama yapmak yerine, tüm logları journalctl ile görüntüleyebilirsiniz.

Belirli Bir Hizmetin Loglarını Görüntüleme

nginx hizmetinin loglarını görmek için:

journalctl -u nginx

Bu komut, nginx birimine ait tüm logları kayıt başlangıcından itibaren gösterir. Yalnızca son 50 satırı görmek için:

journalctl -u nginx -n 50

Logları canlı olarak takip etmek için (tail -f gibi):

journalctl -u nginx -f

Bu seçenek, devam eden bir sorunu giderirken oldukça kullanışlıdır.

Zamana Göre Filtreleme

Belirli bir zaman aralığına ait logları görmek için --since ve --until seçeneklerini kullanın:

journalctl -u nginx --since "2025-01-15 10:00:00" --until "2025-01-15 11:00:00"

Ayrıca göreceli ifadeler de kullanabilirsiniz:

journalctl -u nginx --since "1 hour ago"

Bu yöntem, belirli bir aralıkta meydana gelen hataları bulmak için harikadır.

Önceliğe Göre Filtreleme (Priority)

Logların öncelik seviyeleri vardır (0 acil durum için, 7 hata ayıklama için). Yalnızca hataları ve kritik durumları görmek için:

journalctl -u nginx -p err

Bu komut yalnızca err (3) veya daha yüksek öncelikli mesajları gösterir. Debug'dan yukarı tüm mesajları görmek için:

journalctl -u nginx -p debug

Yaygın Sorun Giderme: Hizmet failed Olduğunda

En yaygın sorunlardan biri failed durumudur. Bir hizmet başlamadığında, ilk adım durumu kontrol etmektir:

systemctl status nginx

Çıktı genellikle Failed to start A high performance web server gibi bir hata mesajı içerir. Daha fazla ayrıntı görmek için logları inceleyin:

journalctl -u nginx -n 30 --no-pager

--no-pager seçeneği, çıktının sayfalanmadan gösterilmesini sağlar ve betikler için kullanışlıdır.

Yaygın Sorun: Port Zaten Kullanımda

Hizmetiniz istenen porta bağlanamıyorsa, Address already in use gibi bir hata görürsünüz. Portu işgal eden süreci bulmak için:

sudo ss -tulpn | grep :80

Ardından sorun çıkaran süreci durdurabilir veya hizmetin portunu değiştirebilirsiniz.

Yaygın Sorun: Permission Denied Hatası

Hizmetiniz belirli bir dosyaya veya dizine erişemiyorsa, logda Permission denied hatası görünür. Bu genellikle dosyaların yanlış sahipliğinden kaynaklanır. Sahipliği aşağıdaki komutla düzeltin:

sudo chown -R www-data:www-data /var/www/html

Hizmetin doğru kullanıcıyla (burada www-data) çalıştığından her zaman emin olun. Bu kullanıcı, hizmetin birim dosyasında tanımlıdır.

Birim Dosyalarını Yönetme (Unit Files)

systemd'deki her hizmetin, genellikle /etc/systemd/system/ veya /lib/systemd/system/ içinde bulunan bir birim dosyası vardır. Bir hizmetin birim dosyasının içeriğini görüntülemek için:

systemctl cat nginx

Birim dosyasını doğrudan açmadan düzenlemek için:

sudo systemctl edit nginx

Bu komut, ayarlarınızı ana dosyayı değiştirmeden uygulayan bir override dosyası oluşturur. Bu yöntem çok daha güvenlidir çünkü ana paketin güncellemelerini bozmaz.

Özel Bir Hizmet Oluşturma

Diyelim ki bir hizmet olarak çalıştırmanız gereken bir Python betiğiniz var. /etc/systemd/system/myapp.service içinde bir birim dosyası oluşturun:

[Unit]
Description=My Custom Python Application
After=network.target

[Service]
Type=simple
User=myuser
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Ardından systemd'yi yeniden yükleyin ve hizmeti etkinleştirin:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp

Restart=on-failure seçeneği, hizmetin bir hata durumunda 5 saniye sonra otomatik olarak yeniden başlatılmasını sağlar. Bu özellik, kritik uygulamaların kararlılığını artırmak için oldukça faydalıdır.

İleri Düzey İpuçları ve Pratik Püf Noktaları

Birden Fazla Hizmeti Aynı Anda Yönetme

Birden fazla hizmeti tek bir komutla yönetebilirsiniz:

sudo systemctl start nginx mysql php-fpm

Bu komut üç hizmeti de sırayla başlatır.

Tüm Aktif Hizmetleri Görüntüleme

Sistemdeki tüm aktif hizmetlerin listesini görmek için:

systemctl list-units --type=service --state=active

Başarısız hizmetleri görmek için:

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

Hizmeti Yeniden Başlatma

Hizmet ayarlarındaki değişiklikleri uygulamak için hizmeti yeniden başlatın:

sudo systemctl restart nginx

Yalnızca yapılandırma dosyasını tam bir kesinti olmadan yeniden yüklemek istiyorsanız, reload kullanın:

sudo systemctl reload nginx

reload komutu çok daha iyidir çünkü hizmeti kesintiye uğratmadan yeni ayarları uygular. Ancak tüm hizmetlerin bu özelliği desteklemediğini unutmayın.

Özet

systemd ile hizmet yönetimi, her sunucu yöneticisinin hakim olması gereken bir beceridir. systemctl ve journalctl komutlarına hakim olarak, hizmetleri etkili bir şekilde yönetebilir, sorunları daha hızlı giderebilir ve sunucunuzun kararlılığını artırabilirsiniz. Hizmetlerinizi çalıştırmak için güvenli ve güvenilir bir barındırma ortamı arıyorsanız, ServerNet'in systemd'yi tam destekleyen sanal ve özel sunucuları sizin için uygun bir seçenek olabilir.

Pratik yapın, birim dosyalarıyla deneyler yapın ve büyük değişikliklerden önce her zaman mevcut ayarlarınızın yedeğini alın. Profesyonel hizmet yönetimi, istikrarlı bir sunucu ile sorunlarla dolu bir sunucu arasındaki farktır.