Send support mailing list submissions to
support@drupal.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.drupal.org/mailman/listinfo/support
or, via email, send a message with subject or body 'help' to
support-request@drupal.org
You can reach the person managing the list at
support-owner@drupal.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of support digest..."
Today's Topics:
1. Re: Memory error (Waprothero@gmail.com)
2. Re: Problem getting Drupal mail (Waprothero@gmail.com)
3. Upgrade from 7.16 to 7.22 (lamp@afan.net)
4. Re: Upgrade from 7.16 to 7.22 (Bob@TurnerPCC.com)
5. Memory error (Roger)
6. Re: Memory error (Waprothero@gmail.com)
7. Re: Memory error (Jamie Holly)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Apr 2013 09:31:35 -0700
From: "Waprothero@gmail.com" <waprothero@gmail.com>
Subject: Re: [support] Memory error
To: "support@drupal.org" <support@drupal.org>, Nancy Wichmann
<nan_wich@bellsouth.net>
Message-ID: <13146D20-74BF-4579-9E19-59E77013E463@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Thanks, I had set the php memory limit to 128mb, but it got reset to 64mb without me initiating it. I'll reset it. On my local MAMP version, I have set php memory to 500mb. Can't do that on my server, tho.
Best,
Bill
William Prothero
http://es.earthednet.org
On Apr 20, 2013, at 4:29 PM, Nancy Wichmann <nan_wich@bellsouth.net> wrote:
> On even a very simple page load, Devel tells me I am using 56MB. Trying to run a real site in 64MB is asking for heartaches. I wouldn't even try to run D7 in less than 128MB. Increase you PHP "memory limit" setting and see if your problem goes away.
>
> Nancy
> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
>
> From: "Waprothero@gmail.com"
>
> Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 101 bytes) in/home/wap/public_html/includes/database/query.inc on line 1856
> --
> [ Drupal support list | http://lists.drupal.org/ ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20130421/9fda34c8/attachment-0001.html
------------------------------
Message: 2
Date: Sun, 21 Apr 2013 09:34:11 -0700
From: "Waprothero@gmail.com" <waprothero@gmail.com>
Subject: Re: [support] Problem getting Drupal mail
To: "support@drupal.org" <support@drupal.org>
Message-ID: <E0C54479-27CA-46E7-A721-588C026FCEF9@gmail.com>
Content-Type: text/plain; charset=us-ascii
Thanks for the replies. Liquidweb support took this on and it turned out to be unable to write to /dev/null. It's fixed. It really shows the value of having good support by Linux guys on your server. Liquidweb is really great. I can't recommend them too highly.
Best,
Bill
William Prothero
http://es.earthednet.org
On Apr 21, 2013, at 1:58 AM, John Summerfield <summer@js.id.au> wrote:
> On 20/04/13 05:19, Prothero William wrote:
>> Folks:
>> I just finished upgrading my Drupal site to D7. I'm having problem with Drupal sending out emails to users who request new accounts or who have forgotten their passwords. This happened very quickly with my D6 site. However, the D7 site keeps emails in the mail queue for 10-15 minutes, then sends them. But, I can send an email, through another mail server (like gmail) to the same address that is being held up in my mail queue, and it comes very quickly. I have several email accounts on the server, and it doesn't matter if I send one email from one account, to another account on my server, either. Response if very quick.
>>
>> It appears that only email initiated by my Drupal 7 site is held for a longer time.
>>
>> What might be going on? I don't see why email should be held for so long and it is definitely a minus for my users.
>>
>> Any insight would be helpful.
>> Bill
>>
>> Prothero William
>> waprothero@gmail.com
>
> If you host your own mail service, examine its logs to see when _it_
> sees them.
>
> I do not yet have any experience sending emails from D7, so I don't know
> whether it batches them (it might) or not.
> --
> [ Drupal support list | http://lists.drupal.org/ ]
------------------------------
Message: 3
Date: Sun, 21 Apr 2013 13:39:37 -0600
From: lamp@afan.net
Subject: [support] Upgrade from 7.16 to 7.22
To: support@drupal.org
Message-ID: <e3b5399e450f51df7b5c1d5842be418c.squirrel@afan.net>
Content-Type: text/plain; charset="utf-8"
Hi to all,
I have website with Drupal 7.16 on it. Plan to upgrade to the latest
version, 7.22.
Is it safe to upgrade directly from 16 to 22 or I
have to go version by version, or something?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20130421/51c0cc72/attachment-0001.html
------------------------------
Message: 4
Date: Sun, 21 Apr 2013 15:54:36 -0400
From: <Bob@TurnerPCC.com>
Subject: Re: [support] Upgrade from 7.16 to 7.22
To: <support@drupal.org>
Message-ID: <6BE5743508124835A0B1084F306806EE@Attic>
Content-Type: text/plain; charset="utf-8"
You can skip the minor upgrades, minor being the number to the right of the decimal point.
Bob
From: lamp@afan.net
Sent: Sunday, April 21, 2013 3:39 PM
To: support@drupal.org
Subject: [support] Upgrade from 7.16 to 7.22
Hi to all,
I have website with Drupal 7.16 on it. Plan to upgrade to the latest version, 7.22.
Is it safe to upgrade directly from 16 to 22 or I have to go version by version, or something?
Thanks.
--------------------------------------------------------------------------------
--
[ Drupal support list | http://lists.drupal.org/ ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20130421/ecac7307/attachment-0001.html
------------------------------
Message: 5
Date: Mon, 22 Apr 2013 09:16:35 +1000
From: Roger <arelem@bigpond.com>
Subject: [support] Memory error
To: support@drupal.org
Message-ID: <51747353.3080501@bigpond.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/21/2013 10:00 PM, support-request@drupal.org wrote:
>
> I'm getting this error, and it doesn't make sense to me:
>
> Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 101 bytes) in/home/wap/public_html/includes/database/query.inc on line 1856
>
> Its trying to allocate only 101 bytes. I get similar errors when I try to enable a module. I have the site also running locally, and get no error. What I have to do is make all changes on my local site, then upload the database to my remote site. It's a pain.
>
> What should I look for to fix this?
>
> Bill
>
>
Bill Thank you.
I won't go into details, it's all in the list and on the LUV forum. I
have been asking about this error message for weeks now and there are
suggestions but no resolution.
It seems to be caused by drupal demanding more memory than PHP allows.
Which could mean that php is not flexible enough to cope with high demand.
It sometimes can be resolved in /sites/default/settings.php by adding
init_set('memory_limit','128M') but this will not stop the error
permanently.
I have seen faulty modules and number of modules blamed, etc. Basically
it all comes down to either a PHP 5 update is faulty or Drupal, or some
3rd party required module is faulty.
It may be resolved by making entries in php.ini and .htaccess but this
also does not permanently fix a problem which should not exist.
Roger
------------------------------
Message: 6
Date: Sun, 21 Apr 2013 16:35:41 -0700
From: "Waprothero@gmail.com" <waprothero@gmail.com>
Subject: Re: [support] Memory error
To: "support@drupal.org" <support@drupal.org>
Message-ID: <7AB191A8-E999-46D6-993E-3F6C26A87DFC@gmail.com>
Content-Type: text/plain; charset=us-ascii
Roger,
One thing I did that seemed to help was to reset the password of the database. It may have gotten unset somehow. But, the memory limit was set to 64mb, so I changed it back to 128mb. It seems fine now. The upgrade to D7 was a complete chore and I seem to have muddled through it. All issues to date seem solved and now I can start having fun with my IT projects again.
Best,
Bill
William Prothero
http://es.earthednet.org
On Apr 21, 2013, at 4:16 PM, Roger <arelem@bigpond.com> wrote:
> On 04/21/2013 10:00 PM, support-request@drupal.org wrote:
>>
>> I'm getting this error, and it doesn't make sense to me:
>>
>> Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 101 bytes) in/home/wap/public_html/includes/database/query.inc on line 1856
>>
>> Its trying to allocate only 101 bytes. I get similar errors when I try to enable a module. I have the site also running locally, and get no error. What I have to do is make all changes on my local site, then upload the database to my remote site. It's a pain.
>>
>> What should I look for to fix this?
>>
>> Bill
>>
>>
> Bill Thank you.
> I won't go into details, it's all in the list and on the LUV forum. I
> have been asking about this error message for weeks now and there are
> suggestions but no resolution.
> It seems to be caused by drupal demanding more memory than PHP allows.
> Which could mean that php is not flexible enough to cope with high demand.
> It sometimes can be resolved in /sites/default/settings.php by adding
> init_set('memory_limit','128M') but this will not stop the error
> permanently.
> I have seen faulty modules and number of modules blamed, etc. Basically
> it all comes down to either a PHP 5 update is faulty or Drupal, or some
> 3rd party required module is faulty.
> It may be resolved by making entries in php.ini and .htaccess but this
> also does not permanently fix a problem which should not exist.
> Roger
>
> --
> [ Drupal support list | http://lists.drupal.org/ ]
------------------------------
Message: 7
Date: Sun, 21 Apr 2013 20:21:46 -0400
From: Jamie Holly <hovercrafter@earthlink.net>
Subject: Re: [support] Memory error
To: support@drupal.org
Message-ID: <5174829A.2020805@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
While PHP gives a "fatal error" for out of memory, it may not be so much
an error, but rather a misconfiguration. PHP ships with a default INI file.
Something you may find interesting. The default php.ini file that is
distributed with PHP for production use actually sets the memory limit
to 128mb:
https://github.com/php/php-src/blob/PHP-5.2/php.ini-recommended#L307
This has been since PHP 5.2, over 6 years ago:
https://github.com/php/php-src/commit/3ffc1c8f4a1e4c1658f94038e009e226258a65a4
Before that it was only 8mb and numerous shared hosts didn't even allow
you to adjust it. They do now because they realize that web apps have
become far more complex as the web has evolved.
(NOTE: The 64mb limit many encounter is due to the fact that the
developers of their OS felt that is all that is needed and set the limit
in the php.ini file they distribute. Luckily this is easy to change
through numerous methods.)
Jamie Holly
http://www.intoxination.net
http://www.hollyit.net
On 4/21/2013 7:16 PM, Roger wrote:
> On 04/21/2013 10:00 PM, support-request@drupal.org wrote:
> >
> > I'm getting this error, and it doesn't make sense to me:
> >
> > Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 101 bytes) in/home/wap/public_html/includes/database/query.inc on line 1856
> >
> > Its trying to allocate only 101 bytes. I get similar errors when I try to enable a module. I have the site also running locally, and get no error. What I have to do is make all changes on my local site, then upload the database to my remote site. It's a pain.
> >
> > What should I look for to fix this?
> >
> > Bill
> >
> >
> Bill Thank you.
> I won't go into details, it's all in the list and on the LUV forum. I
> have been asking about this error message for weeks now and there are
> suggestions but no resolution.
> It seems to be caused by drupal demanding more memory than PHP allows.
> Which could mean that php is not flexible enough to cope with high demand.
> It sometimes can be resolved in /sites/default/settings.php by adding
> init_set('memory_limit','128M') but this will not stop the error
> permanently.
> I have seen faulty modules and number of modules blamed, etc. Basically
> it all comes down to either a PHP 5 update is faulty or Drupal, or some
> 3rd party required module is faulty.
> It may be resolved by making entries in php.ini and .htaccess but this
> also does not permanently fix a problem which should not exist.
> Roger
>
------------------------------
--
[ Drupal support list | http://lists.drupal.org/ ]
End of support Digest, Vol 124, Issue 28
****************************************