Another Fatal error: Out of memory

Greg,

Thank you for the quick reply.

I just can't get past the fact that Drush is saying that it (allocated 8126464) and (tried to allocate 24576 bytes) when it failed. These numbers are not anywhere near a 128M limit unless I am not understanding what these numbers are representing.

I would think that either:

a. the hosting provider is not allowing php to get 8126464+24576 bytes of memory, or

b. Drush is incorrectly reporting the memory that it is trying to allocate.

Is it possible have one of the first lines of the debug return what Drush thinks it has for PHP memory?

Actually, this all started because I am trying to upgrade core by hand and I wanted a list of all the installed modules so that I could turn them off until after the upgrade.

It would have been so nice to:

>drush sm | grep -i enabled > installed_modules.txt

So, I do find it ironic that to test why I cannot run drush sm, I need to turn the modules off by hand and then turn them on one at a time.

But, hey, if you can't laugh at yourself ..

Ah, at least MySQL didn't let me down:

To get a rough list of modules that were enabled:

mysql> SELECT name FROM system where status=1;
+-----------------------------+
| name                        |
+-----------------------------+
| advanced_help               |
| newsflash                   |
| system                      |
| block                       |
| dblog                       |
| filter                      |
| menu                        |
| node                        |
| path                        |
| profile                     |
| update                      |
| user                        |
| admin_menu                  |
| environment_indicator       |
| drupalforfirebug_preprocess |
| content                     |
| filefield                   |
| imagefield                  |
| views                       |
| views_ui                    |
| views_customfield           |
+-----------------------------+
21 rows in set (0.01 sec)

Sorry, I don't know how to read the version number out of the field.

Greg,

Sometimes ISPs limit the amount of RAM you can use

That's exactly what I'm trying to find out. How do you phrase that question to a hosting provider so that you don't get a automatic "we're not limiting RAM" response?

Okay, so a little depressing:

The only modules enabled are:

mysql> SELECT name FROM system where status=1;
+----------+
| name     |
+----------+
| system   |
| block    |
| filter   |
| node     |
| user     |
| minnelli |
+----------+
6 rows in set (0.01 sec)

And the output from CLI:

>drush st --debug
Found command: core-status (commandfile=core) [0.06 sec, 3.36 MB]    [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.06 sec,    [bootstrap]
3.38 MB]
Initialized Drupal 6.19 root directory at                               [notice]
/home/domain/public_html/drupal [0.07 sec, 4.18 MB]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.07 sec,    [bootstrap]
4.19 MB]
Initialized Drupal site domain.com at sites/domain.com [0.2   [notice]
sec, 4.4 MB]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.2 [bootstrap]
sec, 4.4 MB]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [0.2 sec, [bootstrap]
4.41 MB]
Successfully connected to the Drupal database. [0.2 sec, 4.41 MB]    [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.21 sec,    [bootstrap]
4.77 MB]
session_start(): Cannot send session cookie - headers already sent by[warning]
(output started at /home/domain/drush/includes/drush.inc:820)
bootstrap.inc:1162 [0.21 sec, 4.85 MB]
session_start(): Cannot send session cache limiter - headers already [warning]
sent (output started at /home/domain/drush/includes/drush.inc:820)
bootstrap.inc:1162 [0.21 sec, 4.85 MB]
Cannot modify header information - headers already sent by (output   [warning]
started at /home/domain/drush/includes/drush.inc:820)
bootstrap.inc:726 [0.21 sec, 4.98 MB]
Cannot modify header information - headers already sent by (output   [warning]
started at /home/domain/drush/includes/drush.inc:820)
bootstrap.inc:727 [0.21 sec, 4.98 MB]
Cannot modify header information - headers already sent by (output   [warning]
started at /home/domain/drush/includes/drush.inc:820)
bootstrap.inc:728 [0.21 sec, 4.98 MB]
Cannot modify header information - headers already sent by (output   [warning]
started at /home/domain/drush/includes/drush.inc:820)
bootstrap.inc:729 [0.21 sec, 4.98 MB]

Fatal error: Out of memory (allocated 8126464) (tried to allocate 95036 bytes) in /home/domain/public_html/drupal/includes/common.inc on line 2711
Drush command could not be completed. [0.25 sec, 7.51 MB]            [error]

Okay. I was troubleshooting the above posts on a dev multisite installation on my hosting provider's server. So I'm trying this on my own dev server (dev2) by grabbing:

• Drush 6.x-3.3
• Drupal 6.19

A quick install with the same php.ini file and alias and drush st works well. I would hope so or else the Issues queue would be full.

The next step is to grab my production environment as mentioned in #4.

I set up ~/.drush/website.aliases.drushrc.php

<?php
$aliases['dev'] = array(
  'root' => '/var/www/html/drupal/sites/dev2.website',
  'uri' => 'dev2.website',
  'db_url' => 'mysql://db_username:db_passpassword@localhost/db_website',
  'path-aliases' => array(
    '%dump' => '/home/website/.drush/dump/dev.sql',
    '%files' => '/home/website/.drush/dev/file',
  )
);

$aliases['prod'] = array(
  'root' => '/home/website/public_html/drupal/sites/dev.website',
  'uri' => 'dev.website',
  'remote-host' => 'dev.website',
  'remote-user' => 'username',
  'db_url' => 'mysql://db_username:db_password@localhost/db_website',
  'path-aliases' => array(
    '%dump' => '/home/website/.drush/dump/prod.sql',
    '%files' => '/home/website/.drush/prod/file',
  )
);

If I run >drush @prod @dev, I am getting:

>drush @prod @dev
The external command could not be executed due to an application     [error]
error.
The command could not be executed successfully (returned: Permission [error]
denied (publickey,gssapi-with-mic,password).
, code: 255)

Is the path_alias on the @prod (remote) site paths on that machine or on my local machine?

Actually, on second thought, where does the password for the remote (@prod) site go?

Getting there.

As you expected drush @prod status did not work. The rsync worked well. When I try to run the sql-sync on the @dev (local) server, I get:

>drush sql-sync @prod @dev --create-db --structure-tables-key=common
The command could not be executed successfully (returned: stdin: is  [error]
not a tty
bash: drush: command not found
, code: 127)
Error: no database record could be found for @prod                   [error]
An error occurred at function : drush_sql_sync                       [error]

Do I need to check my @prod alias?

I have to hand it to you; you are very patient (for now).

On the @dev server, the results from drush site-alias @dev --with-db --show-passwords is:

$aliases['dev'] = array (
  'root' => '/var/www/html/drupal/sites/dev2.website',
  'uri' => 'dev2.website',
  'db_url' => 'mysql://db_user:db_password@localhost/db_name',
  'path-aliases' =>
  array (
    '%dump' => '/home/website/.drush/dump/dev.sql',
    '%files' => '/home/website/.drush/dev/file',
  ),
  'databases' =>
  array (
  ),
);

There is no database information.

I needed to clean up a couple of things first:

• the paths in the dump and files directories need to exist
• the paths need to exist on the @prod and @dev servers as well (not just locally)

On the @dev server, after running: drush sql-sync @prod @dev --create-db --structure-tables-key=common

You will destroy data from drupal and replace with data from x.x.x.x/@dev.

You might want to make a backup first, using sql_dump command.

Do you really want to continue? (y/n): y
ERROR 1044 (42000) at line 1: Access denied for user 'dev_db_username'@'localhost' to database 'dev_dbname'

It looks like the @dev site is up and running. What could that last error be from?

Okay. Using the -s switch showed the echo command that was the equivalent of the following commands individually with mysql -hlocalhost -u[db_username] -p[db_password]:

• DROP DATABASE IF EXISTS db_website;
• CREATE DATABASE db_website;
• GRANT ALL PRIVILEGES ON db_website.* TO 'db_username'@'localhost' IDENTIFIED BY 'db_password';

Then the database is imported with:

mysql -hlocalhost -u[db_username] -p[db_password] db_website --silent < /home/website/.drush/dump/dev.sql

Shouldn't there be a FLUSH PRIVILEGES; after the GRANT?

Using --db-su and --db-su-pw at the end of the drush sql-sync worked.

To summarize:

• from #9, download drush and drupal
• from #9 and #15, created ~/.drush/website.aliases.drushrc.php (make sure to use db-url)
• from #13, run: drush site-alias @dev --with-db --show-passwords and add the 'databases' record to @prod
• make sure full paths to dump and files exists on bother the @dev and @prod servers
• from #11, if you have not set up an SSL public/private keys, run: drush dl drush_extras and then drush pushkey @prod
• from #11, run: drush rsync @prod @dev --include-conf to create the local site
• from #11, edit settings.php for the local server
• from #17, run drush sql-sync @prod @dev --create-db --structure-tables-key=common --db-su=privuser and --db-su-pw=secretpassword to copy the database
• changed to @dev directory and ran: drush cc all

I am not sure why drush @dev cc all did not work. It returned:

>drush @dev cc all
The directory /var/www/html/website/sites/dev2.website does not   [error]
contain a valid Drupal installation
Command cache-clear needs a higher bootstrap level to run - you will [error]
need invoke drush from a more functional Drupal environment to run
this command.
The drush command 'cc all' could not be executed.                    [error]

Oops.