You have requested a non-existent service "drush.service.consolecommands". #2767

scubafly · 2017-05-18T12:15:53Z

See issue #2658
This occurs with drush 8.1.11
I opened a new issue since the other one is closed.

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "drush.service.consolecommands". in                                        [error]
Drupal\Component\DependencyInjection\Container->get() (line 157 of /var/www/drupal8/core/lib/Drupal/Component/DependencyInjection/Container.php) #0
/usr/local/src/composer/vendor/drush/drush/lib/Drush/Boot/DrupalBoot8.php(163): Drupal\Component\DependencyInjection\Container->get('drush.service.c...')
#1 /usr/local/src/composer/vendor/drush/drush/includes/bootstrap.inc(354): Drush\Boot\DrupalBoot8->bootstrap_drupal_full()
#2 /usr/local/src/composer/vendor/drush/drush/includes/bootstrap.inc(473): drush_bootstrap(5, 5)
#3 /usr/local/src/composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(53): drush_bootstrap_to_phase(5)
#4 /usr/local/src/composer/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#5 /usr/local/src/composer/vendor/drush/drush/drush.php(12): drush_main()
#6 {main}.
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "drush.service.consolecommands". in /var/www/drupal8/core/lib/Drupal/Component/Dep
endencyInjection/Container.php on line 157 #0 /usr/local/src/composer/vendor/drush/drush/lib/Drush/Boot/DrupalBoot8.php(163): Drupal\Component\DependencyInjection\Container->get('drush.service.c...')
#1 /usr/local/src/composer/vendor/drush/drush/includes/bootstrap.inc(354): Drush\Boot\DrupalBoot8->bootstrap_drupal_full()
#2 /usr/local/src/composer/vendor/drush/drush/includes/bootstrap.inc(473): drush_bootstrap(5, 5)
#3 /usr/local/src/composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(53): drush_bootstrap_to_phase(5)
#4 /usr/local/src/composer/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#5 /usr/local/src/composer/vendor/drush/drush/drush.php(12): drush_main()
#6 {main}
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "drush.service.consolecommands". in Drupal\Component\DependencyInjection\Container->ge
t() (line 157 of /var/www/drupal8/core/lib/Drupal/Component/DependencyInjection/Container.php).
Drush command terminated abnormally due to an unrecoverable error.

The text was updated successfully, but these errors were encountered:

scubafly · 2017-05-18T12:30:08Z

Looks like you need Drupal 8.3.1 or up to let this error occur.

scubafly · 2017-05-18T12:36:00Z

Downgrading to drush 8.1.10 solves the problem.

mikaelkundert · 2017-05-22T10:35:45Z

I can confirm this. I'm using drush 8.1.11, but I'm using Drupal 8.3.0

EDIT: And yes, downgrading fixed the issue

weitzman · 2017-06-09T12:34:25Z

Could someone try drush cr to see if that clears up the problem.

scubafly · 2017-07-03T13:58:46Z

Doing a drush cr on the server itself does not solve the problem for me. ( Using drush 8.1.12 )

rmuit · 2017-08-28T21:14:51Z

Just a suggestion for others coming across this: maybe Drush 8.1.11 is not the actual cause of the problem, but it just exposes existing weirdness with containers/autoloaders/drushs+library inconsistencies that was waiting to happen... Which makes it hard to trace.

Question to anyone experiencing this: do you have a 'site-local' drush version installed?

Two of our customers in the past week reported this problem. As it turns out, both of them

had a site-local drush in their drupal's vendor/ tree
but their vendor/ tree (as committed into their repo & deployed,) had no vendor/bin/ for some reason.

Apparently if you have a drush in your vendor/, you should really run that drush instead of whatever system-wide drush you have, otherwise: dragons. (I won't argue this point but will defer to https://pantheon.io/blog/trouble-two-autoloaders and https://pantheon.io/blog/avoiding-dependency-hell-site-local-drush.)
The thing is that

Drush takes care of you for that; great! If you run 'drush --root=/your/docroot/ it checks for a site-local drush, and semi-secretly runs that instead of your system-wide drush.
however that breaks down for our customers who have a missing vendor/bin/drush.
Therefore: system-wide drush runs and then boots/autoloads Drupal + other included drush. Therefore: dragons. Manifesting in the form of the error message in this issue title.

greg-1-anderson · 2017-08-28T21:53:24Z

Haven't seen the missing vendor/bin thing before. If that's common, then maybe Drush should have a fallback check for vendor/bin/drush/drush/drush in the redispatch code, just in case.

rmuit · 2017-08-29T14:28:01Z

I was getting paranoid about this because I started seeing this in multiple places for different reasons. But it might be, for the most part, a wonky .gitignore with a missing "always include vendor/bin", that got distributed to multiple customers. I can't say.

So - so far I am unable to 'prove' that this is more common, and the above note is just a hint for others to look in that direction and maybe share their experiences.

smfsh · 2017-08-29T23:10:39Z

I'm experiencing this issue right now on Acquia's PaaS with their default global drush (version 8.1.12). My site code does have a vendor directory with drush installed locally and available in vendor/bin. As a workaround for our deployment, we just use the drush executable from the local code and it works fine, not the one Acquia provides, but it would still be nice to get some resolution.

rmuit · 2017-09-11T20:54:32Z

Two followups:

The missing vendor/bin thing was caused by two things:

a composer.json that specifies "config": {"bin-dir": "bin/"},
a .gitignore that ignores bin/

I couldn't get answers to "why?", so I hacked a solution in this particular repo/build script already. I have no idea how many people redefine "bin-dir", so I won't advocate actively for having a fallback check for vendor/bin/drush/drush/drush in the redispatch code... maybe it's a good idea just in case.

Miles' issue, and no doubt an issue for other Acquia customers, is that

Acquia provides standard aliases for its customer accounts, through a /etc/drush/drushrc.php which sets $options['alias-path'] = (some unix-user-specific file). The aliases have 'root' specified.
the drush finder script looks at the --root commandline option, but not at aliases, when trying to find a site-local drush. => aliases are pretty much unusable. This is not very intuitive.

So my questions are:

Is Drush planning to support finding a site-local drush through aliases?
In case the answer is "yes, please submit a PR": got any rough hints on whether someone should
** copy code from sitealias.inc into startup.inc?
** abstract code from sitealias.inc (if necessary) so that it's usable in a way that the context cache does not get used? (Disclaimer: I know nothing about drush_get_context(), I just see it being called everywhere)
** just include the whole context.inc thing into the finder?
** ... other?

greg-1-anderson · 2017-09-11T22:57:34Z

Please see #2843. This PR will be merged into master when ready. The general idea is that the alias code from this PR will be extracted into consolidation/aliases or consolidation/site_aliases for re-use elsewhere (launcher, et. al.)

…rvices unless they exist in the container. This converts a crashing scenario into one where commands are merely missing. A 'drush cr' should bring back the missing commands.

Fixes #2767: Avoid 'non-existent service' error

greg-1-anderson · 2017-10-03T12:19:27Z

Could folks who are experiencing this problem please try again with the latest HEAD from the 8.x branch? That PR converts this error from a crash to a situation where module commands will be missing. Only module commands implemented with annotations will be missing; that feature is uncommonly used right now, so I imagine most people will not realize it if they are having this problem.

calbasi · 2018-01-08T23:25:48Z

Just to say I'm having a drush freeze issue... I'm not an very skilled composer user, but my situation is like you are talking about...
I have a local drush 8.1.x installation, at /home/user folder, and I have a path link at my ~/.bashrc file...
Well, today I've updated my drupal 8.4.0 to drupal 8.4.4 because drupal commerce 2.2.0 was not updating to 2.2.2, and for do it, I have to update drush to 9.x using composer require drush/drush:>9.0.0 (or similar :-p ). Well, after it, I've disabled my local (/home/user/...) drush 8.1.x
But drush 9.0 is just freezing my server...
If I do: drush -d version, I get a loop of:
[preflight] Redispatch to site-local Drush: /var/www/espai31.cat/web/espai31/vendor/drush/drush/drush.
[preflight] Redispatch to site-local Drush: /var/www/espai31.cat/web/espai31/vendor/drush/drush/drush.
[preflight] Redispatch to site-local Drush: /var/www/espai31.cat/web/espai31/vendor/drush/drush/drush.
[preflight] Redispatch to site-local Drush: /var/www/espai31.cat/web/espai31/vendor/drush/drush/drush.
[preflight] Redispatch to site-local Drush: /var/www/espai31.cat/web/espai31/vendor/drush/drush/drush.
[preflight] Redispatch to site-local Drush: /var/www/espai31.cat/web/espai31/vendor/drush/drush/drush.
...
And I've seen my /bin is not inside /vendor, but outside:
/var/www/espai31.cat/web/espai31/vendor/
/var/www/espai31.cat/web/espai31/bin
...
Deleting bin, vendor and composer.lock and doing a composer update has the same result...

I have no idea what's happening...

calbasi · 2018-01-08T23:55:35Z

More info: this behavior is happening only with my user "joan" (was user who I managed to use a local drush 8.x globally). If I execute drush using sudo, it seems OK

I've tryed creating a new user, with a clean /home/new_user folder, and I get the same error than with previous user... Only seems Ok with using sudo.

calbasi · 2018-01-09T00:11:43Z

By the way, drush launcher is not solving my issue :-(

calbasi · 2018-01-09T13:35:39Z

FYI: my issue has dissapeared using dev-master at composer.json:
"drush/drush": "dev-master"
instead of:
"drush/drush": "~9.0"
Now I have 9.0-dev-g3198a8ad version, and before I had RC1 from 9.0

NickDickinsonWilde · 2018-01-22T02:26:08Z

I can confirm that never ending redispatch notices are fixed in RC2 and can happen under some circumstances with RC1.

weitzman assigned greg-1-anderson May 20, 2017

weitzman added the area-annotated label May 20, 2017

weitzman added the stat-needs-work label Jun 12, 2017

greg-1-anderson added a commit that referenced this issue Oct 3, 2017

Merge pull request #3007 from drush-ops/guard-service-cache

4e3ae5b

Fixes #2767: Avoid 'non-existent service' error

calbasi mentioned this issue Jan 8, 2018

Global Drush9 should redispatch to site-local drush8 even if alias record not found #3274

Closed

weitzman closed this as completed Jan 22, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

You have requested a non-existent service "drush.service.consolecommands". #2767

You have requested a non-existent service "drush.service.consolecommands". #2767

scubafly commented May 18, 2017

scubafly commented May 18, 2017

scubafly commented May 18, 2017

mikaelkundert commented May 22, 2017 •

edited

weitzman commented Jun 9, 2017

scubafly commented Jul 3, 2017 •

edited

rmuit commented Aug 28, 2017

greg-1-anderson commented Aug 28, 2017

rmuit commented Aug 29, 2017

smfsh commented Aug 29, 2017

rmuit commented Sep 11, 2017 •

edited

greg-1-anderson commented Sep 11, 2017

greg-1-anderson commented Oct 3, 2017

calbasi commented Jan 8, 2018

calbasi commented Jan 8, 2018

calbasi commented Jan 9, 2018 •

edited

calbasi commented Jan 9, 2018

NickDickinsonWilde commented Jan 22, 2018

You have requested a non-existent service "drush.service.consolecommands". #2767

You have requested a non-existent service "drush.service.consolecommands". #2767

Comments

scubafly commented May 18, 2017

scubafly commented May 18, 2017

scubafly commented May 18, 2017

mikaelkundert commented May 22, 2017 • edited

weitzman commented Jun 9, 2017

scubafly commented Jul 3, 2017 • edited

rmuit commented Aug 28, 2017

greg-1-anderson commented Aug 28, 2017

rmuit commented Aug 29, 2017

smfsh commented Aug 29, 2017

rmuit commented Sep 11, 2017 • edited

greg-1-anderson commented Sep 11, 2017

greg-1-anderson commented Oct 3, 2017

calbasi commented Jan 8, 2018

calbasi commented Jan 8, 2018

calbasi commented Jan 9, 2018 • edited

calbasi commented Jan 9, 2018

NickDickinsonWilde commented Jan 22, 2018

mikaelkundert commented May 22, 2017 •

edited

scubafly commented Jul 3, 2017 •

edited

rmuit commented Sep 11, 2017 •

edited

calbasi commented Jan 9, 2018 •

edited