Apache Başlamıyor: Yaygın Nedenler ve Çözüm Adımları

Sabah erkenden telefon çalıyor, ekip arkadaşın “site çöktü” diyor ve sen hemen sunucuya bağlanıyorsun. systemctl status apache2 çıktısına bakıyorsun, kırmızı bir “failed” yazısı seni karşılıyor. Bu senaryo her sysadmin’in başına en az bir kez gelmiştir. Apache’nin neden başlamadığını hızlıca bulmak ve çözmek, hem senin hem de şirketin için kritik bir beceri. Bu yazıda Apache’nin başlamamasına yol açan en yaygın nedenleri, nasıl teşhis edeceğini ve adım adım nasıl çözeceğini ele alacağız.

İlk Adım: Durumu Anlamak

Paniğe kapılmadan önce yapman gereken ilk şey, Apache’nin tam olarak ne dediğini anlamak. Servis yöneticisinden başla:

systemctl status apache2
# veya RHEL/CentOS için:
systemctl status httpd

Bu komutun çıktısı sana çok şey söyler. “Active: failed” görüyorsan, hemen ardından gelen satırlarda kısa bir hata özeti bulursun. Ama bu özet genellikle yeterli değildir. Daha detaylı log’lara bakmak için şunu kullan:

journalctl -xe -u apache2
# veya
journalctl -xe -u httpd

-xe parametreleri şu anlama gelir:

• -x: Hata mesajlarına açıklama ekler
• -e: Log’un sonuna atlar, en son hataları görürsün

Apache’nin kendi log dosyalarına da mutlaka göz at:

tail -n 50 /var/log/apache2/error.log
# veya RHEL/CentOS:
tail -n 50 /var/log/httpd/error_log

Bu üç kaynaktan birinde mutlaka somut bir hata mesajı bulursun. Şimdi bu hataların her birine tek tek bakalım.

Port Çakışması: En Yaygın Sebep

Apache varsayılan olarak 80 ve 443 portlarını dinler. Eğer bu portları başka bir uygulama zaten kullanıyorsa, Apache başlayamaz. Hata mesajı genellikle şöyle görünür:

(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80

Hangi uygulamanın o portu kullandığını bulmak için:

ss -tlnp | grep ':80'
# veya eski yöntemle:
netstat -tlnp | grep ':80'
# ya da doğrudan port sahibini görmek için:
lsof -i :80

Çıktıda nginx, tomcat, node veya başka bir şey görürsen, önce karar vermen gerekiyor: O uygulama orada olmalı mı? Eğer yanlışlıkla çalışıyorsa durdur:

systemctl stop nginx

Eğer her iki uygulama da aynı portu kullanması gerekiyorsa, yapılandırmayı gözden geçirmen şart. Apache’yi farklı bir porta yönlendirmek için /etc/apache2/ports.conf dosyasını düzenle:

nano /etc/apache2/ports.conf

İçinde Listen 80 yazan satırı bulup Listen 8080 gibi uygun bir porta çevirebilirsin. Ama production ortamında bunu yapmadan önce tüm sanal host yapılandırmalarını da güncellemeyi unutma.

Yapılandırma Dosyası Hataları

Apache’nin başlamamasının bir diğer çok yaygın nedeni, config dosyasındaki sözdizimi hataları. Birisi bir sanal host eklemiş, bir karakter yanlış yazılmış, Apache o dosyayı parse edemez ve başlamayı reddeder.

Neyse ki Apache, başlamadan önce kendi yapılandırmasını test etme imkanı sunar:

apache2ctl configtest
# veya
apachectl configtest
# RHEL/CentOS:
httpd -t

Bu komut çalıştırıldığında ya Syntax OK yazar ya da tam olarak hangi dosyanın hangi satırında hata olduğunu söyler:

AH00526: Syntax error on line 23 of /etc/apache2/sites-enabled/mysite.conf:
Invalid command 'ServerNam', perhaps misspelled or defined by a module that's not enabled

Yukarıdaki örnekte ServerName yerine ServerNam yazılmış. Bu tür yazım hataları saatlerce hata ayıklamana neden olabilir. Hatayı bulduktan sonra ilgili dosyayı düzenle ve tekrar test et.

Config test geçtikten sonra Apache’yi başlatmayı dene:

systemctl start apache2

Yaygın Config Hataları

Sözdizimi hatalarının en sık karşılaşılan türleri şunlar:

• Kapanmayan direktifler: açıp yazmamak
• Eksik noktalı virgül veya tırnak: SSLCertificateFile "/etc/ssl/certs/site.crt gibi kapanmamış tırnak
• Yanlış dosya yolu: DocumentRoot olarak var olmayan bir dizin vermek
• Büyük/küçük harf hatası: Direktifler büyük/küçük harf duyarlıdır

Modül Sorunları

Apache bir modüle referans veriyorsa ama o modül yüklü değilse, başlamayı reddeder. Hata mesajı şuna benzer:

Invalid command 'SSLEngine', perhaps misspelled or defined by a module that's not enabled

Bu durumda ilgili modülü etkinleştirmen gerekiyor. Debian/Ubuntu sistemlerde:

a2enmod ssl
systemctl restart apache2

Etkin olan modülleri listelemek için:

apache2ctl -M

RHEL/CentOS sistemlerde modüller genellikle /etc/httpd/conf.modules.d/ dizininde yönetilir. İlgili modül dosyasında satırın başındaki # işaretini kaldırarak etkinleştirebilirsin.

Bir de şuna dikkat et: Bazen bir modülü etkinleştirirsin ama o modülün bağımlı olduğu başka bir modül eksik olabilir. apache2ctl configtest bunu da yakalar.

SSL Sertifika Sorunları

HTTPS kullanan bir sunucuda SSL sertifikasıyla ilgili sorunlar Apache’nin başlamasını engelleyebilir. En yaygın senaryolar:

Sertifika dosyası bulunamıyor:

SSLCertificateFile: file '/etc/ssl/certs/mysite.crt' does not exist or is empty

Sertifikanın süresi dolmuş: Bu durum Apache’nin başlamasını her zaman engellemez ama bazı yapılandırmalarda sorun çıkarabilir.

Özel anahtar ile sertifika eşleşmiyor: Bu ciddi bir hatadır:

SSL Library Error: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

Sertifika ve anahtar dosyasının eşleşip eşleşmediğini kontrol etmek için modulus değerlerini karşılaştır:

openssl x509 -noout -modulus -in /etc/ssl/certs/mysite.crt | md5sum
openssl rsa -noout -modulus -in /etc/ssl/private/mysite.key | md5sum

Her iki komutun çıktısı aynı MD5 hash’ini veriyorsa, sertifika ve anahtar eşleşiyor demektir. Farklıysa, yanlış dosyaları kullanıyorsundur.

Sertifika dosyasının izinlerini de kontrol et. Özel anahtar dosyası root dışında kimse tarafından okunamamalı:

chmod 600 /etc/ssl/private/mysite.key
chown root:root /etc/ssl/private/mysite.key

İzin ve Sahiplik Sorunları

Apache’nin erişmesi gereken dosya ve dizinlere izin yoksa bu da başlama sorunlarına yol açar. Özellikle log dizinleri, PID dosyası ve DocumentRoot dizinleri bu açıdan kritik.

PID dosyası problemi sık yaşanan bir durum. Apache başlarken /var/run/apache2/apache2.pid dosyasını oluşturur. Eğer bu dizin yoksa veya Apache’nin bu dizine yazma izni yoksa başlayamaz:

ls -la /var/run/apache2/
# Yoksa oluştur:
mkdir -p /var/run/apache2/
chown www-data:www-data /var/run/apache2/

Log dizini için de benzer bir kontrol yap:

ls -la /var/log/apache2/

www-data kullanıcısının (veya apache kullanıcısının RHEL sistemlerde) bu dizine yazma izni olmalı.

DocumentRoot olarak belirtilen dizin yoksa da Apache bunu hata olarak kaydeder:

# Belirtilen dizinin var olup olmadığını kontrol et:
ls -la /var/www/html/mysite
# Yoksa oluştur:
mkdir -p /var/www/html/mysite
chown -R www-data:www-data /var/www/html/mysite

SELinux ve AppArmor Engellemeleri

Security-Enhanced Linux veya AppArmor etkinse, Apache’nin bazı dosyalara veya portlara erişimini engelleyebilir. Bu durum özellikle RHEL/CentOS sistemlerde sık yaşanır.

SELinux’un engelleme yapıp yapmadığını kontrol etmek için:

ausearch -c 'httpd' --raw | audit2allow -M myhttpd
# veya audit log'larına bak:
tail -f /var/log/audit/audit.log | grep httpd

Hızlı test için SELinux’u geçici olarak permissive moda al ve Apache’nin başlayıp başlamadığını gör:

setenforce 0
systemctl start httpd

Eğer bu şekilde başlıyorsa, sorun SELinux’tan kaynaklanıyor demektir. Kalıcı çözüm için doğru SELinux politikasını oluşturman gerekir, SELinux’u tamamen kapatmak production’da iyi bir fikir değil.

Non-standart bir port kullanıyorsan, SELinux’a bu porta izin vermek gerekir:

semanage port -a -t http_port_t -p tcp 8080

Ubuntu/Debian sistemlerde AppArmor için:

aa-status
# Apache profilini kontrol et:
cat /etc/apparmor.d/usr.sbin.apache2

Disk Dolu ve Kaynak Sorunları

“Disk dolu” durumu çok ilginç hatalara yol açabilir. Apache log yazamıyorsa veya PID dosyası oluşturamıyorsa başlamayı reddedebilir.

Disk kullanımını kontrol et:

df -h
# Inode kullanımını da kontrol et, bazen inode dolar ama disk dolu görünmez:
df -i

Eğer /var bölümü doluysa log dosyaları şişmiş olabilir. En büyük log dosyalarını bul:

find /var/log -type f -name "*.log" -exec du -sh {} ; | sort -rh | head -20

Geçmiş Apache log’larını temizlemek için logrotate’i manuel tetikleyebilirsin:

logrotate -f /etc/logrotate.d/apache2

Bellek sorunu da Apache’nin başlamasını engelleyebilir. Özellikle MaxRequestWorkers veya MaxClients gibi direktifler çok yüksek ayarlanmışsa, Apache başlarken yeterli bellek bulamayabilir:

free -h

Sanal Host Çakışmaları

Birden fazla sanal host yapılandırması varsa ve bunlar birbiriyle çakışıyorsa sorun çıkabilir. Özellikle aynı IP:port kombinasyonunun birden fazla yerde tanımlanması veya eksik ServerName direktifi bu tür sorunlara yol açar.

Etkin sanal hostları listele:

apache2ctl -S
# veya
apachectl -S

Bu çıktı hangi sanal hostların aktif olduğunu, hangi portları dinlediklerini ve olası çakışmaları gösterir. Çıktıda “warning” görürsen, bunları da ciddiye al.

Bir örnek gerçek dünya senaryosu: Bir müşterinin sitesi için /etc/apache2/sites-available/ altına yeni bir config dosyası oluşturulmuş ama hem eski hem yeni config aynı ServerName değerini kullanıyor. Apache başlıyor ama yanlış sanal hosta yönlendiriyor. apachectl -S bu durumu hemen gün yüzüne çıkarır.

Sistematik Hata Ayıklama Yaklaşımı

Yukarıdaki senaryoların hiçbiri sorununla örtüşmüyorsa, adım adım sistematik bir yaklaşım benimse:

# 1. Önce config'i test et
apache2ctl configtest

# 2. Verbose modda manuel başlat (servis olmadan)
apache2 -e debug -DFOREGROUND

# 3. Tüm hata log'larını gerçek zamanlı izle
tail -f /var/log/apache2/error.log &

# 4. System log'larını kontrol et
journalctl -f -u apache2

# 5. Strace ile sistem çağrılarını izle (son çare)
strace -e trace=file apache2 -t 2>&1 | grep "No such file"

strace ile Apache’nin hangi dosyalara erişmeye çalıştığını görebilirsin. Bu özellikle “dosya bulunamadı” türü gizli hataları yakalamak için harika bir yöntem.

Güncelleme Sonrası Bozulan Yapılandırma

Sistem güncellemesi sonrası Apache’nin bozulması da çok yaygın. Özellikle Apache versiyonu değişmişse, bazı direktifler deprecated olmuş ya da kaldırılmış olabilir. Hata mesajında “deprecated” veya “no longer supported” gibi ifadeler görüyorsan bu senaryodaki gibidir.

Apache’nin hangi versiyonundan hangisine geçtiğini kontrol et:

apache2 -v
# Değişiklik notlarına bak:
dpkg -l apache2

Apache 2.2’den 2.4’e geçişte Order Allow,Deny direktiflerinin yerine Require kullanılması gerekiyor. Bu tür eski direktifler yeni versiyonda hata verebilir. Eski config:

Order allow,deny
Allow from all

Yeni (2.4+) karşılığı:

Require all granted

Güncelleme sonrası backup config dosyaları da sorun çıkarabilir. .bak, .old veya ~ uzantılı config dosyaları bazen Apache tarafından da parse edilmeye çalışılır:

ls /etc/apache2/sites-enabled/
ls /etc/apache2/conf-enabled/

Bu dizinlerde yedek dosyaları görürsen, Apache bunları da okumaya çalışıyor olabilir. Güvenli bir yere taşı.

Hızlı Referans: Teşhis Komutları

Sorun yaşadığında sırayla çalıştırabileceğin teşhis komutlarını özetleyelim:

# Servis durumu
systemctl status apache2

# Config sözdizimi kontrolü
apache2ctl configtest

# Port kullanımı kontrolü
ss -tlnp | grep -E ':80|:443'

# Apache log'larına son bakış
tail -50 /var/log/apache2/error.log

# Sanal host durumu
apache2ctl -S

# Yüklü modüller
apache2ctl -M

# Disk durumu
df -h && df -i

# Bellek durumu
free -h

Bu komutları bir script haline getirip “apache-debug.sh” olarak kaydedebilirsin. Bir sonraki olayda tek komutla tüm bilgileri toplayabilirsin.

Sonuç

Apache’nin başlamaması ilk anda stresli görünse de neredeyse her zaman belirli birkaç nedenden birinden kaynaklanır. Port çakışması, config sözdizimi hatası, eksik modül, sertifika sorunu, izin problemi veya disk dolması… Bunların hepsinin üstesinden gelmek için önce doğru log’u okumak, sonra sistematik bir şekilde ilerlemek yeterli.

En önemli alışkanlık şu: Apache’de değişiklik yapmadan önce her zaman configtest çalıştır. Bu tek alışkanlık, gece 2’de aldığın “site çöktü” telefonlarının büyük çoğunluğunu önler. Bir de production’da değişiklik yapmadan önce staging ortamında test etmek, seni birçok dertten kurtarır.

Son olarak, daha önce yaşanan sorunları ve çözümleri bir yere kaydet. Runbook veya wiki fark etmez, önemli olan bilginin kaybolmaması. Bir sorunla bir kez karşılaşıp çözdüysen, ikinci karşılaşmada 10 dakika değil 1 dakika harcamalısın. Bu kadar.