php extensions priority gets written into ini file with every puppet run which results into a service restart

[vmpr]

Hi everyone and thanks for the great work on the PHP module!

we have a strange problem with priorities and PHP extensions, For example, I would like to install the pdo extension and it needs to have a prefix 10 instead of the standard 20. It seems fairly easy, to use the "; priority' setting. But now with every puppet run the module adds a new line "; priority = 10" to my .ini file ( /etc/php/8.1/mods-available/pdo.ini ) as a result, puppet restarts the php-fpm every 30 minutes while running, which causes Problems for the application. Does anybody know how to avoid that?

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 7.34.0
• Distribution: Debian 11
• Module version: 10.1.0

How to reproduce (e.g Puppet code you use)

Our configuration in Hiera:

php::extensions:
  pdo:
    package_name: 'php8.1-common'
    settings:
      '; priority': 10

What are you seeing

every puppet run the module adds another line:

# cat /etc/php/8.1/mods-available/pdo.ini
extension = pdo.so
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
...

and restarts the php-fpm which causes unavailability for the application

Notice: /Stage[main]/Php/Php::Extension[pdo]/Php::Extension::Config[pdo]/Php::Config[pdo]/Php::Config::Setting[/etc/php/8.1/mods-available/pdo.ini: ; priority]/Ini_setting[/etc/php/8.1/mods-available/pdo.ini: ; priority]/ensure: created (corrective)
Info: Php::Extension[pdo]: Scheduling refresh of Service[php8.1-fpm]

Notice: /Stage[main]/Php::Fpm::Service/Service[php8.1-fpm]: Triggered 'refresh' from ...

What behaviour did you expect instead

puppet runs once and writes the .ini file, the next time puppets is running it will not change the .ini file and also not restart php-fpm

[vmpr]

can anybody help? we still have the problem :(

[yakatz]

I haven't looked at your question in too much detail yet, but Puppet 6 is no longer supported, so it is unlikely anyone could help if that is why it isn't working.

[vmpr]

I haven't looked at your question in too much detail yet, but Puppet 6 is no longer supported, so it is unlikely anyone could help if that is why it isn't working.

Thanks for your answer @yakatz ! It was Puppet 6 back in April, but now we are using puppet7, so it's not a Puppet version-related problem. The problem is that the module code writes the correct configuration on the first run:

# cat /etc/php/8.1/mods-available/pdo.ini
extension = pdo.so
; priority = 10

but then on the next run, it doesn't recognise that there is already a line with ; priority = 10 in the config file and writes the same line again in the file plus restarts the whole php-fpm service, because of the config change, which results in service interruption every 30 minutes when puppet runs :(

After some runs the files look like that and today I deleted the files with 10000 lines each

# cat /etc/php/8.1/mods-available/pdo.ini
extension = pdo.so
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10
; priority = 10

If I knew how to fix it in the code, I would contribute, but I need help finding the problem.

It only happens when we use the priority as a setting for the PHP module:

php::extensions:
  pdo:
    package_name: 'php8.1-common'
    settings:
      '; priority': 10

[yakatz]

I looked into it:
This can't work with the current module implementation. This works because it is a comment as far as PHP is concerned, but the Debian symlink tool reads that comment to change the name of the symlink. The puppet module uses the ini_setting resource from puppetlabs-inifile to manage this file. It appears (rightly) that a key starting with a semicolon is not a valid key for ini_setting because by definition such an entry in the config file is ignored, so ini_setting puts it back. The only options I can think of would be to add priority management to the module or use a different ini building tool that supports this use.