-
Notifications
You must be signed in to change notification settings - Fork 18
Execution modes
This page describes the different execution modes for composer operations within the composer-client, especially the detached mode. The mode can be changed in the Contao back end under System » Settings » Composer settings » Execution mode.
This is the default mode. The composer operations are executed within the same process where your back end PHP script is executed. This means the composer operation is limited by the same PHP environment as the Contao installation itself. If the composer operation uses a lot of memory or takes a lot of time (depending on your requirements) you may run into your respective memory_limit or max_execution_time resulting in a failed composer operation and possibly a broken website afterwards.
In this mode the composer operation is spawned as its own process within the web server's PHP process. The same memory_limit and max_execution_time still applies, though the available time and memory may have improved a little bit.
The detached mode is what you should aim for. In this mode the composer operation is spawned as a completely independent process (at least under Linux). When doing a package update, the composer-client spawns this process and refreshes the output that the composer operation produces in one second intervals.
In this mode, the composer operation directly uses the PHP command line interface and thus there usually will be no memory_limit and no max_execution_time. However, certain hosters may still impose limits for the command line interface environment of PHP.
When enabling the detached mode, you are presented with a new option: PHP Path/Command. The default value is
/usr/bin/env php -d memory_limit=1G -d max_execution_time=900
This means that the composer-client tries to obtain the globally available php executable path, which get's determined by /usr/bin/env, and it tries to override the memory_limit and max_execution_time settings via command parameters.
You may need to customize these values depending on your hosting environment. For instance, the globally available php executable (if at all available in the first place) might be an older version and thus you need to find out where a more appropriate version (for PHP 5.6 or 7.0 for example) is available. In a shared hosting environment, you will probably have to contact the support of your hoster for that.
Also the default setting imposes a memory_limit of 1G. Nowadays composer operations (more precisely the dependency resolving part) are known to exceed that. So you should set it to 4G or -1 (unlimited) or remove -d memory_limit=1G altogether. If you remove the memory_limit or max_execution_time parameters, the default limits will apply - these limits could be infinite or something else.
Since the PHP executable of the detached mode might be a different version than that of your web server, it is recommended to define the desired platform in your /composer/composer.json. To do that, simply add:
"platform": {
"php": "5.6.26"
}
to the "config" part and replace 5.6.26 with the exact (or at least minor version) of your web server's PHP version.
Some packages offer shell access, however reports suggest that even via the shell a fairly low, dynamic memory_limit is applied. As mentioned in community.1und1.de/php-composer-bei-1und1-verwenden and community.1und1.de/php-7/#comment-154894 Shared Hosting Packages only have PHP5.5-CLI available on the shell.
PHP command line interfaces are available at this location:
/usr/bin/php5.5-cli
/usr/bin/php7.1-cli
However, a dynamic memory_limit may still apply. Depending on your hosting package, you might be able to connect via SSH and do the composer update manually.
PHP CLI binaries are available here:
/usr/bin/php5.6
/usr/bin/php7.0
/usr/bin/php7.1
However, reports suggest that a low memory_limit of 128M still applies and you need to override it manually, e.g.:
/usr/bin/php7.1 -d memory_limit=2G -d max_execution_time=900
The PHP executables for all available versions are located in /usr/bin where /usr/bin/php seems to default to the lowest PHP version available. For PHP 5.6 for example, you can use
/usr/bin/php56
as the PHP Path/Command. Lower versions are also available, but will soon be removed. Also available is
/usr/bin/php70
for example.
You can use
php5.6.12-cli
for example as the PHP Path/Command. However, reports suggest that even then a dynamic memory_limit might apply (see here for example). You can still perform the composer update manually directly via SSH though, using the same PHP executable, e.g.
php5.6.12-cli composer.phar update
In this case no memory_limit will apply.
Unfortunately the detached mode cannot be used here, since easyname has disabled vital functions like posix_kill (see this thread for more information). The composer-client will therefore revert to the inline mode. However, easyname offers SSH access, so you can still do composer updates manually.
/usr/bin/php (newest), otherwise /usr/bin/php56 for example.
Paths to the PHP executables can be taken from www.hosteurope.de/faq/webhosting/skripte/skript-pfadangaben/. Example for the PHP path:
/usr/bin/php7.1
/usr/bin/php-5.6
/usr/bin/php-7.1
Reports suggest it is advisable to use the following parameters:
/usr/bin/php-7.1 -d memory_limit=-1 -d max_execution_time=900
PHP path: /usr/local/php{major}{minor}/bin/php
Set the composerPhpPath in the system settings to
/usr/local/bin/php_cli
Paths to the PHP executables can be taken from https://www.netcup-wiki.de/wiki/Shell_verschiedene_PHP-Versionen. Attention, PHP 5.3 is set on the shell by default.
Set the composerPhpPath in the system settings to
/usr/local/php56/bin/php
Paths to the PHP CLI can be found here:
/opt/RZphp{major}{minor}/bin/php-cli
Paths to the PHP CLI can be found here:
/usr/bin/php{major}.{minor}
PHP path: /usr/bin/php{major}