I attempted to install Drush 7 using the "manual install" instructions, and the "composer install" step failed with the error that the ext-pcntl PHP extension was not found. The hosting company (which I don't have control over choosing) says they are unwilling to install ext-pcntl in a production environment due to security concerns. Are such security concerns justified? Is there any workaround for installing Drush 7 without the ext-pcntl dependency? If not, I might try to install an older Drush version that doesn't have the dependency.

2 Answers 2


Are such security concerns justified?

Given the description on extension's introduction page, yes:

Process Control support in PHP implements the Unix style of process creation, program execution, signal handling and process termination. Process Control should not be enabled within a web server environment and unexpected results may happen if any Process Control functions are used within a web server environment.

Emphasis mine.

But also no, because, as greg_1_anderson stated in his answer, it can be enabled (or even compiled) into CLI only.

Then again, it might be yes. With functions like pcntl_fork it might be possible to make a fork bomb. Other bad things may also be possible. Personally, I wouldn't allow it on shared server.

Is there any workaround for installing Drush 7 without the ext-pcntl dependency?

Not really*, but if you can mount webserver's filesystem on your local machine and tunnel SQL port, you can install drush locally and still use it on remote website. From Drush's point of view there will be no difference.

* Correct me if I'm wrong here.


php-cli has a different php.ini file than the webserver's php environment, so it is entirely possible to enable ext-pcntl for php-cli, but not for the php in the web server environment. Some shared hosting environments only allow one shared php.ini file, though. It is also possible that they may be unwilling to install it simply to prevent their clients from accidentally enabling it for the web server environment.

Drush uses ext-pcntl in backend invoke, so it is unlikely that you'll be able to use Drush successfully without it. The missing dependency might not be enforced in pre-Composer versions of Drush, so it might work to install Drush 6 or earlier, provided you do not call any functions that redispatch back to drush (e.g. use drush pm-updatecode followed by drush updatedb rather than using drush pm-update -- not that you'll be updating your live site on the hosting platform with pm-update though, right?)

  • I was able to work around it by installing Drush 6, which still lets me do what I need to do, for now. Thanks! Commented Aug 6, 2015 at 0:39
  • "not that you'll be updating your live site on the hosting platform with Drush though," - s far as i remember drush is also able to sync data and files between Drupal instances? Even if updates are tested on dev all right, they need to somehow get on production and Drush is one of the ways.
    – Mołot
    Commented Aug 6, 2015 at 6:11
  • Most folks update code on dev, and then either commit it to the vcs and push to live, or rsync it over. You are right that the Drush rsync wrapper could be used to deploy; there are also Drush extensions designed specifically for deploying. I'll update the answer to say pm-update instead of Drush. Commented Aug 6, 2015 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.