systemd Kullanarak Linux Hizmetini Önyükleme Sırasında Başlatma

Sunucunuz yeniden başlatıldığında kritik hizmetlerin otomatik olarak başlamasını sağlamak, herhangi bir Linux sistem yöneticisinin en temel sorumluluklarından biridir. Bir web uygulaması, bir veritabanı motoru veya VPS Hosting ortamında özel bir daemon çalıştırıyor olsanız da, beklenmeyen bir yeniden başlatma asla uzun süreli kapalı kalma anlamına gelmemelidir. Günümüzün çoğu Linux dağıtımını güçlendiren modern init sistemi olan systemd ile, hizmetlerinizin nasıl, ne zaman ve kimin olarak başlayacağını temiz, bildirimsel bir birim dosyası aracılığıyla tam olarak tanımlayabilirsiniz.

Bu kapsamlı rehber sizi her adımda yönlendirir: systemd’nin ne olduğunu anlamak, üretime hazır bir hizmet birim dosyası oluşturmak, izinleri doğrulamak, yürütülebilir dosyanızı test etmek ve hizmet yaşam döngüsünü yönetmek. Sonunda, özel uygulamanız her yeniden başlatmada otomatik olarak çalışmaya devam edecektir.

systemd Nedir ve Neden Önemlidir?

systemd, Ubuntu, Debian, CentOS, Rocky Linux, AlmaLinux ve Fedora dahil olmak üzere çoğu büyük Linux dağıtımında SysVinit ve Upstart gibi eski alternatiflerin yerini alan bir init sistemi ve hizmet yöneticisidir. Önyükleme sırasında sıralı bir shell komut dosyası zinciri yürütmek yerine, systemd hizmet başlatmayı paralelleştirir, bağımlılık sıralamasını çözer ve sistem işlemlerinin tüm yaşam döngüsünü tek bir birleşik arayüzden yönetir.

Sunucu ortamları için systemd’nin temel avantajları

Dedicated Servers veya VPS örneklerinde uygulamaları yönetenler için, bu yetenekler doğrudan daha yüksek çalışma süresi ve yük altında daha öngörülebilir davranışa dönüşür.

systemd Unit Dosyalarını Anlamak

systemd’nin yönettiği her şey bir unit dosyası ile temsil edilir — bölümlere ayrılmış düz metin yapılandırma dosyası. Bir .service unit dosyası systemd’ye şunları söyler:

• Ne olduğu (meta veriler, açıklama, bağımlılıklar)
• Nasıl çalıştırılacağı (çalıştırılabilir yol, çalışma dizini, kullanıcı bağlamı)
• Ne zaman başlatılacağı (boot hedefi, diğer unitlara göre sıralama)
• Ne yapılacağı başarısız olursa (yeniden başlatma politikası, yeniden başlatma gecikmesi)

Sistem genelinde hizmetler için Service unit dosyaları /etc/systemd/system/ içinde bulunur. Buraya yerleştirilen dosyalar /lib/systemd/system/ içindeki satıcı tarafından sağlanan unitlara göre öncelik alır ve paket yükseltmeleri arasında kalıcı olur.

Adım Adım: systemd Hizmet Birimi Oluşturma

Aşağıdaki kılavuz myapp adlı kurgusal bir uygulamayı kullanır. myapp, myuser ve /usr/bin/myapp örneklerinin her birini kendi ortamınız için uygun değerlerle değiştirin.

Adım 1: Çalışma Dizinini Hazırlayın

Birim dosyasını yazmadan önce, uygulamanızın hangi dizinden çalışacağına karar verin. Adanmış bir çalışma dizini, yapılandırma dosyalarını, günlükleri ve çalışma zamanı verilerini organize eder ve izin yönetimini basitleştirir.

Dizin zaten mevcut değilse oluşturun:

sudo mkdir -p /opt/myapp

> Neden /opt/ yerine /etc/systemd/?

> /etc/systemd/ ağacı systemd’nin kendi yapılandırması için ayrılmıştır. Uygulama verilerini oraya yerleştirmek standart dışıdır ve karışıklığa neden olabilir. Dosya Sistemi Hiyerarşi Standardı kategorisine en uygun olan /opt/myapp, /srv/myapp veya /var/lib/myapp kullanın.

Sahipliği hizmeti çalıştıracak kullanıcıya atayın:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myuser
sudo chown -R myuser:myuser /opt/myapp

Adanmış bir sistem hesabı (giriş kabuğu yok, ev dizini yok) kullanmak bir güvenlik en iyi uygulamasıdır. Uygulama hiç bir zaman tehlikeye girerse, hasar alanını sınırlar.

Sonucu doğrulayın:

ls -ld /opt/myapp
# Expected output: drwxr-xr-x 2 myuser myuser 4096 Jan 1 00:00 /opt/myapp

Adım 2: Hizmet Birim Dosyasını Oluşturun

Tercih ettiğiniz düzenleyici ile yeni bir birim dosyası açın:

sudo nano /etc/systemd/system/myapp.service

Aşağıdaki içeriği yapıştırın ve değerleri uygulamanızla eşleşecek şekilde ayarlayın:

[Unit]
Description=My Custom Application
Documentation=https://example.com/docs
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/myapp --config /opt/myapp/myapp.conf
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s
User=myuser
Group=myuser
WorkingDirectory=/opt/myapp
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Dosyayı Ctrl+O ile kaydedin, ardından Ctrl+X ile çıkın.

Adım 3: Her Yönergeyi Anlayın

[Unit] Bölümü

> network-online.target vs network.target: Hizmetler gerçekten tam olarak yapılandırılmış bir ağ arayüzüne ihtiyaç duyduğunda network-online.target (Wants=network-online.target ile birlikte) kullanın — örneğin, başlangıçta uzak bir veritabanına veya harici bir API’ye bağlanan bir uygulama. network.target yalnızca ağ alt sisteminin *başlatıldığını* garanti eder, arayüzlerin açık olduğunu ve adreslerin atandığını değil.

[Service] Bölümü

[Install] Bölümü

Adım 4: Dosya ve Dizin İzinlerini Doğrulayın

systemd’yi yeniden yüklemeden önce, hizmet kullanıcısının gerçekten ihtiyaç duyduğu her şeye erişebildiğini doğrulayın:

# Check working directory ownership and permissions
ls -ld /opt/myapp

# Confirm the executable exists and is executable
ls -l /usr/bin/myapp

# Verify the config file is readable by myuser
sudo -u myuser cat /opt/myapp/myapp.conf

Bu kontrollerin herhangi biri başarısız olursa, devam etmeden önce izinleri düzeltin:

# Make the binary executable
sudo chmod +x /usr/bin/myapp

# Grant read access to the config file
sudo chmod 640 /opt/myapp/myapp.conf
sudo chown myuser:myuser /opt/myapp/myapp.conf

Adım 5: Yürütülebilir Dosyayı El ile Test Edin

systemd’ye kontrol vermeden *önce* uygulamanızın doğru şekilde çalıştığını her zaman doğrulayın. Bu, uygulama hatalarını systemd yapılandırma sorunlarından ayırır:

sudo -u myuser /usr/bin/myapp --config /opt/myapp/myapp.conf

Uygulama hatasız başlarsa, durdurmak için Ctrl+C tuşuna basın ve devam edin. Başarısız olursa, uygulamanın kendisini sorun giderin — tüm bağımlılıkların yüklü olduğunu, ortam değişkenlerinin ayarlandığını ve gerekli bağlantı noktalarının kullanılabilir olduğunu kontrol edin.

Adım 6: systemd’yi Yeniden Yükleyin ve Hizmeti Etkinleştirin

Birim dosyasını kaydettikten sonra, systemd’ye yapılandırmasını yeniden okumasını söyleyin:

sudo systemctl daemon-reload

Hizmeti her sonraki önyüklemede otomatik olarak başlayacak şekilde etkinleştirin:

sudo systemctl enable myapp.service

Bu komut, uygun .wants dizininde bir sembolik bağlantı oluşturur ve birim dosyanızı multi-user.target önyükleme sırasına bağlar. Şuna benzer bir çıktı görmelisiniz:

Created symlink /etc/systemd/system/multi-user.target.wants/myapp.service → /etc/systemd/system/myapp.service.

Yeniden başlatmadan hizmeti hemen başlatın:

sudo systemctl start myapp.service

Adım 7: Hizmetin Çalıştığını Doğrulayın

Hizmetin geçerli durumunu kontrol edin:

sudo systemctl status myapp.service

Sağlıklı bir hizmet şuna benzer bir çıktı üretir:

● myapp.service - My Custom Application
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2025-01-01 12:00:00 UTC; 5s ago
   Main PID: 12345 (myapp)
      Tasks: 4 (limit: 4915)
     Memory: 12.3M
        CPU: 45ms
     CGroup: /system.slice/myapp.service
             └─12345 /usr/bin/myapp --config /opt/myapp/myapp.conf

Doğrulanacak anahtar alanlar:

• Loaded — birim dosyasının başarıyla ayrıştırıldığını doğrular ve önyükleme için enabled veya disabled olup olmadığını gösterir
• Active: active (running) — hizmet şu anda çalışıyor
• Main PID — uygulamanızın işlem kimliği

Adım 8: journalctl ile Günlükleri İzleyin

systemd tüm hizmet çıktısını yapılandırılabilir, sorgulanabilir bir günlük deposu olan günlüğe yönlendirir. Bunu incelemek için journalctl kullanın:

# View all logs for myapp (most recent last)
journalctl -u myapp.service

# Follow live log output (like tail -f)
journalctl -u myapp.service -f

# Show only logs since the last boot
journalctl -u myapp.service -b

# Show the last 50 lines
journalctl -u myapp.service -n 50

# Show logs since a specific time
journalctl -u myapp.service --since "2025-01-01 12:00:00"

Hizmetiniz başlayamazsa, günlük neredeyse her zaman başarısız olma nedenini açıklayan tam hata mesajını içerir. Herhangi bir değişiklik yapmadan önce buradasına bakılacak ilk yerdir.

Adım 9: Önyükleme Davranışını Test Edin

Hizmetin önyükleme sırasını el ile incelemeden bir yeniden başlatmadan sonra hayatta kaldığını doğrulamak için bunu simüle edebilirsiniz:

# Reboot the server (only if safe to do so)
sudo reboot

Sunucu tekrar çevrimiçi olduktan sonra, hizmet durumunu tekrar kontrol edin:

sudo systemctl status myapp.service

active (running) gösteriyorsa, hizmetiniz otomatik başlatma için doğru şekilde yapılandırılmıştır.

Hizmet Yaşam Döngüsünü Yönetme

Hizmetiniz çalışmaya başladığında, aşağıdaki komutları düzenli olarak kullanacaksınız:

Yaygın systemctl Komutları

# Start the service
sudo systemctl start myapp.service

# Stop the service gracefully
sudo systemctl stop myapp.service

# Restart the service (stop + start)
sudo systemctl restart myapp.service

# Reload configuration without restarting (if ExecReload is defined)
sudo systemctl reload myapp.service

# Enable automatic startup at boot
sudo systemctl enable myapp.service

# Disable automatic startup at boot
sudo systemctl disable myapp.service

# Check whether the service is enabled
sudo systemctl is-enabled myapp.service

# Check whether the service is currently active
sudo systemctl is-active myapp.service

# View the full unit file as systemd interprets it
sudo systemctl cat myapp.service

# Edit the unit file and reload in one step
sudo systemctl edit --full myapp.service

Yaygın Sorunları Giderme

Hizmet başlatılamıyor: "No such file or directory"

Bu genellikle ExecStart var olmayan bir ikili dosyaya işaret ettiği veya WorkingDirectory mevcut olmadığı anlamına gelir. Her iki yolu da doğrulayın:

which myapp
ls -l /opt/myapp

Hizmet başlar ancak hemen çıkar

Uygulamanın kendi hata çıktısı için günlüğü kontrol edin:

journalctl -u myapp.service -n 100 --no-pager

Ayrıca Type=simple uygulamanız için doğru olduğunu doğrulayın. İkili dosyanız kendisini arka plana çatallandırırsa, bunun yerine Type=forking kullanın.

"Permission denied" hataları

Hizmet kullanıcısı gerekli bir dosya veya dizine erişemez. İzinleri denetlemek için ls -l ve erişimi etkileşimli olarak test etmek için sudo -u myuser kullanın.

Port zaten kullanımda

Başka bir işlem uygulamanızın ihtiyaç duyduğu porta bağlı. Bunu şu şekilde tanımlayın:

sudo ss -tlnp | grep :<port>

Hizmet döngüde yeniden başlatılıyor

Eğer Restart=on-failure hızlı yeniden başlatma döngülerine neden olursa, systemd sonunda yeniden başlatmaları kısıtlayacaktır. [Unit] bölümünde StartLimitIntervalSec ve StartLimitBurst kontrol edin ve bu davranışı ayarlamak için, ve her zaman günlükte kök nedeni araştırın.

Üretim Sunucuları için Gelişmiş systemd Desenleri

Ortam Değişkenleri ve Ortam Dosyaları

Gizli anahtarları asla birim dosyalarında sabit kodlamayın. Bunun yerine bir ortam dosyası kullanın:

[Service]
EnvironmentFile=/etc/myapp/myapp.env
ExecStart=/usr/bin/myapp

/etc/myapp/myapp.env oluşturun ve erişimi kısıtlamak için chmod 600 ve chown root:myuser ile yapılandırın:

DATABASE_URL=postgresql://user:password@localhost/mydb
API_KEY=supersecretkey

Hizmet Bağımlılıkları ve Sıralama

Uygulamanız bir veritabanı hizmetine (örneğin PostgreSQL veya MySQL) bağlıysa, bu bağımlılığı açıkça bildirin:

[Unit]
After=network-online.target postgresql.service
Requires=postgresql.service

Requires katı bir bağımlılıktır — PostgreSQL başlatılamaz duruma gelirse, systemd uygulamanızı başlatmaya çalışmayacaktır.

Watchdog Entegrasyonu

Görev açısından kritik hizmetler için, asılı kalan işlemleri tespit etmek amacıyla systemd’nin yerleşik watchdog özelliğini etkinleştirin:

[Service]
WatchdogSec=30s
Restart=on-watchdog

Uygulamanız watchdog zamanlayıcısını sıfırlamak için periyodik olarak sd_notify(0, "WATCHDOG=1") çağırmalıdır. WatchdogSec içinde bunu yapamaması durumunda, systemd hizmeti sonlandırır ve yeniden başlatır.

Doğru Hosting Ortamını Seçmek

Bu kılavuzda açıklanan systemd yapılandırma desenleri tüm Linux sunucu türlerinde eşit şekilde geçerlidir, ancak hosting altyapınızın seçimi, init sistemi ve hizmet yönetimi üzerinde ne kadar kontrole sahip olduğunuzu etkiler.

• VPS Hosting — Tam root erişimi, tam systemd kontrolü, özel uygulama dağıtımları için ideal. AlexHost VPS planları KVM sanallaştırması üzerinde çalışır ve size gerçek bir izole çekirdek ortamı sağlar.
• Dedicated Servers — Kaynak yoğun hizmetler için maksimum performans ve izolasyon. Komşu sorunları olmayan tam donanım erişimi.
• cPanel’li VPS — Root seviyesi systemd erişimini, sistem hizmetlerini ve web hostingini tek bir arayüzden yöneten takımlar için grafik kontrol paneli ile birleştirir.
• Paylaşımlı Web Hosting — Özel sistem hizmetleri gerektirmeyen standart web uygulamaları için uygun. Root erişimi yok, ancak sıfır sunucu yönetimi yükü.

Özel bir daemon, microservice veya yeniden başlatmalardan sonra otomatik olarak çalışması gereken herhangi bir uygulama dağıtıyorsanız, tam root erişimi olan bir VPS veya dedicated sunucu uygun seçimdir.

Hızlı Referans: Eksiksiz systemd Hizmeti Kontrol Listesi

Hizmetinizi üretim ortamına hazır olarak değerlendirmeden önce, bu kontrol listesindeki her öğeyi doğrulayın:

• [ ] Unit dosyası /etc/systemd/system/myapp.service konumuna kaydedildi
• [ ] ExecStart geçerli, çalıştırılabilir bir ikili dosyaya mutlak yol kullanıyor
• [ ] WorkingDirectory var ve hizmet kullanıcısına ait
• [ ] Hizmet, adanmış root olmayan sistem hesabı olarak çalışıyor
• [ ] sudo systemctl daemon-reload herhangi bir unit dosyası değişikliğinden sonra yürütüldü
• [ ] sudo systemctl enable myapp.service sembolik bağlantının oluşturulduğunu doğruluyor
• [ ] sudo systemctl status myapp.service active (running) gösteriyor
• [ ] journalctl -u myapp.service hata göstermiyor
• [ ] Sunucu yeniden başlatıldı ve hizmet önyükleme sonrası çalıştığı doğrulandı
• [ ] Güvenlik sertleştirme yönergeleri (NoNewPrivileges, ProtectSystem, PrivateTmp) uygulandı

Sonuç

systemd, modern Linux sunucuları için kesin hizmet yönetim katmanıdır. İyi yapılandırılmış bir .service unit dosyası oluşturarak, önyükleme sırasında otomatik başlatma, akıllı yeniden başlatma politikaları, merkezi günlüğe kaydetme ve ayrıntılı güvenlik kontrolleri elde edersiniz — tek bir satır shell script yazmadan.

İşlem basittir: adanmış bir çalışma dizini ve sistem kullanıcısı hazırlayın, unit dosyasını doğru [Unit], [Service] ve [Install] bölümleriyle yazın, systemd daemon’unu yeniden yükleyin, hizmeti etkinleştirin ve başlatın, ardından systemctl status ve journalctl ile doğrulayın. Yukarıda tartışılan güvenlik sertleştirme yönergelerini uygulayın ve hizmetiniz hem dayanıklı hem de sistemin geri kalanından uygun şekilde izole edilmiş olacaktır.

AlexHost VPS Hosting veya Dedicated Servers planında bir Node.js API’si, Python worker’ı, Go binary’si veya başka herhangi bir özel uygulama dağıtıyor olsanız da, bu systemd iş akışı hizmetinizin kullanıcılarınızın ihtiyaç duyduğu zaman her zaman çalışmasını sağlar — beklenmedik bir yeniden başlatmadan sonra bile.