[Installation Error] Symfony: "The service definition 'request' does not exist."

Are you trying to install in a language other than English? If so I think there's already a bug report for that.

This error also occurs during a standard installation if the 'sites/default/files' directory exists but is not writeable.
During the system_requirements() pass, the files directory is identified as not writeable and calls drupal_chmod(). Here a call to octdec() triggers the Synfony error message.

The linkage to Symfony in #4 was not clear. Let's try that again.

In the core/modules/system/system.install call to system_requirements('install'), a check is performed to ensure that the sites/default/files exists and is writeable. That process calls:

file_prepare_directory("sites/default/files", FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS)

which then calls:

drupal_chmod("sites/default/files")

In drupal_chmod(), the call to octdec passes an argument that will eventually call into Symfony.

   if (is_dir($uri)) {
      $mode = octdec(config('system.file')->get('chmod.directory'));
      if (!$mode) {
        $mode = 0775;
      }
    }

Call to config("system.file") immediately calls drupal_container. Note that this call is deprecated.

function config($name) {
  return drupal_container()->get('config.factory')->get($name);
}

drupal_container::getContainer() is called next

Drupal::getContainer returns static::$container

At this point we have the drupal_container() reference from above. Next is a call to the get method in Symfony to retrieve a service.
And that's were it fails - it cannot find the 'request' service reference.

I found this by tracing through the call stack with PHPStorm and xDebug. I have no knowledge of Symfony other then a bit I picked up from our consultant. Replacing the deprecated call with the correct method in the Drupal object might help.

@jewald nice steps to follow along.

file.inc tries to chmod silently and fails to do so.

function drupal_chmod($uri, $mode = NULL) {
...
  else {
    if (@chmod($uri, $mode)) {
      return TRUE;
    }
  }

  watchdog('file', 'The file permissions could not be set on %uri.', array('%uri' => $uri), WATCHDOG_ERROR);
  return FALSE;
}

next the watchdog line is called. That call introduces an exception trying to Drupal::request()->getClientIP(); while setting the log entry:

    $log_entry = array(
      'type'        => $type,
      'message'     => $message,
      'variables'   => $variables,
      'severity'    => $severity,
      'link'        => $link,
      'user'        => $user,
      'uid'         => $user_uid,
      'request_uri' => $base_root . request_uri(),
      'referer'     => isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : '',
      'ip'          => Drupal::request()->getClientIP(),
      // Request time isn't accurate for long processes, use time() instead.
      'timestamp'   => time(),
    );

I'm not sure why the static call the get the request fails through Drupal::request()?

See #1974570: The service container is used before it's set in the drupal error handler for the cause I guess.

The patch wraps the call to file_prepare_directory in a try catch and adds a message.

Is the extra message necessary?

Hmmm I disagree with my own #9 now while writing #1974570-6: The service container is used before it's set in the drupal error handler. We should patch watchdog in using Drupal::request.

Shall we close this issue as a 'dup' of #1974570: The service container is used before it's set in the drupal error handler as that is closer related to the causing problem?

The senario presented in #6 fails at the call to octdec(), well before the watchdog in drupal_chmod(), but it fails for essentially the same reason as the issue in #7 inside watchdog. The common issue is that the service container is used before it's ready.

If the service container is established in the boot process before code wants to call the drupal error handler, it should also correct the issue in #4 where the evaluation of the parameter in the octdec() call fails.

#10 works for me.

the issue is permissions on sites/default/files, as solved in http://drupal.org/node/1986996

chmod 777 sites/default/files

fixes it - just reposting here because this thread was a dead end for me ;)

The problem is with the call to config itself I think. There's no UI setting for this, so why not move it to $settings?

@catch I don't get it.

The problem is with the call to config itself I think. There's no UI setting for this, so why not move it to $settings?

This is imho similar to #1974570: The service container is used before it's set in the drupal error handler and patch from #9 should not be considered anymore as I tried to say in #10

We should close this and make critical #1974570: The service container is used before it's set in the drupal error handler.

I mean drupal_mkdir() is supposed to be a low-level PHP wrapper, it shouldn't have a dependency on the configuration system at all.

IC ... not sure whether that should always be so as we have ie #1908440: Relax MTimeProtectedFileStorage permissions for DX, drush integration and world domination

I'm not sure why I ended up into the watchdog() flow and @jewald into octdec() flow :(

clemens$ sudo rm -r files fails nicely report files directory does not exists.

clemens$ mkdir files fails through watchdog() flow

clemens$ chmod 777 files let the installer do it's expected job

@jewald did you do something different?

Putting it in $settings means that you have to specify it in settings.php - it couldn't be configured by the UI (not that you can now either of course since there isn't a UI for this). That's about it though in terms of the change to site administrators.

Most PHP wrappers are moving to static utility classes - in this case the file class would have a dependency on the settings class, but that's always available in Drupal and also static.

In my test case, the files directory perms were 755. The owner and group were my dev account, 'jewald', not the typical apache www-data account. I think the issue here is that the apache process does not have sufficient permissions to change permissions on the 'files' folder to 775.

After reading #1845646: error_displayable() cannot be converted from variable system safely I close this one as asked for in #10 and agreed in #11 to reduce the issue count :)

The title of #1845646: error_displayable() cannot be converted from variable system safely is a little cryptic but it's patch is inline (sort of) with #1974570: The service container is used before it's set in the drupal error handler.

I wonder if anyone has tried installing Drupal 8 with SQLite?

I ran into the same

The service definition "request" does not exist.

error message when trying to install with the SQLite database engine, with sites/default/files/ directory user and permission set to www-data:www-data, 0775.

With MySQL engine, however, Drupal 8.x-dev (2013-05-16) installed successfully.

Many thanks!

Updated issue summary.

I cannot reproduce the error as described in the issue summary. But I am getting the error mentioned in #28. I opened issue #1998366: [meta] SQLite is broken, which someone closed as a duplicate of this. But I can verify I was NOT getting the sqlite error as late as 5/5, which is when this issue was posted and I think, but can't verify, that I wasn't getting the error as of 5/8. The sqlite error may be related to this but I don't think it is a permissions problem. I will re-open #1998366: [meta] SQLite is broken until things become clearer.

I run this script after loading the distribution into my "Sites/drupal8" directory:

#!/bin/sh
# $Id: setup $
chmod a+w sites/default
cp sites/default/default.settings.php sites/default/settings.php
chmod a+w sites/default/settings.php

I then start the install from my web browser. The permissions on 'Sites/drupal8/sites/default' at the time of failure are:

drwxrwxrwx+ 5 staff    170 May 19 20:16 .
drwxr-xr-x+ 5 staff    170 May 18 10:50 ..
-rw-r--r--+ 1 staff  25489 May 18 10:50 default.settings.php
drwxrwxr-x+ 2 staff     68 May 19 20:16 files
-rw-rw-rw-+ 1 staff  25489 May 19 20:16 settings.php

The 'files' directory is empty.

@dcrocks if you chmod 777 sites/default/files you are as good to go. Note this is bad practice. And why should the sites/default be writable to the world?

Updated issue summary.

Added to the issue summary
- #1908440: Relax MTimeProtectedFileStorage permissions for DX, drush integration and world domination
- #1974570: The service container is used before it's set in the drupal error handler

I've tested the following

1 sites/default/files does not exists and cannot be created by web server

- the installer tells us it is not there and it cannot be created.
- by creating the directory mkdir sites/default/files we get "The service definition "request" does not exist."
- by chmod 777 sites/defaults/files the installer is happy again.

2 sites/default does not exists and can be created by web server as we did chmod a+w sites/default which is completely bad practice.
- the installer is happy.

3 sites/default/files is created and user or group owner is the webserver.
- installer is happy.

As far as I understand this is a user 'error' not setting the permissions for the sites/default/files directory properly which produces a very not helping message.

The root cause will be fixed through one of the related issues most probably through #1845646: error_displayable() cannot be converted from variable system safely.

re: #33 Setting 'files' to 777 does not work for me. Where the install fails, it has created 'files' with appropriate permissions. I haven't tried creating it before I start install.

re: #32 'staff', '_www', and myself all have R+W permissions on the 'files' directory at the time of failure.

re: #39 I don't use MySql but rather SQLite. I haven't tested it but #28 indicates a permissions change solves the problem for MySql but not SQLite.

ps. The 'owner' of sites/default/files is '_www'.

@the_phi we are in a transitional phase :-/

#1938334: META: Replace uses of drupal_container() and #1938338: Replace drupal_container() in Configuration system to name a few.

Thanks for the links ... I was not aware of config().

@dcrocks your files mods don't look ok to me in #31 ... files should have 'rwx' to world aka www-data

Let's at least fix the bug that hides the underlying issues.

@the_phi: the patch from #43 tries to solve the problem but your patch from #44 and/or #47 does not contain parts of #43. That should be the case.

Bare in mind that #43 failed due to a test 'can acquire second lock' which sound very bad. That must be addressed too :-)

So please add #43 as part of a new patch and motivate your part from #44 and/or #47 being part of the fix.

Tried fix in #43 on latest 8-x.dev and got a WSOD. Apache error log showed:

[Tue May 21 11:00:28 2013] [error] [client ::1] PHP Fatal error: Call to a member function get() on a non-object in /Users/rocks/Sites/drupal8/core/lib/Drupal.php on line 147, referer: http://localhost/~rocks/drupal8/core/install.php?langcode=en&profile=sta...

Btw, could someone here give me D8 core commit perms/rights, please? :) I'd love to commit this directly, if you all allow/agree.

Yeah, umh... That's not gonna happen :P

-      $mode = octdec(config('system.file')->get('chmod.directory'));
+      $mode = octdec(Drupal::config('system.file')->get('chmod.directory'));
       if (!$mode) {

The direct call to Drupal::config() should be replaced with using $settings. The Drupal class still uses the container so this isn't really fixing much as it is.

http://drupal.org/node/1882698 has docs for the settings api.

In #1908440-10: Relax MTimeProtectedFileStorage permissions for DX, drush integration and world domination sun mentioned settings should already exists but I failed to find those.

@the_phi fwiw if we left out the chmod stuff (as that's a moving target still) we can mark this patch after testing as RTBC which will make the installer report the errors.

For what it's worth, I also got this message on a server with SELinux enabled where the "files" directory had the wrong SELinux label. Please keep in mind that it's not just about the read-write-execute permissions -- there could be any number of reasons access to a file or directory might be blocked.

You can add the default for chmod_directory in the settings call: settings()->get('chmod_directory', '0775').

Added more related items

Patch from #62 works as expected.

The installer nicely reports:
- The directory sites/default/files does not exist.
- The directory sites/default/files is not writable. (new behaviour fixed by the patch)

Thanks @the_phi + @Damien Tournoud

We shouldn't set _drupal_error_handler() until after the kernel is booted. In fact watchdog() can't do anything until afterhttp://api.drupal.org/api/drupal/core%21includes%21bootstrap.inc/functio... anyway.

This is closely related to #1974570: The service container is used before it's set in the drupal error handler which is in turn closely related to #1845646: error_displayable() cannot be converted from variable system safely.

@catch: no, this is unrelated. This patch is about the *request* not being available, not the container. There is no reason for watchdog() not to work outside of a request context.

#62 is basically my #43 re-uploaded, but RTBC again based on #65.

@Damien, please explain how watchdog will work when there's no bootstrap modules loaded.

@Damien, please explain how watchdog will work when there's no bootstrap modules loaded.

@catch: I'm sorry? I fear that we are totally talking past each other.

This patch is about making watchdog work when the container is available but *before* the request is set. I.e. it's the time between new DrupalHTTPKernel() and $kernel->handle($request).

The main underlying problem here is the "request" object is not being set in the dependency-injection container. I have created a simple fix which ensures the request object is set at all times during the installation process. Previously, it was only being set when $install_state['settings_verified'] is true

No interdiff included because this is a new approach

@bshaffer: that's an independent fix. Watchdog should *not* assume that it is running in a request scope, so the patch in #63 should go in no matter what.

The patch #62 it's good, now it creat the sqlite3 database, but I have some error ... I'm gonna try to catch it and post the error.

This is the trace I have.

2013/06/04 20:48:21 [error] 9300#0: *84 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Call to a member function get() on a non-object in /var/www/htdocs/drupal8/public_html/core/lib/Drupal.php on line 147
PHP message: PHP Stack trace:
PHP message: PHP   1. {main}() /var/www/htdocs/drupal8/public_html/core/install.php:0
PHP message: PHP   2. install_drupal() /var/www/htdocs/drupal8/public_html/core/install.php:31
PHP message: PHP   3. install_begin_request() /var/www/htdocs/drupal8/public_html/core/includes/install.core.inc:88
PHP message: PHP   4. install_verify_database_settings() /var/www/htdocs/drupal8/public_html/core/includes/install.core.inc:318
PHP message: PHP   5. install_database_errors() /var/www/htdocs/drupal8/public_html/core/includes/install.core.inc:1002
PHP message: PHP   6. db_run_tasks() /var/www/htdocs/drupal8/public_html/core/includes/install.core.inc:1142
PHP message: PHP   7. Drupal\Core\Database\Install\Tasks->runTasks() /var/www/htdocs/drupal8/public_html/core/includes/install.inc:1159
PHP message: PHP   8. Drupal\Core\Database\Driver\sqlite\Install\Tasks->connect() /var/www/htdocs/drupal8/public_html/core/lib/Drupal/Core/Database/Install/Tasks.php:128
PHP message: PHP   9. Drupal\Core\Database\Database::getConnection() /var/www/htdocs/drupal8/public_html/core/lib/Drupal/Core/Database/Driver/sqlite/Install/Tasks.php:54
PHP message: PHP  10. Drupal\Core\Database\Database::openConnection() /var/www/htdocs/drupal8/public_html/core/lib/Drupal/Core/Database/Database.php:171
PHP message: PHP  11. Symfony\Component\ClassLoader\ClassLoader->loadClass() /var/www/htdocs/drupal8/public_html/core/lib/Drupal/Core/Database/Database.php:0
PHP message: PHP  12. require() /var/www/htdocs/drupal8/public_html/core/vendor/symfony/class-loader/Symfony/Component/ClassLoader/ClassLoader.php:152
PHP message: PHP  13. _drupal_error_handler() /var/www/htdocs/drupal8/public_html/core/vendor/symfony/class-loader/Symfony/Component/ClassLoader/ClassLoader.php:24
PHP message: PHP  14. _drupal_error_handler_re

@kilua99
If you are using SQLite, there are 2 other issues you need to try before you can complete an install; #2008644: FilterPluginManager::__construct calls CacheDecorator with incorrect parameters (expires) and #2010322: SQLite follow up to #1953800 'Make the database connection serializable'. If you apply those 2 patches you will at least get 8-x installed. However, it still won't function as there is another problem introduced by #1498674: Refactor node properties to multilingual. You can look thru #1998366: [meta] SQLite is broken to see some of the discussion. But right now the latest 8-x will not run on SQLite, or postgres apparently.

I tried patching with #71 and the patch did not work.

Edit: I also tried patching using #62 and it did not work.

Edit2: Changing PHP version from 5.4.10 to 5.3.20 fixed the issue.
(I am running MAMP 2.1.3)

So, can be the PHP version? I have 5.4.x ubuntu 13.05 repo .... but I don't want to downgrade it.

@adamcowboy
What is/was your setup? Did you try the patch in #62 to see if you could get better error msgs? You may have a different problem than those previously discussed.

Is this(#1958006: WSOD with Drupal 7 to Drupal 8 upgrade on Win 8/PHP 5.4 and Ubuntu 12/PHP 5.3) also related. Seems a lot of different error conditions masked under same error msg.

As far as I understand this is a user 'error' not setting the permissions for the sites/default/files directory properly which produces a very not helping message.

Yep, the error is caused by incorrect file permissions. I corrected it by changing the directory owner to the web server user. The root cause for me was Drupal making the "sites/default" folder read-only, then when I recreated the files directory, my computer helpfully asked for my username/password to elevate the permissions to make the files directory. However then it created it as root, resulting in making an unwritable directory for Drupal. So I'm glad that we're fixing the error message that is resulting here in this issue, but it would be nice to fix #1925822: Stop locking me out of my own sites/default directory if Drupal is already insecure so this didn't happen in the first place.

Could we get #62 in, please?

The only result of waiting is more people reporting random, independent installation-related bugs in this issue.

i am +1 for #62 too

This seems like a good idea... reporting the real error will be a great help :)

Committed 547b874 and pushed to 8.x. Thanks!

pfew and thanks :)

Still here on drupal8-alpha2.

Yes there's plenty of other places that we try to access request before it's available, patch is only fixing it in one place via a workaround.

Re-opening.

if settings.php doesnt exist or isnt writable, this error comes up.

#62: symfony-request-context-in-watchdog-bootstrap-1987262-62.patch queued for re-testing.

#71: installation-error-symfony-request-does-not-exist-1987262-71.patch queued for re-testing.

Why is this issue reopened? I would expect a new issue as the root cause is different from the fix patch #71.

re-testing patch #71is of no use either as it is already applied :p

@the_phi, #62 was committed but there's still multiple errors with this.

@clemens.tolboom we could open another issue but 1. #62 was not a complete fix 2. it'd have exactly the same title and the root cause is the same - we have procedural code called before the request is available in the installer.

@catch ic ... I completely missed #62 was committed :/

@the_phi#93 I did try to apply patch #62 and got a failure.
When I click on re-test, test fails.

Step 1 : Choose language : English
Step 2 : Choose profile : Standard
Step 3 : Verify requirements : Requirements problem - The service definition "request" does not exist.

Did I did something wrong ?

@fgrossin The fix in #62 is already committed. I get the failure in your scenario if I failed to set permissions correctly before starting the install. Setting the permissions correctly allows install to go on. Perhaps you have a permissions problem.

Could this be closed and a new issue opened addressing the problem with permissions and install? And any other install errors identified here but not yet addressed? If you find a install failure with symptoms similar to the one addressed here this issue can become a very misleading read.

git clone --branch 8.x http://git.drupal.org/project/drupal.git
Installing gives me 'The service definition "request" does not exist.'

When trying to apply the patch in #62 I get:
error: patch failed: core/includes/bootstrap.inc:1675
error: core/includes/bootstrap.inc: patch does not apply

The patch is already committed so apply will definitely fail. Make sure your permissions as explained in install.txt are correct as that is the most frequent explanation for this misleading error message.

This got me through the installer.

Actually I can get through the installer without that, but was able to uncover another bug.

If you do everything correctly instead of emptying your database, you get the following error:

The service definition "feed.bridge.reader" does not exist.

That's due to #1839468: [Followup] Replace aggregator rss parsing with Zend Feed will post on there.

Okay patch attached fixes a couple of scenarios...

• If you have no writeable settings.php you get the expected error message telling you to copy the file.
• If you install drupal and then re copy default.settings.php to settings.php and get rid of sites/default/files but don't drop the db you get the expected drupal already installed if you enter the same db config as you did during your first install...

#103 gets me to the same point as #101 without the common.inc hunk.

The 'already installed' is still broken though - if you click 'visit your existing site' from that message you get this:

Fatal error: Call to undefined function _system_default_theme_features()

Partial backtace:

Drupal\Core\Controller\ExceptionController->on500Html() /Users/catch/Sites/8.x/core/lib/Drupal/Core/Controller/ExceptionController.php:57 0.4480 23956976 18. drupal_render() /Users/catch/Sites/8.x/core/lib/Drupal/Core/Controller/ExceptionController.php:262 0.4481 23958344 19. theme() /Users/catch/Sites/8.x/core/includes/common.inc:3806 0.4535 24804528 20. template_preprocess_maintenance_page() /Users/catch/Sites/8.x/core/includes/theme.inc:1065 0.4535 24805376 21. theme_get_setting() /Users/catch/Sites/8.x/core/includes/theme.inc:2924

That should definitely be a new issue though.

Would be good to get more testing of #103.

In my unscientific testing, the patch in #103 gets me through a full re-install after I had dumped and recreated the database. #101 didn't.

With the patch in #101 and a simple install where I failed to set permissions correctly I now get the the standard error messages about permissions instead of the mysterious

'Verify requirements : Requirements problem - The service definition "request" does not exist.'

If I select another language during install I now get:

"The translations directory does not exist.
The installer requires that you create a translations directory as part of the installation process. Create the directory sites/default/files/translations . More details about installing Drupal are available in INSTALL.txt."

This is again much better even though it hasn't told me that I have a permissions problems.

I get the same results with #103 in the same scenario. Possibly the error message for "The translations directory does not exist." should be updated to indicate the cause might be permissions problems.

#103: 1987262.install-errors.103.patch queued for re-testing.

I can't recreate the issues in #104 in the already installed step without doing something really weird...

Sure if you remove settings.php and use the same db config you'll get a message saying that drupal is already installed.... the issue now is that if you create a writeable settings.php how does it know what config directory location to write to it. I'm not sure how to solve this.

Yes man, of course I tried that. Eventually I even just ended up doing:

root@ip-10-37-136-20:/home/drupal8# chmod -R a+rwx www
root@ip-10-37-136-20:/home/drupal8# chown -R www-data:www-data www

But still the error message occurs (see: http://176.34.228.73/)

This was on installation on a FRESH aws amazon ubuntu server!

@bvanmeurs can you confirm that you have the patch applied from #103? And if possible detailed instructions of how to get this state with a clean clone of 8.x with this patch applied. Thanks for your help!

It seems that the message 'The service definition "request" does not exist.' always occurs if there is any requirement error! I added a 'var_dump($requirements);' at the top of the function 'install_display_requirements' and found out that I was missing some PHP extensions (PDO and gd). After fixing those requirements the installer did no longer complain about 'The service definition "request" does not exist.'.

There is something definately wrong in displaying the missing requirements.

The problem proces to be in drupal_requirements_url > drupal_current_script_url > drupal_get_query_parameters which fetches the get parameters from the currently active request. This seems te be impossible because the 'container' was not initialized at that point. I frankly don't know enough about Symfony to help with that. Probably it has to do with the bootstrap phase not being 'far' enough at that point. I'd suggest just using the $_GET array instead of the processed GETs from the request object. That fixes the problem, but I am unaware of any side effects.

Please ignore this patch, the patch from catch seems to work fine!

Hi Alex, the patch fixed my problems!

Marking #103 RTBC. Let's get that in then open follow-ups for anything else. We also likely need to bump fleshing out the installer tests to critical.

Assigning to Dries to commit #103 since I wrote it and @catch rtbc'd it :)

I was receiving this error on the 3rd step of the installer. core/install.php?langcode=en&profile=standard

After applying the patch it now says “The settings file does not exist.” MUCH BETTER!

I then tested it under 4 different scenarios:

• No sites/default/files directory
• sites/default/files doesn't have proper permissions
• No settings.php file
• settings.php doesn't have proper permissions

Without patch #103, any of the above give you the "The service definition 'request' does not exist." error message. With patch #103, you see the Requirements problem table describing the exact installation problem(s) and how you can fix them.

RTBC+1

Maybe Catch can commit it now that I've RTBC'ed it? :-D

We also likely need to bump fleshing out the installer tests to critical.

Which issue is that? I just wrote an installer test yesterday for #1887800: Add mobile friendly meta tags to the maintenance page. Fun! I think we need some refactoring so there's less code dupe, though.

I confirm the validity of patch #103 for settings.php permission message and missing/unwritable files directory.
It works for me...

RTBC +1 for patch at #103. Tested it same as John at #118, got the same requirements missing table. After having the requirements met, the installation went on smoothly.

Thanks for the extra RTBCs. Committed/pushed to 8.x.

Doesn't need to be assigned to Dries any more.