Apache service failed Hatası: systemd ve Yapılandırma Sorunlarını Güvenle Giderme

Apache service failed hatası, Apache HTTP Server hizmetinin systemd tarafından başlatılamadığını veya başlatıldıktan hemen sonra durduğunu gösteren genel bir uyarıdır. Hata, tek başına kök nedeni söylemez; hatalı bir sanal host yapılandırması, kullanımda olan 80/443 portu, geçersiz SSL dosya yolu, disk doluluğu ya da erişim izni sorunu buna neden olabilir. Bu rehber, Linux üzerinde Apache’nin neden başlamadığını güvenli biçimde belirlemek ve yalnızca doğrulanmış nedene yönelik düzeltme yapmak için hazırlanmıştır. Önce servis ve hata günlüklerini inceleyin, ardından yapılandırmayı test edin; üretim sisteminde doğrudan dosya silmek veya rastgele yapılandırma değiştirmekten kaçının.

Belirti ve kapsam: Apache neden “failed” durumuna geçer?

Hata genellikle aşağıdaki komutlardan sonra görünür:

sudo systemctl start apache2
sudo systemctl restart apache2
sudo systemctl start httpd

Debian ve Ubuntu ailesinde hizmet adı çoğunlukla apache2, RHEL, AlmaLinux, Rocky Linux, CentOS ve Fedora ailesinde ise çoğunlukla httpd olur. Panel kullanan sunucularda servis adı veya Apache ikili dosyasının konumu özelleştirilmiş olabilir; bu nedenle önce sistemdeki gerçek servis birimini doğrulayın.

“failed” durumu, web sitelerinin ulaşılamaz olmasına yol açabilir. Ancak servis gerçekten hiç açılmamış olabileceği gibi, yanlış bir denemeden kalmış eski bir systemd durumu da olabilir. Bu ayrımı servis durumu ve günlük kayıtlarıyla yapmak gerekir.

Apache service failed hatası için hızlı teşhis özeti

• Doğru servis adını ve son hata satırlarını alın.
• Apache yapılandırmasını yeniden başlatmadan önce sözdizimi açısından test edin.
• 80 ve 443 portlarını dinleyen başka bir süreç olup olmadığını kontrol edin.
• SSL sertifikası, özel anahtar ve include edilen dosyaların varlığını ve okunabilirliğini denetleyin.
• Disk alanı, inode tüketimi, dosya izinleri ve RHEL tabanlı sistemlerde SELinux reddini inceleyin.
• Yalnızca hata giderildikten sonra servisi başlatın ve HTTP/HTTPS yanıtını doğrulayın.

Olası nedenler ve ilk kontrol noktaları

Belirti veya log ifadesi	Muhtemel neden	Güvenli ilk işlem
Syntax error, Invalid command	Hatalı Apache yapılandırması veya eksik modül	Yapılandırma testini çalıştırın ve belirtilen dosya/satırı inceleyin.
Address already in use	80 veya 443 port çakışması	Portu dinleyen süreci belirleyin; körlemesine süreç sonlandırmayın.
SSLCertificateFile veya Permission denied	Eksik sertifika, anahtar veya yetersiz erişim izni	Dosya yolu, sahiplik ve erişim izinlerini doğrulayın.
No space left on device	Disk ya da inode doluluğu	Önce alan tüketimini tespit edin; logları ve uygulama verisini silmeden inceleyin.
SELinux is preventing veya AVC kaydı	SELinux güvenlik politikası engeli	Audit kayıtlarını inceleyin; SELinux’u kalıcı olarak kapatmayın.
AH00072 ile başlayan port hataları	Başka web sunucusu ya da eski Apache süreci	ss çıktısıyla süreç sahipliğini doğrulayın.

Loglar ve komutlarla kök nedeni bulma

1. Servis birimini ve systemd günlüğünü inceleyin

Önce hangi servis biriminin mevcut olduğunu kontrol edin:

systemctl list-unit-files | grep -E '^(apache2|httpd)\.service'

Debian/Ubuntu için aşağıdaki komutları kullanın:

sudo systemctl status apache2 --no-pager -l
sudo journalctl -u apache2 -b --no-pager -n 100

RHEL tabanlı dağıtımlar için eşdeğeri:

sudo systemctl status httpd --no-pager -l
sudo journalctl -u httpd -b --no-pager -n 100

-b seçeneği, mevcut önyüklemenin kayıtlarına odaklanır. Çıktıda özellikle error, failed, AH0, permission denied ve yapılandırma dosyası yolu içeren satırları not edin. Systemd’in kısa özeti yerine Apache’nin kendi hata mesajı çözüm için belirleyicidir.

2. Apache hata günlüğünü kontrol edin

Standart paket kurulumlarında günlük yolu dağıtıma göre değişir. Debian/Ubuntu’da sıklıkla /var/log/apache2/error.log, RHEL ailesinde ise sıklıkla /var/log/httpd/error_log kullanılır. Dosya sisteminizde varlığını doğrulayarak son satırları okuyun:

sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/httpd/error_log

Bu iki dosyadan yalnızca sisteminizde bulunanı kullanın. Özel kurulumlarda günlük yolu ana Apache yapılandırmasında farklı tanımlanmış olabilir.

3. Yeniden başlatmadan önce yapılandırma testini çalıştırın

Yapılandırma hatası şüphesi varsa servis yeniden başlatmak yerine test edin. Bu yaklaşım çalışan bir Apache’nin gereksiz kesintiye uğramasını da önler.

# Debian/Ubuntu
sudo apache2ctl configtest

# RHEL, AlmaLinux, Rocky Linux, CentOS, Fedora
sudo httpd -t

Başarılı bir test genellikle Syntax OK döndürür. Test bir dosya ve satır numarası verirse önce yalnızca o bölümü inceleyin. Yakın zamanda eklenen bir VirtualHost bloğu, Include satırı, modül yapılandırması veya SSL tanımı sorunun kaynağı olabilir.

Apache service failed hatasını güvenli biçimde çözme

Uyarı: Üretim sunucusunda yapılandırma dosyası, sertifika veya port kullanımını değiştirmek hizmet kesintisine neden olabilir. Değişiklikten önce ilgili yapılandırma dosyalarının yedeğini alın ve mümkünse bakım penceresi planlayın. Çalışan bir yapılandırmayı değiştirmeden önce mevcut içeriği ve son değişiklikleri kayıt altına alın.

Yapılandırma testi hata veriyorsa

Testin işaret ettiği dosyayı açmadan önce yedekleyin. Örneğin dosya yolunu kendi hata çıktınızla değiştirin:

sudo cp -a /etc/apache2/sites-available/ornek.conf /etc/apache2/sites-available/ornek.conf.bak.$(date +%F-%H%M%S)

Yaygın sorunlar; kapanmamış bir etiket, yanlış yazılmış yönerge, etkin olmayan modüle ait direktif veya mevcut olmayan include dosyasıdır. Bir SSL sanal hostunda sertifika yenilemesi sonrası dosya yolu değişmişse, SSLCertificateFile ve SSLCertificateKeyFile tanımlarının gerçekten var olan dosyalara işaret ettiğini doğrulayın:

sudo ls -l /sertifika/dosyasi.pem /anahtar/dosyasi.key

Yol örnektir; log veya yapılandırmada geçen gerçek yolları kullanın. Özel anahtar dosyasını geniş izinlerle açmayın. Apache hizmet hesabının ve ana dizinlerin dosyaya erişebildiğinden emin olun; anahtarın içeriğini ekrana yazdırmayın veya paylaşmayın.

80 veya 443 portu kullanımda ise

Apache, dinlemesi gereken porta başka bir süreç bağlanmışsa başlatılamaz. Dinleyen servisleri belirleyin:

sudo ss -ltnp '( sport = :80 or sport = :443 )'

Çıktıda Nginx, Caddy, başka bir Apache örneği, Docker proxy süreci veya beklenmeyen bir uygulama görülebilir. Önce bu sürecin neden çalıştığını değerlendirin. Ters proxy mimarisinde Nginx’in 80/443 üzerinde, Apache’nin ise farklı bir yerel portta dinlemesi tasarlanmış olabilir. Böyle bir mimaride Apache’yi zorla 80/443’e bağlamaya çalışmak yerine mevcut port planını ve Apache’nin Listen yönergelerini doğrulayın.

Yanlışlıkla başlatılmış ve gerekli olmadığı doğrulanmış bir hizmet çakışmaya neden oluyorsa, değişiklik yönetimi kapsamında o hizmeti durdurup Apache’yi tekrar test edin. PID’ye göre rastgele kill -9 kullanmak veri kaybı veya yeni kesintiler doğurabilir.

Disk alanı veya inode doluysa

Apache günlük yazamadığında, geçici dosya oluşturamadığında veya yapılandırmada referans verilen dosyalara erişemediğinde hizmet başarısız olabilir. Alan ve inode durumunu inceleyin:

df -h
df -i

Özellikle /, /var ve ayrı bir bölümse günlüklerin bulunduğu dosya sistemini kontrol edin. Büyük dosyaları silmeden önce hangi dizinin alan kullandığını saptayın. Log rotasyonu çalışmıyorsa sebebini inceleyin; uygulama verileri, veritabanı dosyaları veya sertifika dosyalarını yer açmak amacıyla silmeyin.

SELinux engeli varsa

RHEL tabanlı sistemlerde SELinux etkinse, dosya izinleri doğru görünse bile politika Apache erişimini engelleyebilir. Önce modu ve son AVC kayıtlarını kontrol edin:

getenforce
sudo ausearch -m AVC,USER_AVC -ts recent

Apache’nin standart dışı bir dizinden içerik veya sertifika okuması, ya da standart dışı bir porta bağlanması politikaya takılabilir. Kalıcı çözüm, erişilmesi gereken dosya veya dizin için doğru SELinux bağlamını ve gerekiyorsa onaylı boolean ayarını belirlemektir. Sorunu gizlemek için SELinux’u disabled yapmak veya sürekli permissive modda bırakmak güvenlik riskidir.

Düzeltme sonrası başlatma ve doğrulama

Yapılandırma testi başarıyla tamamlanmadan Apache’yi yeniden başlatmayın. Test başarılıysa uygun komutu kullanın:

# Debian/Ubuntu
sudo systemctl restart apache2
sudo systemctl is-active apache2

# RHEL tabanlı dağıtımlar
sudo systemctl restart httpd
sudo systemctl is-active httpd

active sonucu tek başına yeterli değildir. Yerel HTTP yanıtını da kontrol edin:

curl -I http://127.0.0.1/
curl -k -I https://127.0.0.1/

-k seçeneği yalnızca yerel teşhis sırasında sertifika doğrulama sorununu ayırmak için kullanılmalıdır; istemcilerde kalıcı kullanım için uygun değildir. Beklenen sanal host adına göre test gerekliyse DNS çözümlemesinin doğru olduğundan emin olun. Son olarak servis günlüğünde yeni hata üretilmediğini doğrulayın.

Tekrarını önleme

• Her yapılandırma değişikliğinden sonra yeniden başlatmadan önce configtest çalıştırın.
• Sertifika yenileme süreçlerinde dosya yollarını, sahiplikleri ve tam sertifika zincirini doğrulayın.
• Disk alanı ve inode kullanımını izleyin; günlük rotasyonunun çalıştığını düzenli kontrol edin.
• 80/443 portları için açık bir ters proxy ve servis sahipliği planı tutun.
• Yapılandırma dosyalarında değişiklik kaydı ve geri dönüş kopyası bulundurun.

Sonuç

Apache service failed hatası çoğu zaman tek bir systemd sorunu değil, alttaki yapılandırma, port, dosya erişimi veya kaynak problemine verilen sonuçtur. En güvenli sıra; günlükleri okumak, Apache yapılandırmasını test etmek, port ve sistem kaynaklarını denetlemek, ardından doğrulanmış düzeltmeyi uygulayıp yerel HTTP/HTTPS yanıtını ölçmektir. Bu yaklaşım, gereksiz servis kesintilerini ve hatayı maskeleyen geçici müdahaleleri azaltır.

Sık sorulan sorular

Apache neden “active (running)” iken site açılmıyor?

Apache çalışıyor olsa da yanlış sanal host, DNS kaydı, güvenlik duvarı, TLS yapılandırması veya uygulama katmanı sorunu erişimi engelleyebilir. Önce sunucuda curl -I ile yerel yanıtı doğrulayın.

Apache’yi yeniden kurmak sorunu çözer mi?

Genellikle ilk adım değildir. Hatalı site yapılandırması, port çakışması veya sertifika yolu gibi sorunlar paket yeniden kurulsa da sürebilir. Önce günlük ve yapılandırma testi ile kök nedeni belirleyin.

“Address already in use” hatasında hangi süreci durdurmalıyım?

Önce ss -ltnp ile portu hangi sürecin tuttuğunu belirleyin. Süreci ancak mimarinizde gereksiz veya yanlışlıkla çalıştığı doğrulandıktan sonra, kontrollü biçimde durdurun.

SELinux’u kapatmak gerekli mi?

Hayır. SELinux reddi varsa ilgili AVC kaydını inceleyip doğru bağlamı veya politikayı uygulamak daha güvenlidir. SELinux’u kapatmak koruma katmanını azaltır.

Yapılandırma testinde “Syntax OK” çıkarsa sorun kesin çözülmüş müdür?

Hayır. Bu sonuç yalnızca Apache yapılandırmasının sözdizimsel olarak geçerli olduğunu gösterir. Port çakışması, disk doluluğu, dosya erişimi ve çalışma zamanı bağımlılıkları ayrıca kontrol edilmelidir.