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
Comment #2
adr_p commentedI 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?
Comment #3
cilefen commentedThis 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?
Comment #4
cilefen commentedHow much RAM is allocated to PHP?
Comment #5
cilefen commentedComment #6
adr_p commented@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.
Comment #7
swentel commentedHmm, 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.
Comment #8
dawehnerThat basically looks like you have user module not available anymore or removed at least
user.services.ymlsomehow. Do you mind ensuring that this particular file is still there?Comment #9
adr_p commented@swentel, thanks for the response.
Here's my core.extension content. I wonder if those zeros are ok.
Comment #10
adr_p commented@dawehner
Yes, both the user.service.yml and the class defined in "password_migrate" service are there.
Comment #11
swentel commentedThe zeros are fine, that's their module weight. Hmm out of ideas for now to be honest.
Comment #12
adr_p commentedI'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.
Comment #13
adr_p commentedIt 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?
Comment #14
adr_p commentedComment #15
catchThere'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.
Comment #16
cilefen commented@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.
Comment #17
cilefen commentedComment #18
dawehnerWell 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.
Comment #19
adr_p commentedSo 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).
Comment #20
catchThat'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.
Comment #21
dawehnerYeah I think being able to alter core modules is pointless these days. Everything is alterable already.
Comment #22
cilefen commented@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.
Comment #23
Scott Dowdle commentedI 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.
Comment #24
Firemyst commentedI 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 819I reverted to 8.1.3 and everything is back to normal.
Comment #25
catchDo you have migrate module installed?
Comment #26
alexpottI'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.
Comment #27
alexpottTo add more information about how to upgrade Drupal - see https://www.drupal.org/node/2700999
Comment #28
cilefen commentedComment #29
Firemyst commentedMy 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.
Comment #30
cilefen commentedI'm glad to hear it.
Comment #31
cilefen commented