Message "PHP memory limit below recommended value of 512 MB" won't vanish/Die Meldung "PHP-Speichergrenze liegt unterhalb des empfohlenen Wertes von 512MB." verschwindet nicht!

'GERMAN VERSION (english below)'

System configuration notes:

Nextcloud version (eg, 12.0.2): 16.0.3
Operating system and version (eg, Ubuntu 17.04): Raspbian GNU/Linux 10 (buster)
Apache or nginx version (eg, Apache 2.4.25): nginx/1.14.2
PHP version (eg, 7.1): 7.3

The issue you are facing:

Unter /settings/admin/overview#version wird folgende Fehlermeldung angezeigt:

'Die PHP-Speichergrenze liegt unterhalb des empfohlenen Wertes von 512MB.'

Is this the first time you’ve seen this error? (Y/N): Y

Hintergrund
Ich habe sowohl php7.3-fpm wie auch php7.3-cli installiert, in beiden zum Paket gehördenden Ordnern habe ich eine php.ini. Mir war aufgefallen, dass in der php.ini im Ordner /etc/php/7.3/cli bei memory_limit der Wert ‚-1‘ eingetragen war. Soweit ich weiß, beudetet das unbegrenzt, also insbesondere nicht < 512MB. Habe dann trotzdem folgendes gemacht:

Folgende Schritte habe ich unternommen, um das Problem zu lösen:

1.) In der Datei /etc/php/7.3/fpm/php.ini setze memory_limit = 512M
2.) In der Datei /etc/php/7.3/cli/php.ini setze memory_limit = 512M (war vorher auf 128M)
3.) sudo systemctl restart php7.3-fpm.service
4.) sudo service nginx restart
5.) sudo service nginx reload (äquivalent zu 4.)?)

Wenn ich aber über den Browser nach den Warnmeldungen für ein Update von Nextcloud 16.0.3 auf 16.0.4 schaue, dann ist die Warnung für die PHP-Speichergrenze immer noch nicht verschwunden! Hat jemand eine Ahnung was ich in diesem Fall tun kann?

Den Thread PHP-Speicherproblem habe ich gelesen, da ich aber keine GUI oder ähnliches in meinem Raspberry verwende, bringt mir dieser Lösungsvorschlag herzlich wenig. Ich wüsste nicht einmal wie ich zu diesem Fenster komme!

Vielen Dank schon mal für eure Hilfe!

Viele Grüße,
fly

'ENGLISH VERSION (german above)'

System configuration notes:

Nextcloud version (eg, 12.0.2): 16.0.3
Operating system and version (eg, Ubuntu 17.04): Raspbian GNU/Linux 10 (buster)
Apache or nginx version (eg, Apache 2.4.25): nginx/1.14.2
PHP version (eg, 7.1): 7.3

The issue you are facing:

The following error message is displayed under /settings/admin/overview#version:

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

Is this the first time you’ve seen this error? (Y/N): Y

**Background
I have installed both php7.3-fpm and php7.3-cli, in both folders belonging to the package I have a php.ini. I noticed that in the php.ini folder /etc/php/7.3/cli the value ‘-1’ was entered in memory_limit. As far as I know, this means unlimited, especially not < 512MB. I did the following anyway:

I have taken the following steps to solve the problem:

1.) /etc/php/7.3/fpm/php.ini -> memory_limit = 512M
2.) /etc/php/7.3/cli/php.ini -> memory_limit = 512M (was previously 128M)
3.) sudo systemctl restart php7.3-fpm.service
4.) sudo service nginx restart
5.) sudo service nginx reload (equivalent to 4.)?)

But when I look through the browser for the warning messages for an update from Nextcloud 16.0.3 to 16.0.4, the warning for the PHP memory limit has still not disappeared! Does anyone have any idea what I can do in this case?

I’ve read the thread PHP memory problem, but since I don’t use a GUI or similar in my Raspberry, this solution doesn’t help me much. I don’t even know how to get to this window!

Thank you very much for your help!

Many greetings,
fly

Hi,

And are these files the only ones containing the memory_limit?
Could you run the following command, just to be sure?

grep -R "memory_limit" /etc/php*/*
2 Likes

Hey Schmu,

thank you very much, that command leads me to a solution. I have had a third file containing memory_limit. It was that one i’ve downloaded when i set up my php installation based on a tutorial I’ve found at this page. This special file was not referenced by others that don’t use the same tutorial.

Really nice, thank you! I have also one other problem but i will open another thread for that!

Have a nice sunday!

Greatings fly

1 Like

It is btw nice to have custom settings in an own “mod”, e.g.

cat << _EOF_ > /etc/php/7.3/mods-available/memory_limit.ini
; Raising memory limit
; priority=99
memory_limit=512M
_EOF_
phpenmod memory_limit

This allows to keep php.ini untouched, so that APT/DPkg can update defaults silently and allows better tracking of custom config changes. priority=99 will make this mod override all other settings. It is applied for all available usage types: cli/fpm/cgi/apache2 etc, phpenmod creates a symlink at all /etc/php/7.3/*/conf.d/99-memory_limit.ini locations.

3 Likes

Hey Michalng,

thank you very much for your support. I’m really new in that kind of materia (php, nginx, nextcloud, etc.). Could you explain what the code does exactly do and what does the lines mean? I would like to study more around php, therefore it would be great!

Kindly Regards!

fly

About the command and syntax:

  • cat is a tool to usually print the content of one file, or concatenates the contents of multiple files to the console. But you can also use it to write content to files.
  • <<” is shell syntax to stream a so called here document to the command, which replaces the file path that cat usually expects.
  • _EOF_ is a free choosable string which marks the end of the here document, so all lines between the command and _EOF_ are taken mostly literally as content.
  • >” is shell syntax to forward the commands output, in this case to the file /etc/php/7.3/mods-available/memory_limit.ini. Without this, the content would be printed to console.

What the file + phpenmod does:

  • /etc/php/7.3/mods-available is the directory where module load- and config files for PHP7.3 are stored. But one can also use it to manage custom settings.
  • The files in there in the first place have no effect, but phpenmod, used to enable PHP modules, creates symlinks to those files inside all /etc/php/7.3/*/conf.d directories.
  • /etc/php/7.3/*/conf.d is the usual place where drop-in configs are stored, which are parsed in alphabetical order after the php.ini in their parent dir. So finally phpenmod does nothing else then adding additional settings, respectively overriding existing ones, to all kinds of PHP calls.
  • ;” inside PHP config files is comment syntax, so lines starting with this character have no effect. Only for phpenmod lines like “; priority=<int>” are parsed to prefix the related symlink file name with the given integer. Since those files are parsed in alphabetical order, is has the effect that files with a higher number are parsed later, thus contained settings will override the ones with lower priority.

So as a result, running the above command set will apply memory_limit=512M to all kind of PHP calls, regardless is run from command line, Apache2, Nginx/Lighttpd (usually php-from), cgi or anything else.

Running phpdismod memory_limit will remove the symlinks, thus disable the settings again.

Managing your custom settings like this allows you to easily test and debug those, without loosing the defaults from php.ini.
And one can easily copy those “modules” to any other PHP instance/system and again apply them there without having to take care multiple php.ini files, also when you do changes, avoiding the need to do the same on multiple files.
And last but not least, usually APT upgrades will not update any config files that were manually changed. So if you edit php.ini, and some larger PHP package upgrade would apply a new one, this will be skipped, or at least you will be asked during install what to do. In some cases, where config files contain requires syntax or settings changes, keeping the old one can break things.

When you go through directories inside /etc, you will often see such, ending with .d, which is then the place for drop-in configs. This has become a usual recommended way to apply custom settings throughout UNIX systems due to the mentioned benefits.

1 Like

Hey MichaIng,

wow, thank you very much for the detailed explanation behind the code you’ve posted. I also have read the wiki article for the here document. After i’v read the following part, one question occure:

What does free choosable string in that context mean? For Debian Buster is _EOF_ the delimiting identifier or is it only an example for one possible delimiting identifier under Debian?

In generall i’m thinking about if this new informations effect other manipulations i’v made. If i will administrate configuration settings in this way, it should be better to handle other changes similar, or? For example i have implemented an APCu based local memory cache. Therefore i have also changed a handfull lines of code belongs to opcache-settings in the ini-files. Can i handle it the same way? I need for that an extra file or can i also write it to the same file as for the memory_limit and save it under another name. I’m not sure, what’s the better way!

Kindly Regards :slightly_smiling_face:

fly

You can choose any delimiter/end-mark you want, so this works as well:

cat << I_am_bored_while_coding > file
Write
lines
to
file
until
I_am_bored_while_coding

EOF or _EOF_ (End Of File) is just what most coders use.

it should be better to handle other changes similar

Jep, I personally have a “mod” called micha.ini which contains all custom settings I need. Just note that e.g. OPcache settings require the OPcache module to be enabled etc of course, otherwise PHP will fail to start.

Another approach is to add module-specific settings to the related module ini (so opcache settings to /etc/php/7.3/mods-available/opcache.ini etc). This has another advantage that the settings are added/removed together with the module call itself and no failure can happen. And those files will most probably never change package-wise, since they all contain the module call command only, without any settings, AFAIK.
On the other hand, if you apply certain settings, you most likely need the module, so instead of having the settings ignored silently, a failure with meaningful error output is probably not bad, as you will recognise if something is missing in the first place :wink:.

  • E.g. Nextcloud can run without OPcache, just performance will be bad. If APCu is disabled, but Nextcloud configured to use it, webserver and PHP will start without error, but opening web UI will throw internal server error 500, without any hint that it is due to missing APCu module. So I prefer to have a failing webserver/PHP in the first place :wink:.
1 Like

Sorry, but i didn’t know if i really understand that hint! Are phpenmod lines only those who begin with priority? What will happen if i remove the ; at the beginning of the line?

Can you tell me please, why i need the symlinks or the system uses the symlinks?

Ok, thank you, i got it! It’s a better explanation as in the wiki article.

Oh i know. Give it a first try to implement APCu memcache.local, i’ve forget to install the related package and run in an server error when i start to load my cloud-domain from a webbrowser.:expressionless:

Greetings,

fly

priority” is no valid PHP setting, thus if you uncomment the line (remove “;”) you will get a syntax error. This, commented, is only read by phpenmod to prefix the symlink.

Can you tell me please, why i need the symlinks or the system uses the symlinks?

As said, /etc/php/7.3/mods-available content is not read by the PHP binaries themselves. They only read the contents of /etc/php/7.3/*/conf.d. Using symlinks to add/remove optional settings/modules is just a common simple but effective method on UNIX/Linux derivatives. You can compare this with many other software:

  • Apache has optional modules/config snippets/vhost configs in /etc/apache2/mods-available|conf-available|sites-available. Those are not read by the Apache binaries. But when you use a2enmod/a2enconf/a2ensite, a symlink will be created to /etc/apache2/mods-enabled|conf-enabled|sites-enabled, the locations which are read by Apache binaries, as defined in the /etc/apache2/apache.conf again via Include/IncludeOptional directives.

  • Or the sysvinit service handling. sysvinit services are stored in /etc/init.d/. But simply storing a service file there will have no effect. One must run update-rc.d <service_name> enable, which will place symlinks to /etc/rc*.d/. The way and which symlinks are placed, depends on a section at the top of the service files, e.g.:

    ### BEGIN INIT INFO
    # Provides:          dropbear
    # Required-Start:    $remote_fs $syslog
    # Required-Stop:     $remote_fs $syslog
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # Short-Description: Lightweight SSH server
    # Description:       Init script for drobpear SSH server.  Edit
    #                    /etc/default/dropbear to configure the server.
    ### END INIT INFO
    
  • Default-Start/Default-Stop define which symlinks are added and their prefix, so declare which system run levels will start the service and which will stop it. But this section is actually commented. So when executing/starting/stopping the service, the shell will ignore it.

  • systemd does the same with its services. Most services are stored in /lib/systemd/system/, but when being enabled, symlinks are created in /etc/systemd/system/*.wants/ from where they are called when certain system states/targets are reached on boot.

This is actually something I like very much about Linux derivatives. The way how things are handled down until the binary level, is in most cases very transparent and follows mostly the same effective methods which one can control and apply manually via simple shell commands. I mean those meta/helper commands are shell scripts themselves: nano $(which phpenmod)
You can see where/how the symlinks are created and removed by this script, you can even find how the package install/upgrade scripts call it to enable default modules, as long as you did not manually disable them, instead prints a bunch of annoying notifications (as I have most default modules disabled, besides the ones required for Nextcloud) :laughing:.