How to Find and Configure php.ini in PHP

By the end of this page, you will understand what php.ini is, how PHP decides which configuration file to load, how to locate the active configuration file, and how to enable a PHP extension such as ibm_db2. You will also learn the difference between CLI and web-server PHP configurations, common mistakes when editing php.ini, and a practical workflow for verifying that your changes actually took effect.

php.ini is PHP's main configuration file. It controls many parts of PHP's behavior, including:

• enabled extensions
• memory limits
• error reporting
• file upload size
• timezone settings
• session behavior

When you install a native extension such as ibm_db2.so, the compiled file does not become available automatically just because it exists on disk. PHP must be told to load it, usually through php.ini or an additional configuration file.

Why this matters

In real projects, PHP often runs in more than one environment on the same machine:

• the command line (php in a terminal)
• Apache with mod_php
• PHP-FPM behind Nginx or Apache

Each of these can use a different configuration file. That means:

• PHP may work in the terminal but not in the browser
• an extension may appear enabled in one place and missing in another
• editing the wrong php.ini can make it seem like nothing changed

So the important skill is not just "find a file called php.ini". The real concept is understanding how PHP loads configuration and how to verify which configuration file is active for the environment you are using.

Think of PHP like an application that checks for instructions when it starts.

• The PHP executable is the worker.
• php.ini is the instruction manual.
• Extension files like ibm_db2.so are plug-in tools.

Having ibm_db2.so on disk is like having a tool sitting in a toolbox. That does not mean the worker is using it. The worker first reads the instruction manual (php.ini) to learn which tools to load.

If there is no instruction manual in the expected place, PHP may:

• use built-in defaults
• look in another directory
• load extra .ini files from a scan directory

So the job is really:

1. Ask PHP where it reads its instructions.
2. Put the correct extension setting there.
3. Restart the process that uses PHP.
4. Verify that the extension is loaded.

How to find the active php.ini

The most reliable way is to ask PHP directly.

From the command line

php --ini

Typical output might look like:

Configuration File (php.ini) Path: /etc/php/8.2/cli
Loaded Configuration File:         /etc/php/8.2/cli/php.ini
Scan for additional .ini files in: /etc/php/8.2/cli/conf.d
Additional .ini files parsed:      /etc/php/8.2/cli/conf.d/20-opcache.ini

You can also run:

php -i | grep "Loaded Configuration File"

From a PHP script in the browser

Create a file such as info.php:

<?php
phpinfo();

Open it in the browser and look for:

• Loaded Configuration File
• Scan this dir for additional .ini files

How to enable an extension

If ibm_db2.so is already installed, you usually add a line like this to your configuration:

extension=ibm_db2

Sometimes an absolute path is used, though using extension_dir plus the module name is more common:

extension=/path/to/ibm_db2.so

You may also need to confirm that extension_dir points to the directory where the .so file exists:

extension_dir="/path/to/php/extensions"
extension=ibm_db2

Example workflow

php --ini
php -m | grep ibm_db2

If the module is not listed, edit the correct php.ini and add:

extension=ibm_db2

Then restart your web server or PHP-FPM, and check again:

php -m | grep ibm_db2

Consider this simple check script:

<?php
if (extension_loaded('ibm_db2')) {
    echo "ibm_db2 is loaded";
} else {
    echo "ibm_db2 is NOT loaded";
}

Here is what happens step by step:

1. PHP starts running the script.
2. Before the script executes, PHP loads its configuration.
3. PHP reads php.ini and any additional .ini files.
4. If one of those files contains extension=ibm_db2, PHP tries to load ibm_db2.so.
5. If the extension loads successfully, extension_loaded('ibm_db2') returns true.
6. The script prints:

ibm_db2 is loaded

If the extension is not configured correctly, one of these happens:

• PHP never tries to load it because no config entry exists
• PHP tries to load it but cannot find the file
• PHP finds the file but the extension is incompatible with the PHP version or architecture

In those cases, extension_loaded('ibm_db2') returns false, and the script prints:

ibm_db2 is NOT loaded

Traceable terminal workflow

php --ini

• Shows where PHP is looking for config.

php -m | grep ibm_db2

• Lists loaded modules and searches for ibm_db2.

php -i | grep extension_dir

• Shows the active extension directory.

After editing config:

php -m | grep ibm_db2

• Confirms whether the extension is now loaded.

This concept appears often in everyday PHP work.

1. Enabling database drivers

Examples:

• ibm_db2
• pdo_mysql
• mysqli
• pgsql
• sqlsrv

A project may fail simply because the required extension is installed but not enabled.

2. Turning on required features for frameworks

A framework or package may require extensions such as:

• mbstring
• intl
• curl
• openssl
• xml

Developers often need to check php.ini or a conf.d directory to make these available.

3. Debugging environment differences

Common issue:

• php artisan works in terminal
• web request fails in browser

Reason:

• CLI PHP and web PHP are using different configuration files

4. Server tuning

php.ini is also used for settings such as:

• memory_limit
• upload_max_filesize
• post_max_size
• display_errors
• date.timezone

So learning where it lives is useful beyond extension loading.

In real projects, developers usually do more than just edit php.ini once.

Common patterns

Environment verification

Teams often include setup steps such as:

php --ini
php -m
php -i

This helps confirm that the machine matches project requirements.

Guard checks in application startup

Projects sometimes verify extension availability early:

<?php
if (!extension_loaded('ibm_db2')) {
    die('The ibm_db2 extension is required.');
}

This is a guard clause: fail early with a clear message.

Separate configuration files

Many Linux distributions use:

• one main php.ini
• a conf.d directory with small extension-specific .ini files

Example:

; /etc/php/8.2/mods-available/ibm_db2.ini
extension=ibm_db2

This is cleaner than putting everything in one giant file.

Restart-after-change workflow

Developers know that editing config is not enough for web requests. They also restart the relevant service, for example:

sudo systemctl restart php8.2-fpm
sudo systemctl restart apache2

Exactly which service to restart depends on the server setup.

Validation after deployment

After changes, developers validate using both:

• terminal checks like php -m
• browser checks like phpinfo() or a health endpoint

That avoids confusion between CLI and web environments.

1. Editing the wrong php.ini

A very common mistake is editing the CLI config when the problem is in Apache or PHP-FPM.

Broken assumption

php --ini

This shows the CLI configuration, not necessarily the one used by your web server.

How to avoid it

• Use phpinfo() in a browser for web requests.
• Use php --ini for terminal scripts.
• Treat them as possibly different environments.

2. Assuming no php.ini means PHP is broken

PHP can still run even if no php.ini is loaded. It may use built-in defaults or scan additional config files.

How to avoid it

Check actual loaded config with:

php --ini

3. Using the wrong extension path

Broken example

extension=/wrong/path/ibm_db2.so

If the file does not exist there, PHP cannot load it.

Better approach

extension=ibm_db2

and verify extension_dir separately.

4. Forgetting to restart the web server or PHP-FPM

If you edit config for web requests, the running service may still use old settings.

How to avoid it

Restart the relevant service after changes.

5. Mixing version-specific files

A module compiled for one PHP version may not work with another.

Symptom

• warning during startup
• extension not listed in php -m

How to avoid it

Make sure:

• the extension was built for the same PHP version
• architecture matches
• thread-safety requirements match where relevant

6. Expecting make install to enable the extension automatically

Installing the .so file usually only places it on disk.

How to avoid it

Always verify both:

• the file exists
• PHP is configured to load it

php.ini vs phpinfo() vs php --ini

Main file vs additional .ini file

If your system supports a scanned config directory, enabling an extension in a separate file is often cleaner.

Example:

; ibm_db2.ini
extension=ibm_db2

This is often easier to manage than editing a large php.ini directly.

Quick commands

php --ini
php -i | grep "Loaded Configuration File"
php -i | grep extension_dir
php -m | grep ibm_db2

Browser check

<?php
phpinfo();

Look for:

• Loaded Configuration File
• Scan this dir for additional .ini files
• extension_dir

Enable an extension

extension=ibm_db2

Or with full path:

extension=/full/path/to/ibm_db2.so

Typical workflow

1. Find active config with php --ini or phpinfo().
2. Confirm where ibm_db2.so is installed.
3. Add extension=ibm_db2 to the correct config file.
4. Restart Apache or PHP-FPM if needed.
5. Verify with php -m or extension_loaded().

Important rules

• CLI and web PHP may use different config files.
• No loaded php.ini does not always mean PHP is unusable.
• Installing an extension file is not the same as enabling it.
• Restart services after web configuration changes.
• Verify changes instead of assuming they worked.

How do I know which php.ini PHP is using?

Use php --ini for the command line, or create a page with phpinfo() for the web server.

What if PHP says no php.ini is loaded?

PHP can still run with default settings or additional scanned .ini files. You can usually create a php.ini in the expected configuration path or use the scanned config directory.

Can there be more than one php.ini file on a system?

Yes. Different SAPIs such as CLI, Apache, and PHP-FPM can each use different configuration files.

Do I need to use the full path to ibm_db2.so?

Not always. If extension_dir is set correctly, extension=ibm_db2 is usually enough.

Why does the extension work in terminal but not in the browser?

The CLI and web server are probably using different PHP configurations.

Do I need to restart anything after editing php.ini?

For web requests, usually yes. Restart Apache or PHP-FPM. For CLI commands, no persistent service restart is usually needed.

How can I check whether ibm_db2 is enabled?

Run php -m | grep ibm_db2 or use extension_loaded('ibm_db2') in a PHP script.

Is editing php.ini the only way to enable an extension?

No. Many systems use separate .ini files in a scanned directory such as conf.d. That often achieves the same result more cleanly.

• PHP extensions — Extensions add compiled functionality such as database drivers and must be enabled in configuration.
• phpinfo() — Useful for discovering the active configuration file and loaded modules in web requests.
• PHP-FPM — A common PHP runtime for web servers that often uses its own configuration path.
• Apache mod_php — Another way PHP runs under Apache, with its own configuration context.
• CLI vs web environment — Important because PHP settings can differ between terminal and browser execution.
• extension_dir — This setting determines where PHP looks for extension files.
• Shared libraries (.so) — Native extension files on Unix-like systems are typically shared objects.
• Environment configuration — Understanding how apps load configuration is a core programming and deployment skill.