Cara Memulai Ulang PHP-FPM: Setiap Metode Dijelaskan untuk Administrator Linux

PHP-FPM (PHP FastCGI Process Manager) adalah manajer proses berkinerja tinggi yang menangani eksekusi PHP sebagai layanan terpisah, terlepas dari web server. Memulai ulang PHP-FPM menerapkan perubahan konfigurasi dari `php.ini` atau `php-fpm.conf`, mengambil kembali memori yang bocor di pool worker yang berjalan lama, dan memulihkan dari proses anak yang tidak responsif — semua tanpa menyentuh Nginx, Apache, atau komponen lain dari stack Anda.

Panduan ini mencakup setiap metode restart praktis yang tersedia di distribusi Linux modern dan lama, termasuk kontrol berbasis sinyal, lingkungan multi-versi, dan strategi reload graceful untuk deployment produksi tanpa downtime.

Mengapa Anda Perlu Memulai Ulang PHP-FPM

Memahami pemicu yang tepat untuk restart mencegah downtime yang tidak perlu dan membantu Anda memilih metode yang paling tidak mengganggu:

• Perubahan konfigurasi: Modifikasi pada `php.ini`, `php-fpm.conf`, atau file konfigurasi pool apa pun di bawah `/etc/php/<version>/fpm/pool.d/` memerlukan restart atau reload agar berlaku. PHP-FPM membaca file-file ini hanya saat startup atau pada sinyal `USR2`.
• Pengambilan kembali memori: Proses worker PHP-FPM mengakumulasi memori dari waktu ke waktu, terutama pada server dengan lalu lintas tinggi yang menjalankan aplikasi intensif memori. Restart yang terkontrol mendaur ulang worker dan mengatur ulang jejak memori mereka.
• Worker yang tidak responsif: Jika proses anak memasuki status zombie atau berhenti menerima koneksi, restart membersihkan tabel proses dan menghasilkan pool baru.
• Rotasi log: Setelah `logrotate` mengganti nama atau mengompresi file log aktif, PHP-FPM masih memegang deskriptor file ke inode lama. Reload memaksanya membuka deskriptor file baru, memastikan kesinambungan log.
• Invalidasi OPcache: Saat men-deploy kode aplikasi baru, memulai ulang PHP-FPM menghapus OPcache sepenuhnya, memastikan worker mengeksekusi bytecode yang diperbarui daripada versi cache yang sudah usang.
• Perubahan ekstensi atau modul: Menambahkan atau menghapus ekstensi PHP di `php.ini` memerlukan restart penuh — reload saja tidak cukup karena daftar ekstensi dievaluasi saat inisialisasi proses.

Prasyarat

Sebelum menjalankan perintah restart apa pun, konfirmasikan hal-hal berikut:

• Anda memiliki akses `root` atau hak istimewa `sudo` di server.
• Anda mengetahui nama layanan PHP-FPM yang tepat di sistem Anda (bervariasi berdasarkan distribusi dan versi yang diinstal).
• Anda telah mengidentifikasi jalur file PID jika Anda berencana menggunakan kontrol berbasis sinyal (biasanya `/run/php/php<version>-fpm.pid` di Debian/Ubuntu atau `/run/php-fpm/php-fpm.pid` di RHEL/CentOS).

Untuk menemukan nama layanan PHP-FPM yang aktif:

“`bash

systemctl list-units –type=service | grep fpm

“`

Untuk menemukan jalur file PID:

“`bash

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

“`

Metode 1: Memulai Ulang PHP-FPM dengan systemctl (Direkomendasikan)

`systemctl` adalah manajer layanan resmi di semua distribusi berbasis systemd, termasuk Ubuntu 16.04+, Debian 8+, CentOS 7+, AlmaLinux, Rocky Linux, dan Fedora. Ini adalah alat yang tepat untuk sebagian besar server produksi.

Restart Standar

“`bash

sudo systemctl restart php8.2-fpm

“`

Ganti `php8.2-fpm` dengan versi yang diinstal di sistem Anda (misalnya, `php7.4-fpm`, `php8.1-fpm`, `php-fpm`). Pada sistem berbasis RHEL, layanan biasanya diberi nama `php-fpm` tanpa awalan versi.

Reload Tanpa Restart Penuh

Reload mengirimkan sinyal `USR2` secara internal, menginstruksikan proses master untuk membaca ulang konfigurasinya dan mengganti proses worker secara graceful. Permintaan yang sedang berjalan diselesaikan sebelum worker didaur ulang:

“`bash

sudo systemctl reload php8.2-fpm

“`

Perbedaan penting: `reload` tidak mengganggu dan lebih disukai untuk perubahan konfigurasi di produksi. `restart` menghentikan semua worker segera, yang dapat memutus koneksi aktif di bawah konkurensi tinggi.

Stop dan Start Secara Terpisah

“`bash

sudo systemctl stop php8.2-fpm

sudo systemctl start php8.2-fpm

“`

Gunakan pendekatan dua langkah ini ketika Anda perlu memastikan layanan benar-benar berhenti sebelum menghidupkannya kembali — misalnya, setelah mengubah jalur socket `listen` atau memodifikasi `pm.max_children` secara signifikan.

Verifikasi Status Layanan

“`bash

sudo systemctl status php8.2-fpm

“`

Output yang sehat menampilkan `Active: active (running)` dan mencantumkan PID master. Jika layanan gagal dimulai, `systemctl status` menampilkan entri jurnal terakhir, yang lebih cepat daripada mencari melalui file log secara manual.

Untuk mengalirkan log langsung selama restart:

“`bash

sudo journalctl -u php8.2-fpm -f

“`

Metode 2: Memulai Ulang PHP-FPM dengan Perintah service Lama

Perintah `service` adalah pembungkus kompatibilitas di sekitar `systemctl` pada sistem modern dan langsung memanggil skrip SysVinit pada distribusi lama (Ubuntu 14.04, CentOS 6, Debian 7). Ini tetap relevan saat mengelola server yang belum dimigrasikan ke systemd.

“`bash

sudo service php-fpm restart

“`

Untuk stop dan start secara independen:

“`bash

sudo service php-fpm stop

sudo service php-fpm start

“`

Pada distribusi yang masih menggunakan SysVinit, skrip yang mendasarinya terletak di `/etc/init.d/php-fpm`. Anda dapat memanggilnya langsung jika pembungkus `service` tidak tersedia:

“`bash

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

“`

Metode 3: Mengelola Beberapa Versi PHP Secara Bersamaan

Server yang menjalankan panel kontrol seperti cPanel, Plesk, atau setup multi-tenant kustom sering memiliki beberapa versi PHP yang diinstal secara paralel. Setiap versi berjalan sebagai layanan PHP-FPM independen dengan pohon konfigurasi, socket, dan file PID-nya sendiri.

Memulai Ulang Versi Tertentu

“`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

“`

Memulai Ulang Semua Versi PHP-FPM Sekaligus

Ketika perubahan seluruh sistem memengaruhi semua versi (seperti pembaruan pustaka bersama), mulai ulang semua instance dengan satu loop:

“`bash

for ver in 7.4 8.1 8.2; do

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

done

“`

Mengidentifikasi Versi Mana yang Melayani Situs Tertentu

Setiap virtual host Nginx atau VirtualHost Apache dipetakan ke socket PHP-FPM tertentu. Periksa konfigurasi situs untuk menentukan versi mana yang aktif sebelum memulai ulang:

“`bash

Nginx

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

Apache with mod_proxy_fcgi

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

“`

Jika Anda mengelola server melalui panel kontrol, VPS dengan cPanel menyediakan antarmuka grafis untuk beralih versi PHP per domain tanpa restart layanan manual.

Metode 4: Mengirim Sinyal POSIX Langsung ke Proses Master

Proses master PHP-FPM merespons sekumpulan sinyal POSIX yang telah ditentukan. Metode ini sepenuhnya melewati sistem init dan memberi Anda kontrol yang tepat dan tingkat rendah — penting dalam lingkungan yang dikontainerisasi, sistem init kustom, atau ketika `systemctl` tidak tersedia.

Tabel Referensi Sinyal

Reload Konfigurasi (Zero Downtime)

“`bash

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

“`

Ini secara fungsional setara dengan `systemctl reload` dan merupakan cara paling aman untuk menerapkan perubahan konfigurasi `php-fpm.conf` atau pool pada server yang sedang berjalan.

Buka Ulang File Log Setelah Rotasi

“`bash

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

“`

Jalankan ini segera setelah `logrotate` dieksekusi untuk mencegah PHP-FPM terus menulis ke file log yang telah diganti namanya.

Shutdown Graceful

“`bash

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

“`

Proses master berhenti menerima koneksi baru dan menunggu semua worker aktif menyelesaikan permintaan mereka saat ini sebelum keluar. Ikuti ini dengan `sudo systemctl start php8.2-fpm` untuk menghidupkan kembali layanan.

Penting: Selalu verifikasi jalur file PID sebelum menggunakan perintah-perintah ini. Jalur yang salah mengakibatkan pengiriman sinyal ke proses yang tidak terkait. Konfirmasikan dengan:

“`bash

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

ps aux | grep php-fpm

“`

Metode 5: Paksa Matikan Proses PHP-FPM dengan pkill atau killall

Ini adalah metode upaya terakhir untuk situasi di mana PHP-FPM menjadi sepenuhnya tidak responsif dan baik `systemctl` maupun kontrol berbasis sinyal tidak menghasilkan hasil. Ini menghentikan semua proses PHP-FPM tanpa syarat, yang akan mengganggu permintaan yang sedang berjalan.

“`bash

sudo pkill -9 php-fpm

“`

Atau menggunakan `killall`:

“`bash

sudo killall -9 php-fpm

“`

Setelah paksa matikan, layanan tidak akan dimulai ulang secara otomatis kecuali dikelola oleh pengawas proses. Mulailah secara eksplisit:

“`bash

sudo systemctl start php8.2-fpm

“`

Kapan menggunakan ini: Akumulasi proses zombie, proses anak yang tidak terkendali mengonsumsi 100% CPU, atau situasi di mana proses master masih hidup tetapi tidak lagi mengelola pool-nya. Sebelum menggunakan `pkill -9`, coba `kill -QUIT` pada PID master terlebih dahulu — ini jauh lebih tidak mengganggu.

Metode 6: Memulai Ulang Web Server untuk Memengaruhi PHP-FPM Secara Tidak Langsung

Memulai ulang Nginx atau Apache tidak memulai ulang PHP-FPM. Karena PHP-FPM berjalan sebagai layanan yang sepenuhnya independen yang berkomunikasi melalui socket Unix atau port TCP, restart web server hanya memengaruhi lapisan HTTP. Ini adalah kesalahpahaman yang umum.

“`bash

Nginx

sudo systemctl restart nginx

Apache

sudo systemctl restart apache2

“`

Satu-satunya skenario di mana restart web server relevan dengan PHP-FPM adalah ketika Anda telah memodifikasi direktif `fastcgi_pass` di Nginx atau aturan `ProxyPassMatch` di Apache untuk menunjuk ke socket PHP-FPM yang berbeda. Dalam kasus itu, Nginx harus memuat ulang konfigurasinya untuk terhubung ke jalur socket baru — tetapi PHP-FPM itu sendiri masih memerlukan restart terpisahnya sendiri.

Untuk pemeliharaan full-stack, mulai ulang kedua layanan dalam urutan yang benar: PHP-FPM terlebih dahulu, kemudian web server.

Perbandingan: Metode Restart PHP-FPM Sekilas

Konfigurasi Pool PHP-FPM: Apa yang Memerlukan Restart vs. Reload

Tidak semua perubahan konfigurasi memiliki bobot yang sama. Mengetahui perubahan mana yang memerlukan restart penuh versus reload sederhana mengurangi downtime yang tidak perlu:

Reload (`USR2` / `systemctl reload`) sudah cukup untuk:

• `pm.max_children`, `pm.start_servers`, `pm.min_spare_servers`, `pm.max_spare_servers`
• `request_terminate_timeout`, `request_slowlog_timeout`
• Perubahan jalur `slowlog`
• Direktif `php_admin_value` dan `php_flag` dalam file pool
• Perubahan jalur `access.log`

Restart penuh diperlukan untuk:

• Perubahan pada direktif `listen` (jalur socket atau port TCP)
• Menambahkan atau menghapus ekstensi PHP di `php.ini`
• Mengubah direktif `user` atau `group` dalam pool
• Memodifikasi jalur `include` di `php-fpm.conf`
• Memperbarui biner PHP itu sendiri (peningkatan versi)

Praktik Terbaik untuk Restart PHP-FPM Produksi

• Selalu utamakan `reload` daripada `restart` di server yang sedang berjalan. Reload mendaur ulang worker secara graceful, menyelesaikan permintaan yang sedang berjalan sebelum menghasilkan pengganti. Restart keras memutus semua koneksi aktif segera.
• Validasi konfigurasi sebelum reload. PHP-FPM menyediakan pemeriksaan sintaks bawaan yang mencegah memuat konfigurasi yang rusak:

“`bash

sudo php-fpm8.2 -t

Expected output: NOTICE: configuration file … test is successful

“`

• Periksa log sebelum dan sesudah. Tinjau `/var/log/php8.2-fpm.log` (atau jalur yang ditentukan dalam `php-fpm.conf` Anda) untuk entri `WARNING` atau `ERROR` yang menunjukkan kegagalan startup pool.
• Pantau metrik pool worker pasca-restart. Gunakan halaman status PHP-FPM (diaktifkan melalui `pm.status_path` dalam konfigurasi pool Anda) untuk memverifikasi bahwa jumlah worker yang diharapkan aktif dan idle setelah restart.
• Otomatisasi dengan pipeline deployment. Dalam alur kerja CI/CD, picu `systemctl reload php-fpm` sebagai hook pasca-deploy daripada restart penuh. Ini memastikan deployment tanpa downtime pada setiap push kode.
• Atur `pm.max_requests` untuk mendaur ulang worker secara otomatis. Daripada menjadwalkan restart berkala untuk mengatasi kebocoran memori, konfigurasikan `pm.max_requests = 500` (atau nilai yang sesuai) untuk secara otomatis memulai ulang setiap worker setelah melayani sejumlah permintaan tetap.

PHP-FPM di Lingkungan VPS dan Server Dedicated

Metode restart yang Anda gunakan juga dipengaruhi oleh lingkungan hosting Anda. Pada paket VPS Hosting dengan akses root penuh, semua metode yang dijelaskan dalam panduan ini tersedia tanpa batasan. Anda memiliki akses langsung ke `systemctl`, file PID, dan tabel proses.

Pada Server Dedicated, di mana Anda mengontrol seluruh stack perangkat keras, Anda juga dapat mengonfigurasi PHP-FPM dengan `pm = ondemand` atau `pm = dynamic` untuk menyetel perilaku spawning worker secara tepat, dan menggunakan file drop-in `systemd` untuk menyesuaikan kebijakan restart (misalnya, `Restart=on-failure`, `RestartSec=5s`).

Jika Anda mengelola beberapa situs klien melalui solusi VPS Control Panels, operasi restart PHP-FPM sering diabstraksikan ke dalam UI panel, tetapi memahami perintah yang mendasarinya tetap penting untuk skenario pemecahan masalah di mana panel itu sendiri tidak responsif.

Untuk aplikasi yang memerlukan konkurensi PHP tinggi — seperti Laravel, WordPress multisite, atau toko WooCommerce — memasangkan PHP-FPM dengan konfigurasi pool yang disetel dengan baik pada Server Dedicated menghilangkan persaingan sumber daya yang diperkenalkan oleh lingkungan bersama.

Matriks Keputusan Teknis: Memilih Metode Restart yang Tepat

Gunakan matriks ini untuk memilih pendekatan yang tepat berdasarkan situasi spesifik Anda:

FAQ

Apa perbedaan antara `systemctl restart` dan `systemctl reload` untuk PHP-FPM?

`restart` segera menghentikan semua proses master dan worker dan memulai dari awal, memutus permintaan yang sedang berjalan. `reload` mengirimkan sinyal `USR2` ke proses master, yang menghasilkan worker baru dengan konfigurasi yang diperbarui sementara worker yang ada menyelesaikan permintaan mereka saat ini sebelum keluar. Selalu gunakan `reload` di produksi.

Bagaimana cara menemukan nama layanan PHP-FPM yang benar di server saya?

Jalankan `systemctl list-units –type=service | grep fpm`. Pada sistem Debian/Ubuntu dengan beberapa versi dari PPA `ondrej/php`, Anda akan melihat entri seperti `php7.4-fpm.service` dan `php8.2-fpm.service`. Pada RHEL/CentOS dengan repositori Remi, konvensi penamaan adalah `php74-php-fpm.service`.

Apakah memulai ulang PHP-FPM memengaruhi koneksi database aktif atau sesi pengguna?

Restart keras (`systemctl restart`) menghentikan semua proses worker segera, yang menutup koneksi database persisten yang dipegang oleh worker tersebut. Sesi pengguna yang disimpan dalam file atau database tidak terpengaruh karena mereka bertahan secara independen dari worker PHP-FPM. Reload graceful (`systemctl reload`) memungkinkan worker menyelesaikan permintaan mereka saat ini, sehingga koneksi persisten ditutup dengan bersih.

Mengapa PHP-FPM gagal dimulai setelah restart?

Penyebab paling umum adalah kesalahan sintaks di `php.ini` atau file konfigurasi pool, konflik port atau jalur socket (proses lain sudah mendengarkan pada alamat `listen` yang dikonfigurasi), atau izin yang tidak cukup pada direktori socket. Jalankan `php-fpm<ver> -t` untuk memvalidasi sintaks konfigurasi, dan periksa `journalctl -u php<ver>-fpm` untuk pesan kesalahan yang tepat.

Bisakah saya memulai ulang PHP-FPM tanpa hak akses root atau sudo?

Tidak pada instalasi Linux standar. Proses master PHP-FPM berjalan sebagai root (ia menurunkan hak istimewa ke `user`/`group` yang dikonfigurasi untuk proses worker), dan mengelola layanan sistem memerlukan hak istimewa yang ditingkatkan. Pada lingkungan shared hosting, penyedia hosting menangani restart PHP-FPM melalui panel kontrol mereka. Untuk kontrol penuh atas PHP-FPM, paket VPS Hosting dengan akses root adalah solusi yang tepat.