PHP Warning: proc_open(): fork failed

[pdewouters]

Similar to https://github.com/humanmade/backupwordpress/issues/997 ?

[08-Mar-2016 12:06:37 UTC] PHP Warning:  proc_open(): fork failed - Cannot allocate memory in /srv/www/wordpress-default/wp-content/plugins/backupwordpress/vendor/symfony/process/Process.php on line 290
[08-Mar-2016 12:06:37 UTC] PHP Stack trace:
[08-Mar-2016 12:06:37 UTC] PHP   1. {main}() /srv/www/wordpress-default/wp-admin/admin-ajax.php:0
[08-Mar-2016 12:06:37 UTC] PHP   2. do_action($tag = 'admin_init', $arg = *uninitialized*) /srv/www/wordpress-default/wp-admin/admin-ajax.php:44
[08-Mar-2016 12:06:37 UTC] PHP   3. call_user_func_array:{/srv/www/wordpress-default/wp-includes/plugin.php:525}('HM\\BackUpWordPress\\set_server_config_notices', array (0 => '')) /srv/www/wordpress-default/wp-includes/plugin.php:525
[08-Mar-2016 12:06:37 UTC] PHP   4. HM\BackUpWordPress\set_server_config_notices('') /srv/www/wordpress-default/wp-includes/plugin.php:525
[08-Mar-2016 12:06:37 UTC] PHP   5. HM\BackUpWordPress\Requirement_Mysqldump_Command_Path::test() /srv/www/wordpress-default/wp-content/plugins/backupwordpress/functions/interface.php:190
[08-Mar-2016 12:06:37 UTC] PHP   6. HM\BackUpWordPress\Mysqldump_Database_Backup_Engine->get_mysqldump_executable_path() /srv/www/wordpress-default/wp-content/plugins/backupwordpress/classes/class-requirement.php:127
[08-Mar-2016 12:06:37 UTC] PHP   7. HM\BackUpWordPress\Backup_Utilities::get_executable_path($paths = array (0 => 'mysqldump', 1 => '/usr/local/bin/mysqldump', 2 => '/usr/local/mysql/bin/mysqldump', 3 => '/usr/mysql/bin/mysqldump', 4 => '/usr/bin/mysqldump', 5 => '/opt/local/lib/mysql6/bin/mysqldump', 6 => '/opt/local/lib/mysql5/bin/mysqldump', 7 => '/opt/local/lib/mysql4/bin/mysqldump', 8 => '/xampp/mysql/bin/mysqldump', 9 => '/Program Files/xampp/mysql/bin/mysqldump', 10 => '/Program Files/MySQL/MySQL Server 6.0/bin/mysqldump', 11 => '/Program Files/MySQL/MySQL Server 5.7/bin/mysqldump', 12 => '/Program Files/MySQL/MySQL Server 5.6/bin/mysqldump', 13 => '/Program Files/MySQL/MySQL Server 5.5/bin/mysqldump', 14 => '/Program Files/MySQL/MySQL Server 5.4/bin/mysqldump', 15 => '/Program Files/MySQL/MySQL Server 5.1/bin/mysqldump', 16 => '/Program Files/MySQL/MySQL Server 5.0/bin/mysqldump', 17 => '/Program Files/MySQL/MySQL Server 4.1/bin/mysqldump', 18 => '/opt/local/bin/mysqldump')) /srv/www/wordpress-default/wp-content/plugins/backupwordpress/classes/backup/class-backup-engine-database-mysqldump.php:73
[08-Mar-2016 12:06:37 UTC] PHP   8. Symfony\Component\Process\Process->run($callback = *uninitialized*) /srv/www/wordpress-default/wp-content/plugins/backupwordpress/classes/backup/class-backup-utilities.php:57
[08-Mar-2016 12:06:37 UTC] PHP   9. Symfony\Component\Process\Process->start($callback = NULL) /srv/www/wordpress-default/wp-content/plugins/backupwordpress/vendor/symfony/process/Process.php:201
[08-Mar-2016 12:06:37 UTC] PHP  10. proc_open('mysqldump --version', array (0 => array (0 => 'pipe', 1 => 'r'), 1 => array (0 => 'pipe', 1 => 'w'), 2 => array (0 => 'pipe', 1 => 'w')), array (), '/srv/www/wordpress-default/wp-admin', NULL, array ('suppress_errors' => TRUE, 'binary_pipes' => TRUE)) /srv/www/wordpress-default/wp-content/plugins/backupwordpress/vendor/symfony/process/Process.php:290

[willmot]

Ultimately this is because the machine itself is running out of memory. There's no way to fix this from within the PHP script other than generally trying to reduce our memory usage.

side note it would be useful to profile our memory usage to make sure it's at least sane.

Looking at some other projects:

Composer solved by adding a troubleshooting doc to cover that error: https://github.com/composer/composer/pull/2748

Varying Vagrant Vagrants specifically upped their memory usage in response to this. Salty WordPress also runs with 1024MB of memory.

Some possible actions here:

1. Profile our memory usage, are there things we could reasonably do to reduce it?
2. Catch & silence this error, the plugin will just fallback to ZipArchive anyway.
3. Specifically catch and provide a useful error message with a link to a doc explaining that they should try upping their system memory.

I don't think 3 is useful, in practise very few people can control the amount of memory their server has. Also this is often just a transient issue as it depends on the system memory already being low (assuming we're not using that much memory ourselves).

I vote we do some profiling to check we're not being a bad citizen when it comes to memory usage and then silence this error and quietly fallback to ZipArchive.

[pdewouters]

Yeah, I thought so. I was running another resource intensive process. One thing we could do is make sure we don't run several backups at the same time.

[willmot]

One thing we could do is make sure we don't run several backups at the same time.

Yeah definitely. We already default to setting the default schedules to different time. Perhaps we could make it clearer when someone is creating a new schedule that one of their existing schedules is already running at the time they've specified.

[willmot]

I ran some testing in low memory environments and was successfully able to complete a backup even with a memory_limit = 16MB. We don't have a memory problem.

Given we'll just fallback to ZipArchive whenever this happens I'm going to close.

Since https://github.com/humanmade/backupwordpress/commit/b2532e1fb464a42a313262396b399c1ef6232577 we no longer surface errors from failed backup engines if a subsequent engine succeeds so this error won't even show any more.

@pdewouters Just realised I accidentally committed https://github.com/humanmade/backupwordpress/commit/b2532e1fb464a42a313262396b399c1ef6232577 directly to master, fancy giving it a quick post-review :-)

[pdewouters]

just had this pop up on my local on master

[willmot]

We shouldn't be seeing this error anymore since https://github.com/humanmade/backupwordpress/commit/b2532e1fb464a42a313262396b399c1ef6232577

[JJJ]

I'm seeing this again when trying to run phpunit without any groups or limitations in place. It always runs out at exactly the same spot, so it's also plausible something in the WordPress tests can be further optimized.

[sibbu2005]

https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors This could be happening because the VPS runs out of memory and has no Swap space enabled.

free -m

total used free shared buffers cached
Mem: 2048 357 1690 0 0 237
-/+ buffers/cache: 119 1928
Swap: 0 0 0

To enable the swap you can use for example:

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1

then update composer