Systemd Unit Files

Systemd Unit File (Birim Dosyası), Linux sisteminin yapı taşlarını tanımlayan, .ini formatına benzeyen metin tabanlı konfigürasyon dosyalarıdır. Systemd’ye “neyi”, “nasıl”, “ne zaman” ve “hangi koşullarda” çalıştıracağını bu dosyalarla anlatırız.

bu dosyaları sadece “yazılımı çalıştıran komut dosyası” olarak değil, Systemd Dependency Graph (Bağımlılık Grafiği) üzerindeki birer düğüm (node) olarak görmelisiniz.

1. Dosya Konumları ve Hiyerarşi (Nerede Bulunurlar?)

Systemd, unit dosyalarını belirli bir öncelik sırasına göre arar. Aynı isimde iki dosya varsa, önceliği yüksek olan klasördeki kazanır. Bu yapı, sistem güncellemelerinin sizin özel ayarlarınızı ezmesini engeller.

Öncelik sırasına göre (En yüksekten en düşüğe):

Öncelik	Dizin Yolu	Açıklama
1. Yönetici (Admin)	`/etc/systemd/system/`	Sizin çalışma alanınız. Buraya yazdığınız dosyalar her şeyi ezer. Sistem genelinde (tüm kullanıcılar için) bir servis yazıyorsanız burayı kullanırsınız.
2. Çalışma Zamanı	`/run/systemd/system/`	Geçici dosyalar içindir. Reboot atınca silinir. Genelde programlar tarafından dinamik oluşturulur.
3. Dağıtım (Vendor)	`/usr/lib/systemd/system/`	Dokunmayın. Paket yöneticisiyle (dnf/apt) gelen varsayılan dosyalar buradadır. Güncelleme gelirse buradaki dosya değişir.
4. Kullanıcı	`~/.config/systemd/user/`	Kişisel alanınız. Root yetkisi gerektirmeyen, sadece o kullanıcı oturum açtığında çalışan servisler içindir.

Mühendislik İpucu: Asla /usr/lib/ altındaki bir dosyayı değiştirmeyin. Eğer varsayılan bir servisin davranışını değiştirmek istiyorsanız, o dosyayı /etc/systemd/system/ altına kopyalayın ve orada düzenleyin. Systemd otomatik olarak /etc altındakini kullanacaktır.

2. Unit Dosyası Nasıl Yazılır? (Anatomi)

Bir unit dosyası genellikle 3 ana bölümden oluşur. Köşeli parantezler [] ile bölümler ayrılır.

A. `[Unit]` Bölümü (Kimlik ve Bağımlılıklar)

Dosyanın ne olduğunu ve diğer servislerle ilişkisini tanımlar.

Description=: İnsanların okuması için kısa açıklama. (systemctl status çıktısında görünür).
After=: Sıralama belirler. After=network.target derseniz, ağ servisi ayağa kalktıktan sonra bu servisi başlatmaya çalışır. (Dikkat: Bu sıkı bir bağımlılık değildir, sadece sıralamadır).
Requires=: Sıkı bağımlılık. “Eğer X servisi çalışmıyorsa ben de çalışmam” demektir. X servisi çökerse bu servis de durdurulur.
Wants=: Gevşek bağımlılık. “X servisini de başlatmayı dene ama o hata verirse beni etkileme” demektir. En çok kullanılan budur.

B. `[Service]` Bölümü (Çalıştırma Mantığı)

Sadece .service uzantılı dosyalarda bulunur. Yazılımın nasıl çalışacağını anlatır.

Type=: Servisin türünü belirler.
- simple: (Varsayılan) Komut çalıştırılır çalıştırılmaz servis “hazır” kabul edilir. (Python scriptleri için ideal).
- forking: Eğer programınız kendini arka plana atıyorsa (daemonize oluyorsa) kullanılır (Örn: Nginx).
- oneshot: Script çalışır, işini yapar ve kapanır. Servis “çalışıyor” durumda kalmaz. (Örn: Yedekleme scriptleri, güncelleme kontrolü).
ExecStart=: Çalıştırılacak ana komut. Tam yol (absolute path) kullanılmalıdır (python yerine /usr/bin/python3).
ExecStop=: Servis durdurulurken çalışacak komut.
Restart=: Hangi durumda yeniden başlasın? (no, on-failure, always).
User= / Group=: Servis hangi kullanıcı haklarıyla çalışsın? (System servisleri için önemlidir, User servislerinde zaten sizsinizdir).
Environment=: Ortam değişkeni tanımlamak için kullanılır.

C. `[Install]` Bölümü (Kurulum ve Tetikleme)

systemctl enable komutunu çalıştırdığınızda ne olacağını belirler.

WantedBy=: Bu servis hangi “hedef” (target) tetiklendiğinde ayağa kalksın?
- multi-user.target: Grafik arayüzsüz sunucu modu (Genel standart).
- graphical.target: Grafik arayüzlü masaüstü modu.
- default.target: Sistemin varsayılan açılış modu.

3. Örnek Senaryo: Basit Bir Web Server Servisi

Diyelim ki /opt/myserver/app.py adresinde bir Flask uygulamanız var ve bunu sistem servisi yapmak istiyorsunuz.

Dosya: /etc/systemd/system/myapp.service

[Unit]
Description=Benim Ozel Web Sunucum
After=network.target
# Ağ bağlantısı olmadan çalışmasının bir anlamı yok

[Service]
Type=simple
User=anil
WorkingDirectory=/opt/myserver
ExecStart=/usr/bin/python3 app.py
Restart=always
RestartSec=10
# Çökerse 10 saniye bekle ve tekrar dene

[Install]
WantedBy=multi-user.target

[Unit]
Description=Benim Ozel Web Sunucum
After=network.target
# Ağ bağlantısı olmadan çalışmasının bir anlamı yok

[Service]
Type=simple
User=anil
WorkingDirectory=/opt/myserver
ExecStart=/usr/bin/python3 app.py
Restart=always
RestartSec=10
# Çökerse 10 saniye bekle ve tekrar dene

[Install]
WantedBy=multi-user.target

4. Sadece `.service` mi var? (Unit Türleri)

Hayır, Systemd modülerdir. Uzantısına göre farklı işler yapan unit dosyaları vardır:

.service: Uygulamaları ve süreçleri yönetir (En yaygın).
.timer: Zamanlanmış görevler (Cron yerine geçer). Bir .service dosyasını tetikler.
.socket: Bir portu veya soketi dinler. Veri geldiği anda ilgili .service‘i uyandırır. (Socket Activation). Kaynak tasarrufu için muazzamdır.
.target: Diğer unitleri gruplamak için kullanılır (Örn: graphical.target aslında ekran kartı, GNOME, ses servisi vb. servislerin bir grubudur).
.mount: Disk bağlama işlemlerini yönetir (/etc/fstab girdileri systemd tarafından otomatik olarak bu dosyalara dönüştürülür).

5. Mühendisler İçin İpuçları

Değişikliği Bildirmek: Bir unit dosyasını oluşturduktan veya değiştirdikten sonra systemd’ye “dosyaları tekrar oku” demeniz şarttır:Bashsudo systemctl daemon-reload
Doğrulama (Verify): Dosyanızda sözdizimi hatası olup olmadığını servisi çalıştırmadan test edebilirsiniz:Bashsystemd-analyze verify /etc/systemd/system/myapp.service
Override (Ezme): Mevcut bir servisin (örneğin docker.service) ayarlarını değiştirmek istiyorsunuz ama tüm dosyayı kopyalamak istemiyorsunuz. Şu komutla sadece farkları içeren bir “drop-in” dosyası oluşturabilirsiniz:Bashsudo systemctl edit docker.service Bu komut otomatik olarak /etc/systemd/system/docker.service.d/override.conf oluşturur ve içine yazdıklarınız ana ayarları ezer.