I'm new to Drupal 8. Today I was trying to figure out what for are tmp15770773961457795076 and tmp16692467511460295936 directories in Drupal's top directory (at the same level as web).

After deleting them and clearing the cache (via the UI) I got "The website encountered an unexpected error. Please try again later." error.

I've found this error in the logs:

Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException: You have requested a non-existent service "password_migrate". in /.../app/vendor/symfony/dependency-injection/ContainerBuilder.php on line 800

Restoring both directories didn't help. I was trying different things: clearing cache tables in the DB, trying drush rebuild (rebuild wasn't successful since it yelds the same error). After some time the error is different (and I don't know why):

Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException: The service "ctools.paramconverter.tempstore" has a dependency on a non-existent service "user.shared_tempstore". in /.../app/vendor/symfony/dependency-injection/ Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php on line 58

The site is basically broken. How can I restore it?

Comments

adr_p created an issue. See original summary.

adr_p’s picture

I can temporarily get the site back to live by loading {cache_container} table from the old backup. But the site breaks again after clearing the cache. Any ideas?

cilefen’s picture

Category: Bug report » Support request
Priority: Critical » Major

This is more like a support request at the moment and those are usually normal priority. If this turns out to be a bug, we can change it back. Are you sure your install is whole, as in, have you got all of Drupal's files?

cilefen’s picture

How much RAM is allocated to PHP?

cilefen’s picture

Title: "Non-existed service" errors after clearing the cache » "Non-existent service" errors after clearing the cache
adr_p’s picture

Category: Support request » Bug report
Priority: Major » Critical

@cilefen, thanks for your response.

I use composer to build the project (and I rebuilt it) so I'm pretty sure that no files are missing. Are there any configuration files (created by Drupal) needed to build {cache_container} content? There's always a possibility that I've deleted them by mistake, if they're not shipped in packages.

As for the PHP memory_memory limit it's 196M, but I've temporarily increased it to 512M and it didn't resolved the issue.

swentel’s picture

Hmm, the errors suggest the user module (core/modules/user.module) isn't enabled, for some weird reason (because I think it's mandatory on install iirc). Could you check the contents of the core.extension configuration and see if user is in there ? It should be there, if not try adding it manually and then clearing caches manually and then reload.

PHP limit won't fix anything here, so that's off the table.

dawehner’s picture

Status: Active » Postponed (maintainer needs more info)

That basically looks like you have user module not available anymore or removed at least user.services.yml somehow. Do you mind ensuring that this particular file is still there?

adr_p’s picture

@swentel, thanks for the response.

Here's my core.extension content. I wonder if those zeros are ok.

array (
  'module' => 
  array (
    'admin_toolbar' => 0,
    'article' => 0,
    'background_image_formatter' => 0,
    'bg_image_formatter' => 0,
    'block' => 0,
    'block_content' => 0,
    'breakpoint' => 0,
    'ckeditor' => 0,
    'config' => 0,
    'config_update' => 0,
    'core' => 0,
    'ctools' => 0,
    'datetime' => 0,
    'dblog' => 0,
    'devel' => 0,
    'devel_generate' => 0,
    'disqus' => 0,
    'dynamic_page_cache' => 0,
    'easy_social' => 0,
    'editor' => 0,
    'fb_likebox' => 0,
    'features' => 0,
    'features_ui' => 0,
    'field' => 0,
    'field_group' => 0,
    'field_ui' => 0,
    'file' => 0,
    'filter' => 0,
    'google_analytics' => 0,
    'image' => 0,
    'imce' => 0,
    'custom_project' => 0,
    'kint' => 0,
    'layout_plugin' => 0,
    'link' => 0,
    'menu_link_content' => 0,
    'menu_ui' => 0,
    'metatag' => 0,
    'metatag_open_graph' => 0,
    'metatag_twitter_cards' => 0,
    'node' => 0,
    'options' => 0,
    'page' => 0,
    'page_cache' => 0,
    'path' => 0,
    'site' => 0,
    'system' => 0,
    'taxonomy' => 0,
    'text' => 0,
    'token' => 0,
    'toolbar' => 0,
    'tvi' => 0,
    'update' => 0,
    'user' => 0,
    'views' => 0,
    'views_slideshow' => 0,
    'views_slideshow_cycle' => 0,
    'views_ui' => 0,
    'ds' => 1,
    'pathauto' => 1,
    'ds_extras' => 2,
    'minimal' => 1000,
  ),
  'theme' => 
  array (
    'stark' => 0,
    'stable' => 0,
    'classy' => 0,
    'bartik' => 0,
    'custom_theme' => 0,
  ),
  '_core' => 
  array (
    'default_config_hash' => 'm2GVq11UAOVuNgj8x0t5fMOPujpvQQ_zxLoaly1BMEU',
  ),
)
adr_p’s picture

@dawehner

Yes, both the user.service.yml and the class defined in "password_migrate" service are there.

swentel’s picture

The zeros are fine, that's their module weight. Hmm out of ideas for now to be honest.

adr_p’s picture

I've found another symptom. When I edit the note, it's almost empty, apart from the title. But when I query the {node__body} table I can see that node's content is there. Somehow Drupal doesn't see it.

adr_p’s picture

It took me a while, but I managed to find the issue and to solve it.

The problem was directly caused by the Features module (or maybe rather it was directly caused by careless me...). Anyway, a couple of hours before I cleared the cache (this is when the issue manifested itself) I had exported some configuration as new features. Normally I would use some custom names, but this time I've just swum with the tide and added the configuration to the features that Features module proposed. And one of the proposed features was "User" with machine name "user", which is exactly the same as the core module! This is why "password_migrate" service couldn't be found, Drupal was looking at the new feature instead of the core module.

Because the module name was already in core.extension configuration I didn't even have to enable it, as it was already enabled (unlike in the old {system} table there's no path to the module in the config so probably Drupal just used the first definition it found). After exporting the feature the problem was there, sleeping, and it was just when I cleared the cache some time later when the site broke (probably if the problem appeared right away I could track it down much earlier).

The problem went away as soon as I deleted the feature.

I think that Features module proposing "user" as a feature name isn't a good idea. But maybe there's something that Drupal could do to prevent such situations? What do you think?

adr_p’s picture

Status: Postponed (maintainer needs more info) » Needs review
catch’s picture

Category: Bug report » Support request
Priority: Critical » Normal

There's a 'feature' whereby you can replace a core module with an alternative version in sites/*/modules and it will look there for modules before core.

We've maintained that feature for years, but as we've added hook_menu_alter() then hook_module_implements_alter() and now plugins and services, there's really no use case for it left.

I think it's worth opening an issue to look at dropping that feature to prevent situations like this, or there might be one already open, but couldn't find it from a cursory search.

Downgrading this issue though since the behaviour is 'by design' even if it was very confusing in this case.

cilefen’s picture

@catch Isn't there an issue around to prefer the newer module, which was needed for Big Pipe now being in core? I can't find it—it may be my imagination.

cilefen’s picture

Title: "Non-existent service" errors after clearing the cache » Duplicate user module causes "Non-existent service" errors
dawehner’s picture

I think it's worth opening an issue to look at dropping that feature to prevent situations like this, or there might be one already open, but couldn't find it from a cursory search.

Well there is a similar feature: a different version of a contrib module in a multsite environment which is provided by the same underlying code. This is IMHO a total valid usecase all the time.

adr_p’s picture

So maybe if there is a use case for sites/*modules and web/modules having precedence over modules and web/core/modules, then we should at least assign the issue to the Features module? Features proposing 'user' as a default feature name is very dangerous. "Overwriting" a core module is a thing that should be done thoughtfully, especially that the use case is very rare and the overwriting module should be "compatible" with replaced one (not just share the name).

catch’s picture

Well there is a similar feature: a different version of a contrib module in a multsite environment which is provided by the same underlying code. This is IMHO a total valid usecase all the time.

That's a reason to look in sites/SITENAME/modules before sites/all/modules and /modules, but I'm not sure it's a good reason to look in those before /core/modules.

dawehner’s picture

Yeah I think being able to alter core modules is pointless these days. Everything is alterable already.

cilefen’s picture

Status: Needs review » Active

@adr_p Open a separate issue with Features on that please and reference this issue, because I agree it's a bad idea to offer a core module name.

I think this is now closed as a support request. If anyone wants to open an issue based on #15, go ahead.

Scott Dowdle’s picture

I have two Drupal 8.1.3 sites. One has two third-party modules (Node View Permissions 8.x-1.0 and Video 8.x-1.2) and the other is stock (aka no third-party modules). I just tried to upgrade them both to 8.1.4 and immediately get the following error after extracting the updated 8.1.4 files to the documentroot:

[Wed Jul 06 20:30:18.058092 2016] [:error] [pid 643] [client {myipaddress}:38112] Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException: You have requested a non-existent service password_migrate. in /{mydocumentroot}/vendor/symfony/dependency-injection/ContainerBuilder.php on line 819

So far as I can tell, I haven't modified anything from stock. Maybe it is my combination of apache, php, and mysql? (Using CentOS 7.2 with packages from the SCL repo: httpd24-httpd-2.4.18-10, rh-php56-php-5.6.5-8, mariadb-5.5.47-1. I have to use those because the stock versions in EL7 aren't new enough to meet Drupal's system requirements).

Anyone else run into this issue?

I don't really understand the developer speak given in many of the comments in this thread but this seemed like the appropriate place to post this... hopefully.

Firemyst’s picture

I can confirm that I had the same problem, but also can't tell if this is related to what has gone on before, or is this a new issue.

Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException: You have requested a non-existent service "password_migrate". in /opt/home/hoffnet/drupal/vendor/symfony/dependency-injection/ContainerBuilder.php on line 819

I reverted to 8.1.3 and everything is back to normal.

catch’s picture

Do you have migrate module installed?

alexpott’s picture

I'm pretty sure #23 and #24 are because of file deletes. In order to upgrade core you need to delete the core directory and replace it.

alexpott’s picture

To add more information about how to upgrade Drupal - see https://www.drupal.org/node/2700999

cilefen’s picture

Title: Duplicate user module causes "Non-existent service" errors » ServiceNotFoundException: You have requested a non-existent service "password_migrate"
Firemyst’s picture

My apologies. I thought I'd done the update correctly. I've followed the upgrade notes to the letter and have no issues now with 8.1.4. Disregard my previous post and thanks for the tip.

cilefen’s picture

Title: ServiceNotFoundException: You have requested a non-existent service "password_migrate" » ServiceNotFoundException: You have requested a non-existent service "password_migrate" when documented upgrade procedure is not followed
Status: Active » Fixed

I'm glad to hear it.

cilefen’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.