Apache HTTP Sunucusu Sürüm 2.0

Apache > HTTP Sunucusu > Belgeleme > Sürüm 2.0

# Durdurma ve Yeniden Başlatma

Mevcut Diller: de | en | es | ja | ko | ru | tr

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.

### Ayrıca bakınız:

- `httpd`
- `apachectl`
- Başlatma

## Giriş

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.

## Hemen Durdur

Sinyal: TERM
  `apachectl -k stop`

Ana 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.

## Nazikçe Yeniden Başlat

Sinyal: USR1
  `apachectl -k graceful`

Ana 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.

Belli platformlarda, nazikçe yeniden başlatma için `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.

Bir yeniden başlatma isteğinde, eğer yapılandırma dosyalarınızda bir hata varsa sunucu yeniden başlamaz ve bir hata ile çıkar. Nazikçe yeniden başlatma durumunda ana süreç çıkarken çocuklarını çalışır durumda bırakır. (Bunlar, ellerindeki istekler bitince ‘nazikçe çıkacak’ olan çocuk süreçlerdir.) Eğer sunucuyu yeniden başlatmaya çalışırsanız bu sorunlara yol açar; örneğin, dinleyeceği portları bağlayamayabilir. Bir yeniden başlatma öncesinde yapılandırma dosyalarınızın sözdizimini `-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.

## Hemen Yeniden Başlat

Sinyal: HUP
  `apachectl -k restart`

Ana 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.

Eğer yapılandırma dosyalarınızda sözdizimi hatası varsa yeniden başlatma işlemi gerçekleşmez ve ana süreç bir hata vererek çıkar. Bundan kaçınmak için önceki yönteme bakınız.

## Ek: Sinyaller ve yarış koşulları

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.

Mevcut Diller: de | en | es | ja | ko | ru | tr