Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
We are seeing random fails in the first tests run - see https://www.drupal.org/pift-ci-job/477829.
nstall_begin_request
exception: [Uncaught exception] Line 493 of core/includes/install.core.inc:
Drupal\Core\Installer\Exception\AlreadyInstalledException:
To start over, you must empty your existing database and copy default.settings.php over settings.php.
To upgrade an existing installation, proceed to the update script.
View your existing site.
in install_begin_request() (line 493 of /var/www/html/core/includes/install.core.inc). install_begin_request(Object, Array) (Line: 112)
install_drupal(Object, Array) (Line: 485)
Drupal\simpletest\WebTestBase->doInstall() (Line: 457)
Drupal\simpletest\WebTestBase->setUp() (Line: 33)
Drupal\aggregator\Tests\AggregatorTestBase->setUp() (Line: 1049)
Drupal\simpletest\TestBase->run(Array) (Line: 744)
simpletest_script_run_one_test('29', 'Drupal\aggregator\Tests\DeleteFeedTest') (Line: 65)
This potentially could be related to #728702: Visiting index.php should redirect to install.php if settings.php already has database credentials but database is empty.
Comments
Comment #2
alexpottTrying to make a patch that exposes the problem quickly.
Comment #3
alexpottMaybe 31 tests is not enough ... bumping 62.
Comment #4
alexpottDiscussed a bit of @mixologic - test bots are reused so maybe something is going on here. However if artefacts are left around then maybe that's what is causing this.
However thinking about this a bit more maybe what is occurring is if a bot has a failed test and then the next run might get this bug.
Comment #5
alexpottI think we should call run-tests.sh at the start of test run to ensure that environment is clean. Unfortunately I just broke it.
Comment #6
alexpottSee #2807171: Use the correct testing table prefix in simpletest_clean_database()
Comment #7
alexpottAnother case https://dispatcher.drupalci.org/job/php7_sqlite3.8/2041/consoleFull - interesting this looks like another first use of a bot. Maybe we've go an error that only occurs on the first usage of a bot???
Comment #8
alexpottDiscussed with @catch, @cottser, @webchick, @xjm, @effulgentsia, and @cilefen. We agreed to keep this critical because random fails are a critical bug. Re-titling so the hypothetical cause is not in the title.
Comment #9
borisson_If it helps to have additional data, I had this failure on the facet tests yesterday https://www.drupal.org/pift-ci-job/518158
Comment #10
andypostI think this comment should tell why 62 and not 42)
Comment #11
xjmComment #12
mikeryanHere's one from a sibling random fail (#2823400: Random fail in CopyFileTest): https://www.drupal.org/pift-ci-job/541462
Comment #13
mikeryanHappened twice with the same combo - 8.2.x/PHP 5.5/SQLite: https://www.drupal.org/pift-ci-job/541462
Comment #14
mikeryanSorry, never mind, second one did pass (the original fail was not cleared).
Comment #15
alexpottAccording to @mixologic a new build of DrupalCI has just been put in place that guarantees new database containers for every test. I wonder if that will make this go away.
Comment #16
MixologicLooks like it didnt. Over in https://www.drupal.org/node/2828559#comment-11857218 there was a battery of tests, and https://www.drupal.org/pift-ci-job/569192 popped up in that battery. So, completely fresh db containers/db directories didnt solve alreadyinstalled exception.
This seems like its some sort of race condition that is somehow getting the same dbname/number for different runs of the children of run-tests.sh.
Comment #17
alexpottThe thing is - the database name is generated using a symlink - see \Drupal\Core\Test\TestDatabase::getTestLock(). A symlink is one of the 2 guaranteed blocking file operations so we are dealing with concurrency here.
Comment #19
arunkumarkHi,
I have re-rolled the patch for latest Drupal 8.4.x version.
Comment #20
alexpottHas anyone actually seen this error recently? I've not seen it in quite a while and it used to be quite frequent.
Comment #21
MixologicThis is the most recent example I can find:
https://dispatcher.drupalci.org/job/drupal_patches/89/
And some other somewhat recentish examples:
https://dispatcher.drupalci.org/job/php7_sqlite3.8/2806/
https://dispatcher.drupalci.org/job/default/311093/
https://dispatcher.drupalci.org/job/php5.5_sqlite3.8/1649
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedhttps://www.drupal.org/pift-ci-job/626952
Comment #23
mondrakehttps://www.drupal.org/pift-ci-job/655711
Comment #25
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedWe haven't seen this in branch tests since the 13th of March: https://www.drupal.org/pift-ci-job/749685 -> https://www.drupal.org/pift-ci-job/620178
I think it's pretty safe to downgrade it from critical.
Comment #26
gambryThis is killing me for work-related development. I'm assuming it's a weirdness due the combination Jenkins + Docker.
It may be related to docker storage process (improved within last year, which could be the reason for #25) + Jenkins not cleaning the workspace as it's supposed to do ( i.e. https://issues.jenkins-ci.org/browse/JENKINS-41805 ).
But there may be something else as really none of them fully explain the exception.
Comment #28
MixologicIm pretty sure that we solved this over in https://www.drupal.org/project/drupal/issues/2906317, so, hooray!
Comment #29
catchMarking this as duplicate of that issue.
Comment #30
gambryI can't find what has been changed as part of #2906317: Random fail due to problems with database , or any related work.
Last saturday I managed to see an AlreadyInstalledException issue again. It wasn't my machine so I can't give more info, but we manage to make it disappearing by properly set the permissions on folders sites, sites/simpletest and the one in
BROWSERTEST_OUTPUT_DIRECTORY
.I promised myself to try to replicate it, thinking it was just a misleading error caused by something else. But now wondering if something has been fixed upstream?
Comment #31
gambryI found these potential works/solutions in that issue:
- #2939026: Installer does not fix the database connection after creating the database on MySQL
- #2817833: Delay sql map table creation
Thanks!
Comment #32
xjm