Php-fpm is it excluded from the stateless paradigm and not going to be overwritten by swupd?

Lets start with:

To modify system service configuration ( systemd (1) service units), the user should not touch or modify unit files under the /usr/ file structure directly, as changes in those files will be lost after a system software update with swupd (1).

The user should create configuration files as needed and avoid modifying distribution provided defaults.


“php’s default configuration file doesn’t allow us to provide an alternative as it is programmed to only read the builtin file.”

A user shouldn’t modify anything under /usr but php-fpm is programmed only to ready the built in file under /usr/share/defaults/php/php-fpm.conf

What about php.ini located /usr/share/defaults/php/php.ini assume same for php-fpm.conf ?

What else is valid, since php-fpm does’t allow Clear Linux to provide an alternative path, is php-fpm excluded and immune from being overwritten by swupd or will swupd treat php.ini and php-fpm.conf like everything else and overwrite php.ini?

Since we have to use the php.ini file to add extensions from php-extras bundle, can we safely modify php.ini in it’s default location /usr/share/defaults/php/php.ini. and not have to worry about swupd trashing the file?

Reading what user must do to use a different config contradicts the stateless paradigm because it requires the user TO MODIFY /usr/share/defaults/php/php-fpm.conf before copying it over to /etc

It makes little practical sense having swupd destroy default located php.ini, because every time php is updated and wipes out the php.ini file we’d have to continually run through the process of modifying the conf file and copying it over to /etc.

So who has an explanation to clarify the situation with php-fpm and the consequences of swupd?

You should be able to use a custom php.ini by copying it to /etc/php.ini and making modifications there that won’t get overwritten. It should automatically see /etc/php.ini and use it.

Not quite.Normally we modify applications to determine if a user-defined configuration exists under /etc and automatically choose to use that over the /usr defaults but in the case of php-fpm it has to be manually done.

The swupd page is suggesting you copy the php-fpm.conf file from /usr to an alternative location like /etc/php-fpm.conf, and modify the systemd service unit file (which will also get placed in /etc once modified using the method described) to have php-fpm read from your new alternative file.

It should automatically see /etc/php.ini and use it.

Doesn’t seem to on my system, file in /etc gets ignored.

After copying php.ini to etc i ran
sudo systemctl stop php-fpm
sudo systemctl stop nginx-mainline
sudo systemctl start php-fpm
sudo systemctl start nginx-mainline

Configure command does indeed have:


Maybe a system reboot is required?


I do think the actual default config needs to be modified to tell it where to look for the new location of the php.ini file, but again if that gets wiped out by swupd then same situation.

The best solution in the current state is to manually override the php-fpm.service unit and pass an explicit location to the custom php-fpm.conf file.

  • Run systemctl edit --full php-fpm.service
  • Change ExecStart so that it passes --fpm-config /etc/php/php-fpm.conf
  • Save&quit.

If it’s not reading php.ini from /etc it’s worth opening a bug report on GitHub.

It looks like it needs to be configured with --with-config-file-scan-dir to pick up alternate locations like /etc

$ php --ini
Configuration File (php.ini) Path: /usr/share/defaults/php/
Loaded Configuration File:         /usr/share/defaults/php/php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

@puneetse beware the difference between php and php-fpm here. php.ini is for php and php-cli. php-fpm.conf is the ini for php-fpm - they are not the same!

ah now thats a bit of information that’s otherwise faded into darkness.
So the php-fpm.conf is the ini for php-fpm
This is bizarre. because editing php.ini in

does actually change the config for php-fpm

Yes, but not all the config options are compatible, so, this is a little bit of an upstream mess. Partially the reason why every distro struggles with this.

right we need to sort this all out with some documentation to make these clarifications and some clear cut guide on how to add these extensions to php-fpm.

On this OS we’re expecting to be adding bundles php-basic and php-extras on nginx-mainline
This is PHP FPM/FastCGI and so we need be specifically referring to php-fpm conf files, php-fpm ini files and distinguishing between these and regular old php.ini php.conf etc

It is also important to understand that PHP configuration values can be set from a variety of places, not just php.ini.

Setting the value in one place may be more advantageous over the others depending on your usage and sharing of resources. As @ahkok mentioned not all values can be changed from all places however.

for some reason my system has always been using php.ini configuration file


I cant get this working I ran:
systemctl edit --full php-fpm.service

with all variations
Original ExecStart=/usr/sbin/php-fpm --nodaemonize
ExecStart=/usr/sbin/php-fpm --fpm-config /etc/php/php-fpm.conf
ExecStart=–fpm-config /etc/php/php-fpm.conf
ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf

fail to start php-fpm

/etc/systemd/system/php-fpm.service:7: Executable “-fpm-config” not found in path “/usr/local/bin:/usr/bin”, ignoring

Sep 14 05:01:41 host systemd[1]: php-fpm.service: Service has no ExecStart=, ExecStop=, or SuccessAction=. Refusing.

(CRON) STAT FAILED (/etc/cron.d): No such file or directory

(CRON) OPENDIR FAILED (/etc/cron.d): No such file or directory
php-fpm.service: Main process exited, code=exited, status=78/CONFIG

for now only thing working is editing

ill back up that php.ini file somewhere safe, run swupd then after system updated copy this file back to

my original php.ini looks something like this:

max_execution_time = 300
max_input_time = 3000
upload_max_filesize = 25M
post_max_size = 25M

This is not your fault.

I’m working on a packaging fix for this. In the meantime, a workaround is to set the environment variable export PHP_INI_SCAN_DIR=/etc/php.d to get php.ini to be read from /etc. You will need to set the environment variable in a place that your application sees it.

$ sudo mkdir -p /etc/php.d
$ sudo cp /usr/share/defaults/php/php.ini /etc/php.d/mycustomphp.ini
$ export PHP_INI_SCAN_DIR=/etc/php.d

$ php --ini
Configuration File (php.ini) Path: /usr/share/defaults/php/
Loaded Configuration File:         /usr/share/defaults/php/php.ini
Scan for additional .ini files in: /etc/php.d
Additional .ini files parsed:      /etc/php.d/mycustomphp.ini

1 Like

ok so what about the php-fpm.conf file that Auke mentioned was the .ini file for php-fpm?

Its strange my php.ini file contents look noting like the contents in php-fpm.conf

Is it possible the php.ini is purely for adding extensions to php and php-fpm?

(edited and left in the default location)

It’s expected they are different because they are configurations for two different programs.

php.ini sets configuration directives for PHP and extensions
php-fpm sets configuration for the process management/pools of worker bees, but it can optionally set some of the same php.ini values using

1 Like

CL version 31020 or newer will read php.ini configuration files (not php-fpm) from /etc/php.d/ as well.

1 Like

Thank you so much for efforts rectifying this issue. I can confirm for you as well now my system php is reading the php.ini file in /etc/php.d/. So happy now.