Apache HTTP Sunucusu Sürüm 2.0
Apache HTTP Sunucusu Sürüm 2.0
Bu belge Apache HTTPd’nin Unix benzeri sistemlerde durdurulması ve yeniden başlatılması konularını kapsar. Windows NT, 2000 ve XP kullanıcıları Apache HTTPd’yi bu platformlarda nasıl denetimlerine alacaklarını öğrenmek için Apache HTTPd’nin Bir Hizmet Olarak Çalıştırılması sayfasına, Windows 9x ve ME kullanıcıları ise Apache HTTPd’nin Bir Konsol Uygulaması Olarak Çalıştırılması sayfasına bakabilirler.
Apache HTTPd’yi durdurmak ve yeniden başlatmak için çalışan
httpd süreçlerine bir sinyal göndermeniz gerekir.
Sinyal göndermek için iki yol vardır. İlki, süreçlere doğrudan sinyal
göndermek için unix kill komutunun kullanımıdır. Bu
suretle, sisteminizde çalışmakta olan bir çok httpd
sürecini uyarabilirsiniz ama süreç kimliği PidFile yönergesi ile belirtilen dosyada
tutulan ana süreç dışında hiçbirine sinyal göndermemelisiniz. Başka
bir deyişle, ana süreç haricinde hiçbir sürece sinyal göndermeye normal
olarak ihtiyacınız olmaması gerekir. Ana sürece gönderebileceğiniz
üç çeşit sinyal vardır:
TERM,
HUP ve
USR1. Bunlar yeri geldikçe
açıklanacaktır.
Ana sürece kill ile sinyal göndermek için şöyle bir
komut verebilirsiniz:
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
httpd süreçlerine sinyal göndermenin ikinci yolu
-k komut satırı seçeneğini şu değerlerden biri ile
kullanmaktır: stop, restart ve
graceful. Bunlar aşağıda açıklanacaktır.
-k komut satırı seçeneği
httpd’ye ait olsa da ana sürece bu sinyalleri
göndermek için apachectl betiğini kullanmanızı
öneririz. apachectl, komut satırı seçeneklerini
httpd’ye aktaracaktır.
httpd’ye sinyal gönderdikten sonra olup biteni şu
komutla izleyebilirsiniz:
tail -f /usr/local/apache2/logs/error_log
Bu örnekleri, kendi ServerRoot ve
PidFile yönergelerinizdeki
ayarlara uygun olarak değiştirdikten sonra kullanınız.
apachectl -k stopAna sürece TERM veya stop sinyali
göndererek tüm çocukların bir an önce öldürülmeye çalışılmasını sağlamış
olursunuz. Tüm çocukların öldürülmesi bir kaç saniye sürebilir. Son
olarak ana süreç çıkacaktır. Yanıtlanmakta olan istekler hemen
sonlandırılacak ve artık isteklere yanıt verilmeyecektir.
apachectl -k gracefulAna sürece USR1 veya graceful sinyalinin
gönderilmesi, çocuklara ellerindeki mevcut işleri bitirdikten sonra
(veya sundukları bir şey yoksa hemen) çıkmalarının önerilmesi
demektir. Ana süreç kendi yapılandırma dosyalarını yeniden okur ve
kendi günlük dosyalarını yeniden açar. Ana sürecin öldürdüğü her sürecin
yerine yeni yapılandırma kuşağından bir süreç başlatır ve hemen
yeni isteklere hizmet sunulmaya başlanır.
USR1 sinyalinin kullanılmasına izin verilmez. Bu gibi
durumlarda, WINCH gibi başka bir sinyal kullanılabilir.
apachectl graceful komutu platformunuz için doğru sinyali
gönderecektir.Bu kod MPM’lerin süreçleri denetleyen yönergelerine daima uyacak
şekilde tasarlanmıştır. Bu suretle, istemcilere hizmet sunacak çocuk
süreçler ve evreler, yeniden başlatma işleminde de uygun sayıda
sağlanmış olur. Bununla birlikte, StartServers yönergesinde şöyle
davranılır: İlk saniye içinde en azından StartServers sayıda yeni çocuk
oluşturulmamışsa iş olmayan bir devreyi geçiştirecek kadarı oluşturulur.
Ardından sunucunun mevcut yükünü karşılamak için gereken sayıda çocuk
süreç oluşturulur. Bu suretle, kod her ikisi için de gereğini yerine
getirmeye çalışmış olur.
mod_status kullanıcıları USR1
gönderildiği zaman sunucu istatistiklerinin sıfırlanmadığı konusunda
uyarılacaktır. Kod, sunucunun yeni isteklere yanıt veremediği zamanı en
aza indirmenin yanısıra ayar parametrelerinize de uymak üzere
tasarlanmıştır (yeni istekler işletim sistemi tarafından kuyruğa
alınacağından bir istek kaybı olayı yaşanmaz). Bunu sağlamak için, her
iki kuşağın çocuklarının izini sürecek bir çetele tutulur.
mod_status modülü, nazikçe yeniden başlat komutunun
verilmesinden önce başlamış ve sunulmaya devam eden isteklere bakan
çocukları imlemek için ayrıca bir G (Graceful’un baş harfi)
kullanır.
Günlük dosyası döndürme betiğine, yeniden başlatma öncesi günlüğe yazan
tüm çocukların işini bitirdiğini USR1 kullanarak
bildirmenin bir yolu yoktur. Önerimiz, eski günlük kaydı üzerinde bir
işlem yapmaya başlamadan önce USR1 sinyali gönderilmesinin
ardından belli bir süre beklenilmesi olacaktır. Örneğin, düşük band
genişliğine sahip istemcilere hizmet sunan çoğu sürecin işinin 10
dakikadan önce bitmeyeceğini gözönüne alarak eski günlük üzerinde işlem
yapmaya başlamak için 15 dakika beklenebilir.
-t komut satırı seçeneği ile sınayabilirsiniz (bkz,
httpd). Ancak, bu hala sunucunuzun düzgünce yeniden
başlatılmasını garanti etmeyecektir. Yapılandırma dosyalarınızı
sözdizimi denetiminin yanında anlamlandırılması bakımından da sınamak
için httpd’nin root olmayan bir kullanıcı tarafından
çalıştırılmasını deneyebilirsiniz. Eğer yapılandırma dosyalarında bir
hata yoksa soketleri ve günlük dosyalarını açmaya çalışırken root
aidiyetinde çalışmadığından veya çalışmakta olan asıl sunucu bu portları
zaten dinlediğinden başarısız olacaktır. Eğer başka bir sebeple
başarısız olursa olası sebep bir yapılandırma dosyası hatasıdır ve asıl
sunucuya ‘nazikçe yeniden başla’ komutunu vermeden önce bu hatayı
düzeltmeniz gerekir.apachectl -k restartAna sürece HUP veya restart sinyalinin
gönderilmesi tüm çocukların TERM sinyali gönderilmiş gibi
öldürülmesine sebep olur fakat ana sürecin çıkmasını sağlamaz.
Ana süreç yapılandırma dosyalarını yeniden okur ve günlük kayıt
dosyalarını yeniden açar. Bunların ardından isteklere yanıt verecek yeni
kuşak çocukları oluşturmaya başlar.
mod_status kullanıcıları bir HUP sinyali
gönderildiğinde sunucu istatistiklerinin sıfırlandığı konusunda
uyarılırlar.
Apache 1.2b9 sürümü öncesinde, yeniden başlatma ve ölüm sinyalleri ile ilgili olarak ortaya çıkan çeşitli yarış koşulları vardı. (Basitçe, bir yarış koşulu zamanlama ile ilgili bir sorundur; yanlış zamanda veya yanlış sırada oluşan bir şey istenmeyen sonuçlara yol açarken, aynı şey doğru zaman ve doğru sırada oluştuğunda herşey yolunda gider.) Bu tür mimarilerde elimizden geldiği kadar bu sorunları giderecek doğru özellikleri kullanmaya gayret etsek de belli mimarilerde hala yarış koşullarının ortaya çıkma olasılığı bulunduğunu belirtmek gerekir.
Disk üzerinde ScoreBoardFile dosyası tutan mimarilerde
çetele bozulması olasılığı gündeme gelebilir. Bu durum, "bind:
Address already in use" (HUP sonrası) veya "long lost
child came home!" (USR1 sonrası) iletileriyle
sonuçlanabilir. İkincisi sadece çetele kaybına sebep olurken birincisi
ölümcül bir hatadır. Bu bakımdan, normalde nazikçe yeniden başlatma
kullanıp ara sıra normal yeniden başlatma yapılması önerilebilir. Bu
sorunları kitabına uydurmak çok zordur fakat şans eseri çoğu mimari bir
çetele dosyası gerektirmemektedir. Çetele dosyası kullanan mimariler
için ScoreBoardFile belgesine
bakınız.
Kalıcı HTTP bağlantısı (KeepAlive) üzerinden ikinci ve sonraki isteklerle ilgili olarak her çocuk süreçte bir yarış koşulu oluşma olasılığı küçük de olsa bütün mimarilerde vardır. İstek satırı okunduktan sonra hiçbir istek başlığı okunmadan çıkabilir. Bu durum 1.2 sürümünde geç de olsa farkedilmiş ve düzeltme yoluna gidilmiştir. Teorik olarak, ağ gecikmeleri ve sunucu zaman aşımları nedeniyle KeepAlive istemcisi açısından bu olaylar beklenmediğinden, bu önemli bir konu değildir. Uygulamada ise, ne sunucuyu ne de istemciyi etkilediği görülmez; bir deneme ortamında sunucu saniyede 20 kere yeniden başlatılmış ve istemciler boş belge veya bozuk resim almadan siteyi başarıyla gezmişlerdir.