Apache HTTP Sunucusu Sürüm 2.2

This document refers to the 2.2 version of Apache httpd, which is no longer maintained. The active release is documented here. If you have not already upgraded, please follow this link for more information.
You may follow this link to go to the current version of this document.
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
      dört çeşit sinyal vardır:
      TERM,
      USR1,
      HUP ve
      WINCH. 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,
      graceful ve graceful-stop. 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.
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.
apachectl -k graceful-stopAna sürecin WINCH veya graceful-stop
      sinyalini alması, çocuklara ellerindeki mevcut işleri bitirdikten sonra
      (veya sundukları bir şey yoksa hemen) çıkmalarının önerilmesine
      sebep olur. Ebevey süreç bunun hemen PidFile dosyasını siler ve port
      dinlemeyi keser. Ana süreç çalışmaya ve isteklere yanıt vermekte olan
      çocuk süreçleri izlemeye devam eder. Tüm çocuklar işlerini bitirip
      çıktığında veya GracefulShutdownTimeout ile belirtilen
      zaman aşımı dolduğunda ana süreç de kendini sonlandırır. Eğer zaman aşımı
      devreye girmişse o an calışmakta olan çocuk süreçlere TERM
      sinyali gönderilerek hemen çıkmaları sağlanır.
Bir TERM sinyali ile "graceful" durumundaki tüm çocuklar
      ve ana süreç hemen sonlandırılacaktır. Bununla birlikte, PidFile dosyası da silineceğinden, artık
      apachectl veya httpd’yi bu sinyali göndermek
      için kullanamayacaksınız.
graceful-stop sinyali, aynı anda, aynı yapılandırma
      ile çok sayıda httpd kopyasının çalıştırılabilmesine
      imkan verir.  Bu, Apache nazikçe yükseltileceği zaman güçlü bir özellik
      haline gelmekteyse de, bazı yapılandırmalarda yarış koşullarının
      oluşmasına ve kısır çekişmelere (deadlock) sebep olabilir.
Sunucunun süreç kimliğini içeren Lockfile ve ScriptSock gibi dosyaların disk üzerindeki
      mevcudiyetlerinin sorunsuz olarak devam ettiğinden emin olunmaya
      çalışılmalıdır.  Ayrıca, bir yapılandırma yönergesi, üçüncü parti bir
      modül veya kalıcı CGI uygulamalarına ait disk kilit veya durum dosyaları
      olabilir; httpd’nin birden fazla kopyasının çalışması
      nedeniyle bu dosyaların da üzerine yazılmadığından emin olunmaya
      çalışılmalıdır.
rotatelogs tarzı borulu günlükleme kullanımı gibi
      durumlarda yarış koşullarının oluşması olasılığına karşı uyanık
      olunmalıdır. Aynı günlük kayıt dosyalarını aynı anda döndürmeye çalışan
      birden fazla rotatelogs kopyasının çalıştırılması
      halinde bunların her biri diğerlerinin günlük kayıt dosyalarının kaybına
      sebep olabilir.