Problem/Motivation

As pointed out in http://drupal.org/node/1986996 (community support forum) already, Drupal8/Spark throws an error during the early installation procedure, expressing that the service definition 'request' does not exist.

Steps to reproduce

  • Initialise D8 installation
  • Choose language
  • Create folder files with regular rights/permissions, e.g. 775 std-user:std-group (as requested by Drupal during step 'Verify requirements')
  • Refresh installation browser page (as requested by Drupal during step 'Verify requirements')

Results

"The service definition 'request' does not exist."

Proposed resolution

  • Short-term: Follow instructions provided in comment#13 by @the_phi.
  • Mid-term: Apply patch from comment#62. Start to evaluate and document the real/root/underlying error now!
  • Long-term: Install most current D8/Spark dev version (which includes the committed patch mentioned).

Remaining tasks

  • Evaluate whether drupal_chmod() needs modification/adaption. Depending on this decision, a new/separate issue needs to be launched.
  • Define the [potential] multiple source causes of this one end occurrence, which then need to be tackled individually. Depending on these findings, decide on how to proceed with the container (see comment#6 from @jewald) kicking in at a later stage in the process chain.

User interface changes

  • None known.

API changes


Original report (end part) by [the_phi]

After briefly checking the code I found that it is the Symfony framework which causes this error message. Below you will find an extraction of the particular code of the file ContainerBuilder.php in /core/vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/. Starting line is number 783, ending line is 803. It seems as if the called service was not defined or does not exist:

<?php
   
/**
     * Gets a service definition.
     *
     * @param string $id The service identifier
     *
     * @return Definition A Definition instance
     *
     * @throws InvalidArgumentException if the service definition does not exist
     *
     * @api
     */
   
public function getDefinition($id)
    {
       
$id = strtolower($id);

        if (!
$this->hasDefinition($id)) {
            throw new
InvalidArgumentException(sprintf('The service definition "%s" does not exist.', $id));
        }

        return
$this->definitions[$id];
    }
?>
Files: 
CommentFileSizeAuthor
#114 core-request-unavailable-1987262-113.patch523 bytesbvanmeurs
PASSED: [[SimpleTest]]: [MySQL] 56,919 pass(es).
[ View ]
#103 1987262.install-errors.103.patch1.41 KBalexpott
PASSED: [[SimpleTest]]: [MySQL] 57,019 pass(es).
[ View ]
#101 silly_services_stop_insssstalling.patch1.58 KBcatch
FAILED: [[SimpleTest]]: [MySQL] 57,009 pass(es), 41 fail(s), and 0 exception(s).
[ View ]
#71 installation-error-symfony-request-does-not-exist-1987262-71.patch730 bytesbshaffer
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch installation-error-symfony-request-does-not-exist-1987262-71.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#62 symfony-request-context-in-watchdog-bootstrap-1987262-62.patch1.23 KBthe_phi
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch symfony-request-context-in-watchdog-bootstrap-1987262-62.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#52 symfony-service-request-drupal-chmod-1987262-52.patch2 KBthe_phi
PASSED: [[SimpleTest]]: [MySQL] 56,104 pass(es).
[ View ]
#47 symfony-service-request-drupal-chmod-1987262-47.patch790 bytesthe_phi
PASSED: [[SimpleTest]]: [MySQL] 55,824 pass(es).
[ View ]
#44 1987262-44-drupal-chmod.patch510 bytesthe_phi
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1987262-44-drupal-chmod.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#43 1987262-request-context-in-watchdog.patch1.23 KBDamien Tournoud
FAILED: [[SimpleTest]]: [MySQL] 55,932 pass(es), 1 fail(s), and 0 exception(s).
[ View ]
#9 core-request-unavailable-1987262-9.patch780 bytesclemens.tolboom
PASSED: [[SimpleTest]]: [MySQL] 55,405 pass(es).
[ View ]

Comments

the_phi’s picture

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

... title improvement.

catch’s picture

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

the_phi’s picture

... nope!

jewald’s picture

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_phi’s picture

Right, @jewald#4: it was/is the lacking permissions on the 'files' folder, indeed! But, how should one [or especially a regular site-builder] know instantly? After all, octdec() (http://php.net/manual/en/function.octdec.php) is a PHP function — where's the obvious, instantly clear link to Symfony? Personal remark: I have, finally, found the time to start with Drupal8 & Symfony2! So the question here is: how did you find out so quickly? — Are you using the 'Symfony2 Dev Controller Switch' (https://addons.mozilla.org/en-US/firefox/addon/symfony2-debug-switch/) in combination with a dev front controller (see http://symfony.com/doc/current/book/controller.html)?

  • Anyhow, are the folder perms the only [potential] error source/trigger?
  • Another thing is that there's no accurate error/debug message from PHP accompanying the Symfony error message. I cannot live without PHP error/debug messages! I find they are a vital requirement. Any helpful ideas on this?
jewald’s picture

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.

clemens.tolboom’s picture

@jewald nice steps to follow along.

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

<?php
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

<?php
 Drupal
::request()->getClientIP();
?>

while setting the log entry:

<?php
    $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()?

clemens.tolboom’s picture

clemens.tolboom’s picture

Status:Active» Needs review
StatusFileSize
new780 bytes
PASSED: [[SimpleTest]]: [MySQL] 55,405 pass(es).
[ View ]

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

Is the extra message necessary?

clemens.tolboom’s picture

Status:Needs review» Needs work

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?

jewald’s picture

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.

decibel.places’s picture

Issue tags:+file permissions

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_phi’s picture

Assigned:the_phi» Unassigned
Priority:Critical» Major

... removing tags! @decibel.places: Before adding tags read the issue tag guidelines, please. Thank you, nevertheless, for posting your hint for Linux novices here!

Btw, to exactly those Linux novices: try to not use 777 permissions for folders unless really necessary. Rather use — in this case — 775 or even 770 together with the owner | group combination e.g. "main-user-foo | www-data/apache" (ownership bash command: chown main-user-foo:www-data sites/default/files. Attention: the exact overall permissions/rights depend on your system settings! This is just a generic example. @see http://linux.die.net/man/1/chown for Linux command chown.

Below a generic overall instruction set:

  1. chdir /var/www/drupal-root
  2. chown -R drupalpro:www-data sites/default/files
  3. Either ... or:
    • chmod -R 775 sites/default/files
    • find sites/default/files -type d -print0 | xargs -0 chmod 775 (more professional)

HINT#1:   depending on your system you might even have to add sudo (@see http://linux.die.net/man/8/sudo) before each permissions/rights command described above.
HINT#2:   are you in search for a complete, extensive Drupal development environment based on Linux? Consider the virtual machine resp. virtual appliance DrupalPro on http://drupal.org/project/drupalpro . Or, maybe, the Acquia Dev Desktop to be found on http://www.acquia.com/downloads .

[EDIT::add] See comment#23 of this issue as well.

the_phi’s picture

Issue summary:View changes

Updated issue summary.

catch’s picture

Issue tags:-file permissions

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’s picture

Priority:Major» Critical
clemens.tolboom’s picture

@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.

catch’s picture

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.

clemens.tolboom’s picture

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?

the_phi’s picture

... @catch#17: after checking http://api.drupal.org/.../drupal_mkdir/8 a bit more thoroughly I see what you mean ("low-level PHP wrapper"). Your argument sounds logical to me. But this would mean to modify drupal_mkdir(). What would, foreseeably, be the consequences of such a change?

catch’s picture

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.

the_phi’s picture

Btw, for all those who have just started freshly with D8 (like me) & are curious about the fundamentals of this whole issue, please @see http://symfony.com/doc/current/book/service_container.html which tackles the subject of the "Service Container" in the underlying PHP framework Symfony. And there is http://api.drupal.org/api/drupal/core%21vendor%21symfony%21dependency-in... as well which seems to be quite revealing/informative.

jewald’s picture

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.

the_phi’s picture

Issue summary:View changes

(ps) Cleaned up the mess.

the_phi’s picture

... @jewald#22: permissions are generally a bit of a challenge (i.e. overview). I therefore refer to the perms/rights settings of the common Drupal Virtual Development Environment DrupalPro (Linux, Ubuntu 12.04 LTS; http://drupal.org/project/drupalpro). Here the standard settings of folders | files in /var/www are: '775 | 664'. Owner | group: 'drupalpro | drupalpro' . So, the user & group ownership situation was — during my installation procedure — the same as yours; just with a different name, obviously. Not the access permissions, though!

However, even with a more permissive 775 on an already [during installation] existing sites/default/files it is not possible for Apache (www-data) to claim the group ownership of this folder since only the user owner (not the group owner!) is allowed to do this.

  • The best would be, from my perspective, to let Drupal create the files folder itself. But this must fail since www-data (or apache or something else, depending on the operating system) does not have the access permissions to generate a folder.

Access Permissions and Ownership Best Practise

Best practice, in essence, recommends for production (and dev) environments
- 750 (dir) and 640 (files) & drupalpro:www-data generally,
- 770 (dir) and 660 (files) & drupalpro:www-data specifically for the files folder and its sub-folders.
Note: the documentation is not absolutely consistent on that!


drupal_chmod()

- Considering the tough best practises (documentation), it would make sense to adjust the API function drupal_chmod()! Why is the default-default in there 775 and 664? To be on the safe side (i.e. due to OS diversity)? However, these settings are not recommended and contradict the guidlines.
- @catch pointed something else out in his comment#17. So my first point, mentioned above, might not even be the only potential change within/in this function.

the_phi’s picture

Issue summary:View changes

(the_phi) Revising according the Issue Summary Template.

the_phi’s picture

Issue summary updated.

the_phi’s picture

Issue summary:View changes

Updated issue summary.

the_phi’s picture

Issue summary:View changes

Updated issue summary.

the_phi’s picture

Issue summary:View changes

Updated issue summary.

the_phi’s picture

Issue summary:View changes

Updated issue summary.

the_phi’s picture

Cannot really decide whether to tag this issue as/with 'Configuration system'! Any advice?

clemens.tolboom’s picture

Status:Needs work» Closed (duplicate)

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.

the_phi’s picture

Assigned:Unassigned» the_phi
Status:Closed (duplicate)» Needs work

... Clemens, although I, too, would like to close the issue [for general efficiency reasons], closing it now — before finding the essential answers to the questions defined in #summary-remaining-tasks — would be wrong as well. Let us, in a first step, try to find two very clear answers to the two task-questions posed in the summary! From everyone please, especially @catch. I'd like to read more about how he would proceed.
Btw, I am willing to put a bit time into sorting things thoroughly out (i.e. launching separate/new issues, more code digging or adding infos to related issues).

Anthony Fok’s picture

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!

Anthony Fok’s picture

Issue summary:View changes

Updated issue summary.

the_phi’s picture

Issue summary:View changes

Updated issue summary.

the_phi’s picture

Issue summary:View changes

Updated issue summary.

dcrocks’s picture

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.

the_phi’s picture

Assigned:Unassigned» the_phi
Priority:Major» Critical

... @dcrocks#29: I briefly went through a current D8 installation (Drupal 8.x-dev 2013-05-20) before. I am still getting exactly the same InvalidArgumentException from the Symfony framework as described initially in the issue summary.

What access permissions and ownership rights did you give your 'files' folder? - I am asking since this is one of the pristine causes of the whole error stack (with Symfony complaining at the very end).

dcrocks’s picture

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.

the_phi’s picture

... what about the user and the group ownership of 'files'?

clemens.tolboom’s picture

@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?

clemens.tolboom’s picture

Issue summary:View changes

Updated issue summary.

the_phi’s picture

... thanks, @Clemens! Let's see what overall data comes together.

clemens.tolboom’s picture

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.

dcrocks’s picture

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.

the_phi’s picture

... @clemens.tolboom#36: 100%, yep ('root cause')!

Btw, do you understand why the two functions

link to different 'configs'? The former to public static function Drupal::config (OO, a static method), the latter to function config (procedural, a classical function) . Seems like the latter will have to be modified since it makes use of the deprecated drupal_container() (note, there are currently 221 calls to this function!).

the_phi’s picture

... @dcrocks#37: [EDIT::del] I referred to your MySQL installation. Since if here the settings on 'files' are permissive enough, you won't get an error message. Your SQLite issue seems to be caused by a different root cause.

dcrocks’s picture

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'.

clemens.tolboom’s picture

@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

the_phi’s picture

re: #40 Since your SQLite issue seems to be caused by a different root/underlying problem (see edited comment above), try to install the debugging tools mentioned in comment#6 by @jewald. To backtrace thoroughly he made use of PHPStorm and xDebug. Since the Symfony error message prevents us from getting to know more details about the real/underlying/root problem, this seems to be the only recommendable thing to do to me, currently.

Maybe later on the error descriptions will improve? I, myself, will have to install/configure the mentioned debugging/tracing tools first. And, gather more knowledge about Symfony first.

Damien Tournoud’s picture

Assigned:the_phi» Unassigned
Status:Needs work» Needs review
StatusFileSize
new1.23 KB
FAILED: [[SimpleTest]]: [MySQL] 55,932 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

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

the_phi’s picture

StatusFileSize
new510 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1987262-44-drupal-chmod.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Has anyone here maintainer permissions (Git) for D8? Me not. But changing drupal_chmod() would be as easy as done/seen in the attached patch!

Status:Needs review» Needs work

The last submitted patch, 1987262-44-drupal-chmod.patch, failed testing.

the_phi’s picture

... well done, @Damien. You obviously checked comment#7 from @Clemens, and you seem to have understood something clearer than the rest of us. I (D8 and Symfony noob, btw) promise to check your patch#43 asap.

the_phi’s picture

StatusFileSize
new790 bytes
PASSED: [[SimpleTest]]: [MySQL] 55,824 pass(es).
[ View ]

Here the proper Git patch for drupal_chmod(). Sorry for the reduced one from before in #44.
Note: this patch just updates the function, it doesn't get rid of Symfony's InvalidArgumentException!

And, bear in mind comment#17 from @catch, too:

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

the_phi’s picture

Status:Needs work» Reviewed & tested by the community

#43 works for me. Thanks, @Damian.

Changing issue status, even though the whole issue covers a broader area, actually. I will triage (oh, a medical expression in English) later, okay everyone?

clemens.tolboom’s picture

Status:Reviewed & tested by the community» Needs work

@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.

dcrocks’s picture

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...

the_phi’s picture

... @dcrocks: This is your underlying/root cause (SQLite), with which you can proceed further now (i.e. new issue!). The patch from #43 works well, apparently. And, it indicates a lot of try ... catch-work will need to be done, now that we have the Symfony-Drupal (and a few more) synthesis. But this is, surely, not a new illumination for the D8-hardcorers.

the_phi’s picture

Status:Needs work» Needs review
StatusFileSize
new2 KB
PASSED: [[SimpleTest]]: [MySQL] 56,104 pass(es).
[ View ]

Both patches (#43 and #47) united, as requested by @Clemens.
Btw, could someone here give me D8 core commit perms/rights, please? :) I'd love to commit this directly, if you all allow/agree.

fubhy’s picture

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

catch’s picture

-      $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.

the_phi’s picture

re #53: Oh, my poor EGO feels terribly hurt now ;) Anyway, I cannot find @fubhy on the core-committers list (http://drupal.org/node/3060/committers) either, which is kind of calming for my mind :P

the_phi’s picture

... @catch: You mean it should look ~ like this

<?php
  $mode
= octdec(Settings::get('chmod.directory');
?>
catch’s picture

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

the_phi’s picture

... alrighty, according to http://drupal.org/node/1882698 :

<?php
  $mode
= octdec(settings()->get('chmod_directory'));
?>
  1. Why not Settings::get() as described on http://api.drupal.org/api/.../Settings/8?
  2. Shall I extend 'settings.php' with $settings['chmod_directory']? If yes, with perm values in octal, really? Why not decimal straight away!?!
  3. Last but not least, what about comment#23 (drupal_chmod())?
clemens.tolboom’s picture

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.

the_phi’s picture

... sounds reasonable, @Clemens.

  • I don't know why my patch passed but Damien's one failed. However, I am willing to re-generate his patch.
  • Regarding your issue #1908440 mentioned above: umask() doesn't sound like a great function. Even the PHPers don't seem to be fond of it!
jaredsmith’s picture

Status:Needs review» Needs work

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.

the_phi’s picture

Status:Needs work» Needs review
StatusFileSize
new1.23 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch symfony-request-context-in-watchdog-bootstrap-1987262-62.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

This here should actually pass now.
After this I am going to launch a separate task for drupal_chmod().

catch’s picture

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

catch’s picture

Issue summary:View changes

Added more related items

the_phi’s picture

Issue summary:View changes

Resolution update.

the_phi’s picture

Issue summary:View changes

Resolution update.

the_phi’s picture

  • #62-patch passed this time -- good! The issue summary ('proposed resolution') was updated accordingly.
    @Clemens (or someone else with a bit of time): can you 'review & test' it and, afterwards, switch the issue to status 'patch (to be ported)', please?
  • @catch#63: wouldn't it be optimal to augment the real 'settings.php' first (with '0750'; according to guidlines, see comment#23) for general [user-adaptable] purposes, but use settings()->get('chmod_directory', '0775') ('0770' could, even though defined this way in the guidlines, cause problems for world-accessers, I tend to guess) specifically for the 'files' folder? In this case, the call would be suboptimal since it got its non-default values in first instance from the settings file (the generic value). Hm ...
  • However, as soon as the working patch will be commited I am going to launch a new issue concerning drupal_chmod().
clemens.tolboom’s picture

Status:Needs review» Reviewed & tested by the community

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

the_phi’s picture

GREAT COMMUNITY WORK!
Just by looking at this very issue one learns to understand why it is that Drupal's ecosystem is prospering. Well, correct, I am blending out the occassional humane occurences, which are, however, typical & common for fleshly humans everywhere ;)
And now back to regular work (*sad*) !!!

catch’s picture

Status:Reviewed & tested by the community» Needs work

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.

Damien Tournoud’s picture

Status:Needs work» Reviewed & tested by the community

@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.

catch’s picture

Status:Reviewed & tested by the community» Needs work

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

Damien Tournoud’s picture

@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).

bshaffer’s picture

Status:Needs work» Needs review
StatusFileSize
new730 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch installation-error-symfony-request-does-not-exist-1987262-71.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

Damien Tournoud’s picture

@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.

killua99’s picture

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.

killua99’s picture

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
dcrocks’s picture

@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.

adamcowboy’s picture

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)

killua99’s picture

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

dcrocks’s picture

@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.

dcrocks’s picture

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.

quicksketch’s picture

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.

Damien Tournoud’s picture

Status:Needs review» Reviewed & tested by the community

Could we get #62 in, please?

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

ParisLiakos’s picture

i am +1 for #62 too

alexpott’s picture

Status:Reviewed & tested by the community» Fixed

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

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

clemens.tolboom’s picture

pfew and thanks :)

the_phi’s picture

w00t!!!

Aritas’s picture

Still here on drupal8-alpha2.

catch’s picture

Status:Fixed» Active

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.

chertzog’s picture

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

fgrossin’s picture

Status:Active» Needs review
fgrossin’s picture

Status:Needs review» Needs work

The last submitted patch, installation-error-symfony-request-does-not-exist-1987262-71.patch, failed testing.

clemens.tolboom’s picture

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’s picture

@fgrossin#89: Strange, when I first posted the patch#62 (#1987262-62: [Installation Error] Symfony: "The service definition 'request' does not exist.") it passed. Back then, the light was on green! Why is it on red all of a sudden? Did this happen after the re-testing?

catch’s picture

@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.

clemens.tolboom’s picture

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

fgrossin’s picture

@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 ?

dcrocks’s picture

@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.

dcrocks’s picture

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.

bvanmeurs’s picture

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

dcrocks’s picture

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.

catch’s picture

Status:Needs work» Needs review
StatusFileSize
new1.58 KB
FAILED: [[SimpleTest]]: [MySQL] 57,009 pass(es), 41 fail(s), and 0 exception(s).
[ View ]

This got me through the installer.

catch’s picture

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.

alexpott’s picture

StatusFileSize
new1.41 KB
PASSED: [[SimpleTest]]: [MySQL] 57,019 pass(es).
[ View ]

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...
catch’s picture

#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.

yoroy’s picture

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.

dcrocks’s picture

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.

dcrocks’s picture

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.

Status:Needs review» Needs work

The last submitted patch, 1987262.install-errors.103.patch, failed testing.

catch’s picture

Status:Needs work» Needs review

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

alexpott’s picture

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.

bvanmeurs’s picture

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!

alexpott’s picture

@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!

bvanmeurs’s picture

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.

bvanmeurs’s picture

StatusFileSize
new523 bytes
PASSED: [[SimpleTest]]: [MySQL] 56,919 pass(es).
[ View ]

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

bvanmeurs’s picture

Hi Alex, the patch fixed my problems!

catch’s picture

Status:Needs review» Reviewed & tested by the community

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.

alexpott’s picture

Assigned:Unassigned» Dries

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

JohnAlbin’s picture

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.

fgrossin’s picture

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

AjitS’s picture

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.

catch’s picture

Status:Reviewed & tested by the community» Fixed

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

effulgentsia’s picture

Assigned:Dries» Unassigned

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

Status:Fixed» Closed (fixed)

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

the_phi’s picture

Whew!

the_phi’s picture

Issue summary:View changes

Resolution update (formatting).