PHP 8.0 command line ignoring php.ini in FreeBSD 13.1 Jail

Setup - this issue is occurring in a FreeBSD jail on a TrueNAS system. While the host is TrueNAS, the issue is happening purely within a FreeBSD environment (the Jail).

I have a Jail running FreeBSD 13.1, running Caddy as a webserver, PHP 8.0, and Nextcloud. The jail was generated from a script (linked below), which then installed all of the packages and copied the appropriate INI files for PHP to run. So far, so good - Nextcloud runs, PHP seems fine, and when I check the system settings from within Nextcloud, I can see it's honoring php.ini and using the correct settings (Memory Limit being the main one).

However, when running PHP commands from the command line, it seems like PHP is ignoring, or not using, the values it uses for the web version. Specifically, two values of note are being ignored - memory_limit, and apc.enable_cli, are set in php.ini and appear to be honored when checked from within Nextcloud, but not from the command line. This is noted when running either the CRON task for scheduled maintenance (apc.emable.cli is ignored), or running Nextcloud's updater from the command line (memory_limit is ignored).

I googled the issue, and found several threads that were 5+ years old with similar symptoms, but none of the solutions provided here apply. In this case, there are no other ini files that have memory_limit set when I grep for it.

Any idea what I may be missing, that the command line is either ignoring, missing, or being overridden for php.ini as comparted to the web version?

Thank you!
 
did you check php -h and php --ini

Also check what is default path of the php.ini and try to manually point it via "-c" for the jail and test it with php -i
For more information read the following link:
 
Thank you for your help! I ran php --ini, and it seems to be pointing to the correct ini file ( /usr/local/etc/php.ini ). There's a list of other ini's that are parsed, but upon greping them, none of them set the memory limit. The output from php --ini also lists memory_limit as 512M, which is the desired value. So that all seems good.

I may be looking at this from the wrong angle - PHP may be working properly, it may be the settings for Nextcloud that are calling / causing the environmental issues. I'm still new to this sort of thing, so I could use guidance on how to check if the Nextcloud scripts are calling / using different settings?
 
you mean using php -i | grep memory show the correct settings from php.ini

Correct. php -i | grep memory shows the result memory_limit => 512M => 512M

But when I run the command sudo -u www php /usr/local/www/nextcloud/updater/updater.phar I see the following error;

[ ] Verify integrity ...PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 150601528 bytes) in phar:///usr/local/www/nextcloud/updater/updater.phar/lib/Updater.php

Commands run from the Command Line do not seem to be using the Memory Limit specified in php.ini, and are using 128M instead.
 
Similarly, when I run:

root@nextcloud:~ # sudo -u #80 php --define apc.enable_cli=1 /usr/local/www/nextcloud/occ maintenance:repair

I get the warning:

The current PHP memory limit is below the recommended value of 512MB.

Note that I need to specify --define apc.enable_cli=1 in the command because it is not using the setting that is defined in php.ini, either.
 
What are the permissions and ownership of /usr/local/etc/php.ini?

root@nextcloud:/usr/local/etc # ls -l php.ini
-rwxr-x--- 1 root wheel 30456 May 26 20:42 php.ini


Of note, when viewing System Info from the Nextcloud Web GUI, I see the following:

Version: 8.0.18
Memory Limit: 512 MB
Max Execution Time: 3600
Upload max size: 16 GB
 
Good catch SirDice
if the php.ini is with 600 permission only php started as root can read it. If the php is started as other user like www then php.ini it can't be read and the default of 128M memory limit is applied. The default permission of php.ini is 644 root:wheel
 
That looks like it solved it! The script that called / created the jail may not be applying the correct permissions. Thank you SO MUCH for all of your help! I'll pass this back to the TrueNAS community to make sure it's share there as well.
 
Back
Top