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
- Possibly
drupal_chmod()
Related issues
- #944582: ./sites/default/files directory permission check is incorrect during install AND status report (affects Docker on Windows)
- #1845646: error_displayable() cannot be converted from variable system safely
- #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
- #1998366: [meta] SQLite is broken
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:
/**
* 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];
}
Comments
Comment #1
Blooniverse CreditAttribution: Blooniverse commented... title improvement.
Comment #2
catchAre you trying to install in a language other than English? If so I think there's already a bug report for that.
Comment #3
Blooniverse CreditAttribution: Blooniverse commented... nope!
Comment #4
jewald CreditAttribution: jewald commentedThis 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.
Comment #5
Blooniverse CreditAttribution: Blooniverse commentedRight, @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)?Comment #6
jewald CreditAttribution: jewald commentedThe 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.
Call to config("system.file") immediately calls drupal_container. Note that this call is deprecated.
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.
Comment #7
clemens.tolboom@jewald nice steps to follow along.
file.inc tries to chmod silently and fails to do so.
next the watchdog line is called. That call introduces an exception trying to
Drupal::request()->getClientIP();
while setting the log entry:I'm not sure why the static call the get the request fails through Drupal::request()?
Comment #8
clemens.tolboomSee #1974570: The service container is used before it's set in the drupal error handler for the cause I guess.
Comment #9
clemens.tolboomThe patch wraps the call to file_prepare_directory in a try catch and adds a message.
Is the extra message necessary?
Comment #10
clemens.tolboomHmmm 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?
Comment #11
jewald CreditAttribution: jewald commentedThe 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.
Comment #12
decibel.places CreditAttribution: decibel.places commentedthe 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 ;)
Comment #13
Blooniverse CreditAttribution: Blooniverse commented... 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 permissionsfor 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 commandchown
.Below a generic overall instruction set:
chdir /var/www/drupal-root
chown -R drupalpro:www-data sites/default/files
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.
Comment #13.0
Blooniverse CreditAttribution: Blooniverse commentedUpdated issue summary.
Comment #14
catchThe problem is with the call to config itself I think. There's no UI setting for this, so why not move it to $settings?
Comment #15
catchComment #16
clemens.tolboom@catch I don't get it.
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.
Comment #17
catchI mean drupal_mkdir() is supposed to be a low-level PHP wrapper, it shouldn't have a dependency on the configuration system at all.
Comment #18
clemens.tolboomIC ... 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() flowclemens$ chmod 777 files
let the installer do it's expected job@jewald did you do something different?
Comment #19
Blooniverse CreditAttribution: Blooniverse commented... @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?Comment #20
catchPutting 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.
Comment #21
Blooniverse CreditAttribution: Blooniverse commentedBtw, 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.
Comment #22
jewald CreditAttribution: jewald commentedIn 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.
Comment #22.0
Blooniverse CreditAttribution: Blooniverse commented(ps) Cleaned up the mess.
Comment #23
Blooniverse CreditAttribution: Blooniverse commented... @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.
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.
Comment #23.0
Blooniverse CreditAttribution: Blooniverse commented(the_phi) Revising according the Issue Summary Template.
Comment #24
Blooniverse CreditAttribution: Blooniverse commentedIssue summary updated.
Comment #24.0
Blooniverse CreditAttribution: Blooniverse commentedUpdated issue summary.
Comment #24.1
Blooniverse CreditAttribution: Blooniverse commentedUpdated issue summary.
Comment #24.2
Blooniverse CreditAttribution: Blooniverse commentedUpdated issue summary.
Comment #24.3
Blooniverse CreditAttribution: Blooniverse commentedUpdated issue summary.
Comment #25
Blooniverse CreditAttribution: Blooniverse commentedCannot really decide whether to tag this issue as/with 'Configuration system'! Any advice?
Comment #26
clemens.tolboomAfter 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.
Comment #27
Blooniverse CreditAttribution: Blooniverse commented... 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).
Comment #28
Anthony Fok CreditAttribution: Anthony Fok commentedI wonder if anyone has tried installing Drupal 8 with SQLite?
I ran into the same
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!
Comment #28.0
Anthony Fok CreditAttribution: Anthony Fok commentedUpdated issue summary.
Comment #28.1
Blooniverse CreditAttribution: Blooniverse commentedUpdated issue summary.
Comment #28.2
Blooniverse CreditAttribution: Blooniverse commentedUpdated issue summary.
Comment #29
dcrocks CreditAttribution: dcrocks commentedI 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.
Comment #30
Blooniverse CreditAttribution: Blooniverse commented... @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).
Comment #31
dcrocks CreditAttribution: dcrocks commentedI run this script after loading the distribution into my "Sites/drupal8" directory:
I then start the install from my web browser. The permissions on 'Sites/drupal8/sites/default' at the time of failure are:
The 'files' directory is empty.
Comment #32
Blooniverse CreditAttribution: Blooniverse commented... what about the user and the group ownership of 'files'?
Comment #33
clemens.tolboom@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?Comment #33.0
clemens.tolboomUpdated issue summary.
Comment #34
clemens.tolboomAdded 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
Comment #35
Blooniverse CreditAttribution: Blooniverse commented... thanks, @Clemens! Let's see what overall data comes together.
Comment #36
clemens.tolboomI'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.
Comment #37
dcrocks CreditAttribution: dcrocks commentedre: #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.
Comment #38
Blooniverse CreditAttribution: Blooniverse commented... @clemens.tolboom#36: 100%, yep ('root cause')!
Btw, do you understand why the two functions
error_displayable()
resp._drupal_get_error_level()
drupal_chmod()
link to different 'configs'? The former to
public static function Drupal::config
(OO, a static method), the latter tofunction config
(procedural, a classical function) . Seems like the latter will have to be modified since it makes use of the deprecateddrupal_container()
(note, there are currently 221 calls to this function!).Comment #39
Blooniverse CreditAttribution: Blooniverse commented... @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.Comment #40
dcrocks CreditAttribution: dcrocks commentedre: #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'.
Comment #41
clemens.tolboom@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
Comment #42
Blooniverse CreditAttribution: Blooniverse commentedre: #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.
Comment #43
Damien Tournoud CreditAttribution: Damien Tournoud commentedLet's at least fix the bug that hides the underlying issues.
Comment #44
Blooniverse CreditAttribution: Blooniverse commentedHas anyone here maintainer permissions (Git) for D8? Me not. But changing
drupal_chmod()
would be as easy as done/seen in the attached patch!Comment #46
Blooniverse CreditAttribution: Blooniverse commented... 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.
Comment #47
Blooniverse CreditAttribution: Blooniverse commentedHere 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:
Comment #48
Blooniverse CreditAttribution: Blooniverse commented#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?
Comment #49
clemens.tolboom@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.
Comment #50
dcrocks CreditAttribution: dcrocks commentedTried 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...
Comment #51
Blooniverse CreditAttribution: Blooniverse commented... @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.Comment #52
Blooniverse CreditAttribution: Blooniverse commentedBoth 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.
Comment #53
fubhy CreditAttribution: fubhy commentedYeah, umh... That's not gonna happen :P
Comment #54
catchThe 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.
Comment #55
Blooniverse CreditAttribution: Blooniverse commentedre #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
Comment #56
Blooniverse CreditAttribution: Blooniverse commented... @catch: You mean it should look ~ like this
Comment #57
catchhttp://drupal.org/node/1882698 has docs for the settings api.
Comment #58
Blooniverse CreditAttribution: Blooniverse commented... alrighty, according to http://drupal.org/node/1882698 :
Settings::get()
as described on http://api.drupal.org/api/.../Settings/8?$settings['chmod_directory']
? If yes, with perm values in octal, really? Why not decimal straight away!?!drupal_chmod()
)?Comment #59
clemens.tolboomIn #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.
Comment #60
Blooniverse CreditAttribution: Blooniverse commented... sounds reasonable, @Clemens.
umask()
doesn't sound like a great function. Even the PHPers don't seem to be fond of it!Comment #61
jaredsmith CreditAttribution: jaredsmith commentedFor 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.
Comment #62
Blooniverse CreditAttribution: Blooniverse commentedThis here should actually pass now.
After this I am going to launch a separate task for
drupal_chmod()
.Comment #63
catchYou can add the default for chmod_directory in the settings call: settings()->get('chmod_directory', '0775').
Comment #63.0
catchAdded more related items
Comment #63.1
Blooniverse CreditAttribution: Blooniverse commentedResolution update.
Comment #63.2
Blooniverse CreditAttribution: Blooniverse commentedResolution update.
Comment #64
Blooniverse CreditAttribution: Blooniverse commented@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?
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 ...drupal_chmod()
.Comment #65
clemens.tolboomPatch 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
Comment #66
Blooniverse CreditAttribution: Blooniverse commentedGREAT 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*) !!!
Comment #67
catchWe 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.
Comment #68
Damien Tournoud CreditAttribution: Damien Tournoud commented@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.
Comment #69
catch@Damien, please explain how watchdog will work when there's no bootstrap modules loaded.
Comment #70
Damien Tournoud CreditAttribution: Damien Tournoud commented@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)
.Comment #71
bshaffer CreditAttribution: bshaffer commentedThe 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 trueNo interdiff included because this is a new approach
Comment #72
Damien Tournoud CreditAttribution: Damien Tournoud commented@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.
Comment #73
killua99 CreditAttribution: killua99 commentedThe 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.
Comment #74
killua99 CreditAttribution: killua99 commentedThis is the trace I have.
Comment #75
dcrocks CreditAttribution: dcrocks commented@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.
Comment #76
adamcowboy CreditAttribution: adamcowboy commentedI 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)
Comment #77
killua99 CreditAttribution: killua99 commentedSo, can be the PHP version? I have 5.4.x ubuntu 13.05 repo .... but I don't want to downgrade it.
Comment #78
dcrocks CreditAttribution: dcrocks commented@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.
Comment #79
dcrocks CreditAttribution: dcrocks commentedIs 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.
Comment #80
quicksketchYep, 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.
Comment #81
Damien Tournoud CreditAttribution: Damien Tournoud commentedCould we get #62 in, please?
The only result of waiting is more people reporting random, independent installation-related bugs in this issue.
Comment #82
ParisLiakos CreditAttribution: ParisLiakos commentedi am +1 for #62 too
Comment #83
alexpottThis seems like a good idea... reporting the real error will be a great help :)
Committed 547b874 and pushed to 8.x. Thanks!
Comment #84
clemens.tolboompfew and thanks :)
Comment #85
Blooniverse CreditAttribution: Blooniverse commentedw00t!!!
Comment #86
Aritas CreditAttribution: Aritas commentedStill here on drupal8-alpha2.
Comment #87
catchYes 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.
Comment #88
chertzogif settings.php doesnt exist or isnt writable, this error comes up.
Comment #89
fgrossin CreditAttribution: fgrossin commented#62: symfony-request-context-in-watchdog-bootstrap-1987262-62.patch queued for re-testing.
Comment #90
fgrossin CreditAttribution: fgrossin commented#71: installation-error-symfony-request-does-not-exist-1987262-71.patch queued for re-testing.
Comment #92
clemens.tolboomWhy 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
Comment #93
Blooniverse CreditAttribution: Blooniverse commented@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?
Comment #94
catch@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.
Comment #95
clemens.tolboom@catch ic ... I completely missed #62 was committed :/
Comment #96
fgrossin CreditAttribution: fgrossin commented@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 ?
Comment #97
dcrocks CreditAttribution: dcrocks commented@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.
Comment #98
dcrocks CreditAttribution: dcrocks commentedCould 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.
Comment #99
bvanmeurs CreditAttribution: bvanmeurs commentedgit 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
Comment #100
dcrocks CreditAttribution: dcrocks commentedThe 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.
Comment #101
catchThis got me through the installer.
Comment #102
catchActually 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:
That's due to #1839468: [Followup] Replace aggregator rss parsing with Zend Feed will post on there.
Comment #103
alexpottOkay patch attached fixes a couple of scenarios...
Comment #104
catch#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:
That should definitely be a new issue though.
Would be good to get more testing of #103.
Comment #105
yoroy CreditAttribution: yoroy commentedIn 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.
Comment #106
dcrocks CreditAttribution: dcrocks commentedWith 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.
Comment #107
dcrocks CreditAttribution: dcrocks commentedI 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.
Comment #109
catch#103: 1987262.install-errors.103.patch queued for re-testing.
Comment #110
alexpottI 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.
Comment #111
bvanmeurs CreditAttribution: bvanmeurs commentedYes 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!
Comment #112
alexpott@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!
Comment #113
bvanmeurs CreditAttribution: bvanmeurs commentedIt 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.
Comment #114
bvanmeurs CreditAttribution: bvanmeurs commentedPlease ignore this patch, the patch from catch seems to work fine!
Comment #115
bvanmeurs CreditAttribution: bvanmeurs commentedHi Alex, the patch fixed my problems!
Comment #116
catchMarking #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.
Comment #117
alexpottAssigning to Dries to commit #103 since I wrote it and @catch rtbc'd it :)
Comment #118
JohnAlbinI 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:
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
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.
Comment #119
fgrossin CreditAttribution: fgrossin commentedI confirm the validity of patch #103 for settings.php permission message and missing/unwritable files directory.
It works for me...
Comment #120
AjitSRTBC +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.
Comment #121
catchThanks for the extra RTBCs. Committed/pushed to 8.x.
Comment #122
effulgentsia CreditAttribution: effulgentsia commentedDoesn't need to be assigned to Dries any more.
Comment #124
Blooniverse CreditAttribution: Blooniverse commentedWhew!
Comment #124.0
Blooniverse CreditAttribution: Blooniverse commentedResolution update (formatting).