PHP-FPM Nasıl Yeniden Başlatılır: Linux Yöneticileri için Her Yöntem Açıklandı

PHP-FPM (PHP FastCGI Process Manager), PHP yürütmesini web sunucusundan bağımsız, ayrı bir hizmet olarak yöneten yüksek performanslı bir süreç yöneticisidir. PHP-FPM’yi yeniden başlatmak, `php.ini` veya `php-fpm.conf` dosyalarındaki yapılandırma değişikliklerini uygular, uzun süreli çalışan worker havuzlarındaki sızdırılan belleği geri kazanır ve yanıt vermeyen alt süreçlerden kurtarır — Nginx, Apache veya yığınınızın diğer bileşenlerine dokunmadan.

Bu kılavuz, sinyal tabanlı kontrol, çok sürümlü ortamlar ve sıfır kesinti süreli üretim dağıtımları için zarif yeniden yükleme stratejileri dahil olmak üzere modern ve eski Linux dağıtımlarında mevcut olan her pratik yeniden başlatma yöntemini kapsar.

PHP-FPM’yi Neden Yeniden Başlatmanız Gerekiyor

Yeniden başlatmanın tam tetikleyicisini anlamak gereksiz kesinti sürelerini önler ve en az kesintiye yol açan yöntemi seçmenize yardımcı olur:

• Yapılandırma değişiklikleri: `php.ini`, `php-fpm.conf` veya `/etc/php/<version>/fpm/pool.d/` altındaki herhangi bir havuz yapılandırma dosyasında yapılan değişiklikler, geçerli olması için yeniden başlatma veya yeniden yükleme gerektirir. PHP-FPM bu dosyaları yalnızca başlangıçta veya `USR2` sinyalinde okur.
• Bellek geri kazanımı: PHP-FPM worker süreçleri, özellikle bellek yoğun uygulamalar çalıştıran yüksek trafikli sunucularda zamanla bellek biriktirir. Kontrollü bir yeniden başlatma, worker’ları yeniler ve bellek kullanımlarını sıfırlar.
• Yanıt vermeyen worker’lar: Alt süreçler zombi durumuna girerse veya bağlantıları kabul etmeyi durdurursa, yeniden başlatma süreç tablosunu temizler ve yeni bir havuz oluşturur.
• Log rotasyonu: `logrotate` aktif log dosyasını yeniden adlandırdıktan veya sıkıştırdıktan sonra, PHP-FPM eski inode’a bir dosya tanımlayıcısı tutmaya devam eder. Yeniden yükleme, yeni dosya tanımlayıcısını açmaya zorlar ve log sürekliliğini sağlar.
• OPcache geçersiz kılma: Yeni uygulama kodu dağıtırken, PHP-FPM’yi yeniden başlatmak OPcache’i tamamen temizler ve worker’ların eski önbelleğe alınmış sürümler yerine güncellenmiş bytecode’u çalıştırmasını garanti eder.
• Uzantı veya modül değişiklikleri: `php.ini` dosyasında PHP uzantıları eklemek veya kaldırmak tam bir yeniden başlatma gerektirir — uzantı listesi süreç başlatma sırasında değerlendirildiğinden yalnızca yeniden yükleme yeterli değildir.

Ön Koşullar

Herhangi bir yeniden başlatma komutu çalıştırmadan önce aşağıdakileri doğrulayın:

• Sunucuda `root` erişiminiz veya `sudo` ayrıcalıklarınız var.
• Sisteminizde tam PHP-FPM hizmet adını biliyorsunuz (dağıtıma ve yüklü sürüme göre değişir).
• Sinyal tabanlı kontrol kullanmayı planlıyorsanız PID dosya yolunu belirlediniz (genellikle Debian/Ubuntu’da `/run/php/php<version>-fpm.pid` veya RHEL/CentOS’ta `/run/php-fpm/php-fpm.pid`).

Aktif PHP-FPM hizmet adını bulmak için:

“`bash

systemctl list-units –type=service | grep fpm

“`

PID dosya yolunu bulmak için:

“`bash

grep -i pid /etc/php/*/fpm/php-fpm.conf

“`

Yöntem 1: systemctl ile PHP-FPM’yi Yeniden Başlatma (Önerilen)

`systemctl`, Ubuntu 16.04+, Debian 8+, CentOS 7+, AlmaLinux, Rocky Linux ve Fedora dahil olmak üzere tüm systemd tabanlı dağıtımlarda yetkili hizmet yöneticisidir. Üretim sunucularının büyük çoğunluğu için doğru araçtır.

Standart Yeniden Başlatma

“`bash

sudo systemctl restart php8.2-fpm

“`

`php8.2-fpm` kısmını sisteminizde yüklü olan sürümle değiştirin (örn. `php7.4-fpm`, `php8.1-fpm`, `php-fpm`). RHEL tabanlı sistemlerde hizmet genellikle sürüm öneki olmadan `php-fpm` olarak adlandırılır.

Tam Yeniden Başlatma Olmadan Yeniden Yükleme

Yeniden yükleme dahili olarak bir `USR2` sinyali gönderir ve ana sürece yapılandırmasını yeniden okumasını ve worker süreçlerini zarif bir şekilde değiştirmesini talimat verir. Uçuştaki mevcut istekler, worker’lar geri dönüştürülmeden önce tamamlanır:

“`bash

sudo systemctl reload php8.2-fpm

“`

Kritik ayrım: `reload` kesintisizdir ve üretimde yapılandırma değişiklikleri için tercih edilir. `restart` tüm worker’ları anında sonlandırır; bu, yüksek eşzamanlılık altında aktif bağlantıları düşürebilir.

Ayrı Ayrı Durdurma ve Başlatma

“`bash

sudo systemctl stop php8.2-fpm

sudo systemctl start php8.2-fpm

“`

Bu iki adımlı yaklaşımı, hizmeti geri getirmeden önce tamamen durduğunu doğrulamanız gerektiğinde kullanın — örneğin, `listen` soket yolunu değiştirdikten veya `pm.max_children` dosyasını önemli ölçüde değiştirdikten sonra.

Hizmet Durumunu Doğrulama

“`bash

sudo systemctl status php8.2-fpm

“`

Sağlıklı bir çıktı `Active: active (running)` gösterir ve ana PID’yi listeler. Hizmet başlatılamadıysa, `systemctl status` son günlük girişlerini görüntüler; bu, log dosyalarını manuel olarak aramaktan çok daha hızlıdır.

Yeniden başlatma sırasında canlı logları akışla izlemek için:

“`bash

sudo journalctl -u php8.2-fpm -f

“`

Yöntem 2: Eski service Komutuyla PHP-FPM’yi Yeniden Başlatma

`service` komutu, modern sistemlerde `systemctl` etrafında bir uyumluluk sarmalayıcısıdır ve eski dağıtımlarda (Ubuntu 14.04, CentOS 6, Debian 7) doğrudan SysVinit betiklerini çağırır. systemd’ye geçirilmemiş sunucuları yönetirken hâlâ geçerliliğini korur.

“`bash

sudo service php-fpm restart

“`

Bağımsız olarak durdurmak ve başlatmak için:

“`bash

sudo service php-fpm stop

sudo service php-fpm start

“`

Hâlâ SysVinit kullanan dağıtımlarda, temel betik `/etc/init.d/php-fpm` konumundadır. `service` sarmalayıcısı kullanılamıyorsa doğrudan çağırabilirsiniz:

“`bash

sudo /etc/init.d/php-fpm restart

“`

Yöntem 3: Birden Fazla PHP Sürümünü Eş Zamanlı Yönetme

cPanel, Plesk gibi kontrol panelleri veya özel çok kiracılı kurulumlar çalıştıran sunucularda genellikle birkaç PHP sürümü paralel olarak yüklüdür. Her sürüm, kendi yapılandırma ağacı, soketi ve PID dosyasıyla bağımsız bir PHP-FPM hizmeti olarak çalışır.

Belirli Bir Sürümü Yeniden Başlatma

“`bash

Debian/Ubuntu (packages from ondrej/php PPA or distribution repos)

sudo systemctl restart php7.4-fpm

sudo systemctl restart php8.1-fpm

sudo systemctl restart php8.2-fpm

RHEL/CentOS with Remi repository

sudo systemctl restart php74-php-fpm

sudo systemctl restart php81-php-fpm

“`

Tüm PHP-FPM Sürümlerini Aynı Anda Yeniden Başlatma

Sistem genelinde bir değişiklik tüm sürümleri etkilediğinde (paylaşılan kütüphane güncellemesi gibi), tek bir döngüyle tüm örnekleri yeniden başlatın:

“`bash

for ver in 7.4 8.1 8.2; do

sudo systemctl restart php${ver}-fpm && echo "php${ver}-fpm restarted"

done

“`

Belirli Bir Siteye Hangi Sürümün Hizmet Verdiğini Belirleme

Her Nginx sanal ana bilgisayarı veya Apache VirtualHost, belirli bir PHP-FPM soketine eşlenir. Yeniden başlatmadan önce hangi sürümün aktif olduğunu belirlemek için site yapılandırmasını kontrol edin:

“`bash

Nginx

grep fastcgi_pass /etc/nginx/sites-enabled/yourdomain.conf

Apache with mod_proxy_fcgi

grep SetHandler /etc/apache2/sites-enabled/yourdomain.conf

“`

Sunucunuzu bir kontrol paneli aracılığıyla yönetiyorsanız, cPanel’li VPS, manuel hizmet yeniden başlatmaları olmadan alan adı başına PHP sürümlerini değiştirmek için grafiksel bir arayüz sağlar.

Yöntem 4: Ana Sürece Doğrudan POSIX Sinyalleri Gönderme

PHP-FPM’nin ana süreci, tanımlanmış bir POSIX sinyalleri kümesine yanıt verir. Bu yöntem, init sistemini tamamen atlayarak size hassas, düşük seviyeli kontrol sağlar — kapsayıcılı ortamlarda, özel init sistemlerinde veya `systemctl` kullanılamadığında gereklidir.

Sinyal Referans Tablosu

Yapılandırmayı Yeniden Yükleme (Sıfır Kesinti Süresi)

“`bash

sudo kill -USR2 $(cat /run/php/php8.2-fpm.pid)

“`

Bu, işlevsel olarak `systemctl reload` ile eşdeğerdir ve canlı bir sunucuda `php-fpm.conf` veya havuz yapılandırma değişikliklerini uygulamanın en güvenli yoludur.

Rotasyondan Sonra Log Dosyalarını Yeniden Açma

“`bash

sudo kill -USR1 $(cat /run/php/php8.2-fpm.pid)

“`

PHP-FPM’nin yeniden adlandırılmış log dosyasına yazmaya devam etmesini önlemek için `logrotate` çalıştıktan hemen sonra bunu çalıştırın.

Zarif Kapatma

“`bash

sudo kill -QUIT $(cat /run/php/php8.2-fpm.pid)

“`

Ana süreç yeni bağlantıları kabul etmeyi durdurur ve çıkmadan önce tüm aktif worker’ların mevcut isteklerini tamamlamasını bekler. Hizmeti geri getirmek için bunu `sudo systemctl start php8.2-fpm` ile takip edin.

Önemli: Bu komutları kullanmadan önce her zaman PID dosya yolunu doğrulayın. Yanlış bir yol, ilgisiz bir sürece sinyal gönderilmesiyle sonuçlanır. Şununla doğrulayın:

“`bash

cat /run/php/php8.2-fpm.pid

ps aux | grep php-fpm

“`

Yöntem 5: pkill veya killall ile PHP-FPM Süreçlerini Zorla Öldürme

Bu, PHP-FPM’nin tamamen yanıt vermez hale geldiği ve ne `systemctl` ne de sinyal tabanlı kontrolün sonuç vermediği durumlar için son çare yöntemidir. Tüm PHP-FPM süreçlerini koşulsuz olarak sonlandırır; bu, uçuştaki istekleri kesintiye uğratır.

“`bash

sudo pkill -9 php-fpm

“`

Veya `killall` kullanarak:

“`bash

sudo killall -9 php-fpm

“`

Zorla öldürmeden sonra, bir süreç denetçisi tarafından yönetilmiyorsa hizmet otomatik olarak yeniden başlamaz. Açıkça başlatın:

“`bash

sudo systemctl start php8.2-fpm

“`

Ne zaman kullanılır: Zombi süreç birikimi, %100 CPU tüketen kontrolden çıkmış alt süreçler veya ana sürecin canlı olduğu ancak artık havuzunu yönetmediği durumlar. `pkill -9` kullanmadan önce, ana PID üzerinde `kill -QUIT` denemeyi deneyin — çok daha az kesintiye yol açar.

Yöntem 6: PHP-FPM’yi Dolaylı Olarak Etkilemek İçin Web Sunucusunu Yeniden Başlatma

Nginx veya Apache’yi yeniden başlatmak PHP-FPM’yi yeniden başlatmaz. PHP-FPM, Unix soketi veya TCP portu üzerinden iletişim kuran tamamen bağımsız bir hizmet olarak çalıştığından, web sunucusu yeniden başlatması yalnızca HTTP katmanını etkiler. Bu yaygın bir yanılgıdır.

“`bash

Nginx

sudo systemctl restart nginx

Apache

sudo systemctl restart apache2

“`

Web sunucusu yeniden başlatmasının PHP-FPM ile ilgili olduğu tek senaryo, Nginx’teki `fastcgi_pass` yönergesini veya Apache’deki `ProxyPassMatch` kuralını farklı bir PHP-FPM soketine işaret edecek şekilde değiştirdiğinizde gerçekleşir. Bu durumda, Nginx yeni soket yoluna bağlanmak için yapılandırmasını yeniden yüklemek zorundadır — ancak PHP-FPM’nin kendisi hâlâ kendi ayrı yeniden başlatmasına ihtiyaç duyar.

Tam yığın bakımı için her iki hizmeti de doğru sırayla yeniden başlatın: önce PHP-FPM, ardından web sunucusu.

Karşılaştırma: Bir Bakışta PHP-FPM Yeniden Başlatma Yöntemleri

PHP-FPM Havuz Yapılandırması: Yeniden Başlatma ile Yeniden Yükleme Gerektiren Değişiklikler

Tüm yapılandırma değişiklikleri aynı ağırlığı taşımaz. Hangi değişikliklerin tam yeniden başlatma yerine basit bir yeniden yükleme gerektirdiğini bilmek gereksiz kesinti sürelerini azaltır:

Yeniden yükleme (`USR2` / `systemctl reload`) şunlar için yeterlidir:

• `pm.max_children`, `pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`
• `request_terminate_timeout`, `request_slowlog_timeout`
• `slowlog` yol değişiklikleri
• Havuz dosyalarındaki `php_admin_value` ve `php_flag` yönergeleri
• `access.log` yol değişiklikleri

Tam yeniden başlatma gereklidir:

• `listen` yönergesindeki değişiklikler (soket yolu veya TCP portu)
• `php.ini` dosyasında PHP uzantıları ekleme veya kaldırma
• Havuzdaki `user` veya `group` yönergelerini değiştirme
• `php-fpm.conf` dosyasındaki `include` yollarını değiştirme
• PHP ikili dosyasının kendisini güncelleme (sürüm yükseltmeleri)

Üretim PHP-FPM Yeniden Başlatmaları için En İyi Uygulamalar

• Canlı sunucularda her zaman `reload` yerine `restart` tercih edin. Yeniden yükleme, worker’ları zarif bir şekilde geri dönüştürür; yedek worker’lar oluşturulmadan önce uçuştaki istekleri tamamlar. Sert yeniden başlatma tüm aktif bağlantıları anında düşürür.
• Yeniden yüklemeden önce yapılandırmayı doğrulayın. PHP-FPM, bozuk bir yapılandırmanın yüklenmesini önleyen yerleşik bir sözdizimi denetimi sağlar:

“`bash

sudo php-fpm8.2 -t

Expected output: NOTICE: configuration file … test is successful

“`

• Öncesinde ve sonrasında logları kontrol edin. Havuz başlatma hatalarını gösteren `WARNING` veya `ERROR` girişleri için `/var/log/php8.2-fpm.log` dosyasını (veya `php-fpm.conf` dosyanızda tanımlanan yolu) inceleyin.
• Yeniden başlatma sonrası worker havuzu metriklerini izleyin. Yeniden başlatmadan sonra beklenen sayıda worker’ın aktif ve boşta olduğunu doğrulamak için PHP-FPM durum sayfasını (havuz yapılandırmanızda `pm.status_path` aracılığıyla etkinleştirilir) kullanın.
• Dağıtım hatlarıyla otomatikleştirin. CI/CD iş akışlarında, tam yeniden başlatma yerine dağıtım sonrası kanca olarak `systemctl reload php-fpm` tetikleyin. Bu, her kod gönderiminde sıfır kesinti süreli dağıtımlar sağlar.
• Worker’ları otomatik geri dönüştürmek için `pm.max_requests` ayarlayın. Bellek sızıntılarıyla mücadele etmek için periyodik yeniden başlatmalar planlamak yerine, her worker’ı sabit sayıda istek sunulduktan sonra otomatik olarak yeniden başlatmak için `pm.max_requests = 500` (veya uygun bir değer) yapılandırın.

VPS ve Özel Sunucu Ortamlarında PHP-FPM

Kullandığınız yeniden başlatma yöntemi aynı zamanda barındırma ortamınızdan da etkilenir. Tam kök erişimine sahip bir VPS Hosting planında, bu kılavuzda açıklanan tüm yöntemler kısıtlama olmaksızın kullanılabilir. `systemctl`, PID dosyasına ve süreç tablosuna doğrudan erişiminiz vardır.

Tüm donanım yığınını kontrol ettiğiniz Özel Sunucular‘da, worker oluşturma davranışını hassas şekilde ayarlamak için PHP-FPM’yi `pm = ondemand` veya `pm = dynamic` ile yapılandırabilir ve yeniden başlatma politikalarını özelleştirmek için `systemd` drop-in dosyalarını kullanabilirsiniz (örn. `Restart=on-failure`, `RestartSec=5s`).

Birden fazla istemci sitesini bir VPS Kontrol Panelleri çözümü aracılığıyla yönetiyorsanız, PHP-FPM yeniden başlatma işlemleri genellikle panelin kullanıcı arayüzüne soyutlanmıştır; ancak panelin kendisinin yanıt vermediği sorun giderme senaryoları için temel komutları anlamak hâlâ önemlidir.

Laravel, WordPress çoklu site veya WooCommerce mağazaları gibi yüksek PHP eşzamanlılığı gerektiren uygulamalar için, PHP-FPM’yi bir Özel Sunucu‘da düzgün ayarlanmış havuz yapılandırmasıyla eşleştirmek, paylaşımlı ortamların getirdiği kaynak çekişmesini ortadan kaldırır.

Teknik Karar Matrisi: Doğru Yeniden Başlatma Yöntemini Seçme

Belirli durumunuza göre doğru yaklaşımı seçmek için bu matrisi kullanın:

SSS

PHP-FPM için `systemctl restart` ile `systemctl reload` arasındaki fark nedir?

`restart` tüm ana ve worker süreçlerini anında sonlandırır ve sıfırdan başlar; uçuştaki istekleri düşürür. `reload` ana sürece bir `USR2` sinyali gönderir; bu, mevcut worker’lar mevcut isteklerini tamamlayıp çıkmadan önce güncellenmiş yapılandırmayla yeni worker’lar oluşturur. Üretimde her zaman `reload` kullanın.

Sunucumdaki doğru PHP-FPM hizmet adını nasıl bulurum?

`systemctl list-units –type=service | grep fpm` komutunu çalıştırın. `ondrej/php` PPA’dan birden fazla sürüme sahip Debian/Ubuntu sistemlerinde `php7.4-fpm.service` ve `php8.2-fpm.service` gibi girişler göreceksiniz. Remi deposuyla RHEL/CentOS’ta adlandırma kuralı `php74-php-fpm.service` şeklindedir.

PHP-FPM’yi yeniden başlatmak aktif veritabanı bağlantılarını veya kullanıcı oturumlarını etkiler mi?

Sert yeniden başlatma (`systemctl restart`) tüm worker süreçlerini anında sonlandırır; bu, söz konusu worker’lar tarafından tutulan kalıcı veritabanı bağlantılarını kapatır. Dosyalarda veya veritabanında depolanan kullanıcı oturumları, PHP-FPM worker’larından bağımsız olarak devam ettiğinden etkilenmez. Zarif yeniden yükleme (`systemctl reload`), worker’ların mevcut isteklerini tamamlamasına izin verir; böylece kalıcı bağlantılar temiz bir şekilde kapatılır.

Yeniden başlatmadan sonra PHP-FPM neden başlatılamıyor?

En yaygın nedenler şunlardır: `php.ini` veya havuz yapılandırma dosyasında sözdizimi hatası, port veya soket yolu çakışması (yapılandırılmış `listen` adresini zaten dinleyen başka bir süreç) veya soket dizininde yetersiz izinler. Yapılandırma sözdizimini doğrulamak için `php-fpm<ver> -t` komutunu çalıştırın ve tam hata mesajı için `journalctl -u php<ver>-fpm` dosyasını kontrol edin.

PHP-FPM’yi root veya sudo ayrıcalıkları olmadan yeniden başlatabilir miyim?

Standart bir Linux kurulumunda hayır. PHP-FPM’nin ana süreci root olarak çalışır (worker süreçleri için yapılandırılmış `user`/`group` ayrıcalıklarına düşürür) ve sistem hizmetlerini yönetmek yükseltilmiş ayrıcalıklar gerektirir. Paylaşımlı barındırma ortamlarında, barındırma sağlayıcısı PHP-FPM yeniden başlatmalarını kontrol panelleri aracılığıyla yönetir. PHP-FPM üzerinde tam kontrol için, kök erişimine sahip bir VPS Hosting planı uygun çözümdür.