1

I have set up a local dev docker environment with the drupal social distribution. My issue is that drush commands do not work and whenever I issue a drush command, it takes approximately 45 seconds to get a response and generally the output is always the same or similar to this:

[warning] proc_open(): unable to dup File-Handle for descriptor 2 - Too many open files exec.inc:243

[warning] proc_get_status() expects parameter 1 to be resource, boolean given exec.inc:244

[warning] proc_close() expects parameter 1 to be resource, boolean given exec.inc:245

I am unsure what's the reason for this response or what I may have done wrong to get to this point. I tried googling the warning errors but without getting a usable answer so if someone has had similar problems and managed to solve it, some directions on what to do would be appreciated.

I also want to state that outside the docker environment I have setup a multiple drushes setup and drush commands work normally without any delays outside of it.

My environment is ubuntu 16.04 and my comp stats are:

15,5 GB RAM

i7-6500U CPU 2,5GHz x4 Processor

200GB DDR disk

Update: I googled some more and found out that for running drush inside a docker environment you need to:

docker-compose run drush "drush command here"

since drush container gets run only for one specific command and then shuts back down, but now I am getting different errors.

2nd update: The command I ran docker-compose run drush cache-rebuild --verbose --debug and the output I got:

Phar detected. Proceeding to drush_main().Drush preflight prepare loaded autoloader at [0 sec, 2.92 MB] [preflight] Starting Drush preflight. [0 sec, 2.92 MB] [preflight] Cache HIT cid: 8.1.2-commandfiles-0-9c75c37463d39480ab97163ab2be3712 [0.01 sec, 2.96 MB] [debug] Scanning into /etc/drush for /.*aliases.drush(8|)rc.php$/ [0.02 sec, 5.02 MB] [debug] Scanning into /etc/drush for /self.alias.drush(8|)rc.php$/ [0.02 sec, 5.02 MB] [debug] Scanning into phar:///usr/local/bin/drush/includes/.. for /.*aliases.drush(8|)rc.php$/ [debug] [0.02 sec, 5.02 MB] Scanning into phar:///usr/local/bin/drush/includes/.. for /self.alias.drush(8|)rc.php$/ [debug] [0.03 sec, 5.03 MB] Scanning into /root/.drush for /.*aliases.drush(8|)rc.php$/ [0.04 sec, 5.03 MB] [debug] Scanning into /root/.drush for /self.alias.drush(8|)rc.php$/ [0.04 sec, 5.03 MB] [debug] Bootstrap to phase 0. [0.05 sec, 6.01 MB] [bootstrap] Bootstrap to phase 2. [0.05 sec, 6.01 MB] [bootstrap] Command cache-rebuild needs a higher bootstrap level to run - you will need to invoke [error] drush from a more functional Drupal environment to run this command. [0.05 sec, 6.01 MB] Command cache-rebuild requires Drupal core version 8+ to run. [0.05 sec, 6.01 MB] [error] The drush command 'cache-rebuild' could not be executed. [0.05 sec, 6.01 MB]

Hope that gives you a clue of what is the matter here.

  • Can you run your drush command with --verbose --debug and add the entire command log here? (omit sensitive strings of course) – Joseph Jul 4 '17 at 14:09
  • i have very similar machine, I installed lamp and from terminal installed drush 8.1.8, and i have no issues at all – pinueve Jul 4 '17 at 21:28
  • As I updated my question when discovering that drush need to be run in a different fashion inside docker, the problem persists of me not being able to resolve and drush commands and as @Joseph the Dreamer mentioned I tried to add verbose and debug to the command and am going to post the output into my question as new update. – user3320816 Jul 5 '17 at 8:27
  • Looks like you also use docker-compose. Can you post the docker-compose.yml? Also, post your alias file, if any. – Joseph Jul 5 '17 at 12:26
0

When you run docker run ... or docker-compose run, Drush is running in the context of the container, not your host machine. So when it needs stuff like DB credentials, aliases, ssh keys, it looks for them in the container. If Drush cannot find such things in the container, Drupal cannot fully connect to Drupal and you get an error, usually the bootstrapping one.

I have a feeling your code isn't mounted to the Drush container, based on the fact that the alias scanning isn't picking up anything custom, only the usual alias paths. If the code is mounted, then probably the Drush container does not have the DB credentials. Do a drush status to check if everything is fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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