This is a classic issue many sysadmins encounter when configuring PHP on CentOS. You edit /usr/local/lib/php.ini, restart Apache, but changes mysteriously disappear. Even more bizarre - emptying the file entirely doesn't break anything! Let's dissect why this happens.

First, verify which php.ini file PHP actually loads:

php --ini | grep "Loaded Configuration File"

You might discover PHP is loading from /etc/php.d/ instead. On modern CentOS installations, PHP often uses a modular configuration system where settings are split across multiple .ini files in /etc/php.d/.

PHP's configuration follows this precedence order:

1. Per-directory .user.ini files (PHP 5.3+)
2. Main php.ini file
3. Additional .ini files in scan_dir
4. Apache/Nginx directives

Run these to gather intel:

# Check all loaded .ini files
php -i | grep "\.ini"

# See the effective value of a specific setting
php -r "echo ini_get('memory_limit');"

# Find where specific extensions load from
php --ri pdo_mysql | grep "ini file"

• Multiple PHP installations: which php vs which php-fpm might point to different binaries
• PHP-FPM pool configuration: If using FPM, check pool.d/*.conf files
• SELinux context: ls -Z /usr/local/lib/php.ini should show httpd_sys_content_t

For Apache:

# Graceful restart preserves connections
sudo apachectl graceful

# Or full restart
sudo systemctl restart httpd

For PHP-FPM:

sudo systemctl restart php-fpm

When managing PHP configurations:

# Always create backups
sudo cp /etc/php.ini /etc/php.ini.bak_$(date +%Y%m%d)

# Use diff to verify changes
diff -u /etc/php.ini.bak /etc/php.ini

# For quick testing, override settings at runtime
php -d memory_limit=512M your_script.php

If increasing memory_limit isn't working:

# 1. Find where it's being set
grep -r "memory_limit" /etc/php*

# 2. Check for override in .htaccess
grep "php_value memory_limit" /var/www/html/.htaccess

# 3. Verify with CLI
php -r "echo ini_get('memory_limit');"

---

When PHP configuration changes don't reflect after modifying php.ini, it typically indicates one of these scenarios:

• PHP is loading a different ini file than you're editing
• The web server isn't properly restarted
• Configuration is being overridden elsewhere

Create a test PHP file with the following content and access it via browser:

<?php
phpinfo();
?>

Search for "Loaded Configuration File" in the output. This shows the actual php.ini being used.

On CentOS systems, common pitfalls include:

# Check for multiple PHP installations
$ which php
/usr/bin/php

# Verify CLI vs Apache PHP versions
$ php -v
$ apachectl -M | grep php

PHP configuration can be overridden at multiple levels:

1. Main php.ini file
2. Per-directory .user.ini files
3. Apache/Nginx configuration overrides
4. Runtime ini_set() calls

Instead of just restarting, try this sequence:

# Full service restart
$ sudo systemctl stop httpd
$ sudo systemctl start httpd

# Alternative graceful restart
$ sudo apachectl graceful

Compare CLI and web PHP configurations:

# Check CLI loaded settings
$ php -i | grep memory_limit

# Check web-context settings
$ curl http://localhost/test.php | grep memory_limit

Common directives that might override php.ini:

# In Apache VirtualHost
<IfModule mod_php7.c>
    php_value memory_limit 256M
</IfModule>

# In .htaccess
php_flag display_errors on

For persistent changes that survive updates:

# Create custom ini file
$ sudo nano /etc/php.d/99-custom.ini

# Add your custom directives
memory_limit = 256M
upload_max_filesize = 64M

On CentOS, SELinux might prevent config changes:

# Check SELinux context
$ ls -Z /usr/local/lib/php.ini

# Temporarily set permissive mode for testing
$ sudo setenforce 0

If using PHP-FPM, remember to restart it separately:

$ sudo systemctl restart php-fpm
$ sudo systemctl restart httpd

Always verify changes using phpinfo() after making adjustments.