I am running subscriptions 1.9 on a new site running Drupal 5.1 I had installed subscriptions prior to ver 1.9 and while I had very few entries I had no problems. Shortly after installing 1.9 my CRON job started to fail. It failed if run as a normal CRON task or manually in the browser.
The Drupal log claimed it failed with 'Cron run exceeded the time limit and was aborted." but when I look in the Apache log I found
[Sun Mar 18 17:24:03 2007] [error] [client ip.ip.ip.ip] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 8388608 bytes) in /MyPath/.../httpdocs/sites/all/modules/subscriptions/subscriptions.module on line 616
I am running my PHP at 32Meg There are no comments so far
When I tuirned off 'Use cron for notifications" the CFRON job stopped failing and ran successfully.
GD library bundled (2.0.28 compatible)
MySQL database 4.1.15
PHP 4.4.2
Unicode library PHP Mbstring Extension
Web server Apache/2.0.53
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | subscriptions5.patch | 8.87 KB | jenlampton |
Comments
Comment #1
mindless commenteddid you try raising your php memory limit?
Comment #2
MacRonin commentedI did not try raising my memory limit, but I figured that 32Meg should be enough. After all its a new site with (at the time) under 30 posts, no comments, under 10 users and I had no problem with the previous release. If its memory requirements are that intensive at that low a level of usage, I don't think I could dedicate enough resources at a high level of usage, and I don't to give and then take away such a nice function.
I am going to give it another test though at the same memory level (32meg) since I found a problem(confirmed by others) with the devel module causing some things to fail. There is an outside chance that it stepped on the subscriptions module also.
OK having the DEVEL module disabled had no impact. I guess I'll just leave it(the CRON option) off till I have a chance to test it fully on my development site. It does do the notifications when I have the CRON option off and its done at node update. So it must be diff memory requirements or some other difference causing the prob.
BTW when the DEVEL module was active it said my normal memory usage at page generation time was 10-12meg so it did leave a 20meg or so cushion
Comment #3
mindless commenteda cron run is not a single page generation, it does a lot of work in a single request.
Comment #4
MacRonin commentedI know CRON is not equal to a single page request, but I figured that that memory number gave at least an idea of my base memory usage for the diff modules I have loaded. Since I have allocated 32 Megs to php that left approx 20 Megs for the CRON task and whatever else got loaded when it ran. And like I said it had no problems when I ran an earlier release of subscriptions. So unless I was just under the wire (a possibility) it just seemed strange. And many times in the past I have seen this type of memory failure caused by other problems, And fixing the other bug also stopped the memory failure. But I'll just have to get a chance to setup a clean test environ, see if it works there, keep adding my current list of modules and see when it dies. And if it doesn't then I just have to figure out what is unique about that site. I still have only have 100 nodes under Drupal so its not like I had a big table of content to be checked. But until then I'll just have it do the check for mailing at NODE modification time. Not as efficient but it works.
BTW what type of PHP memory allocations are any other Subscriptions users using??
Comment #5
daddison commentedFWIW, I have had cron fail on my largest list (1400+ addresses) using Drupal 4.7.x. My php memory is set at 48M.
Comment #6
tobiass commentedSame problem as MacRonin
If i don't send the notifications by cronjob it works, but then i have a problem with access control. I have an administrator forum with taxonomy controled access. If a user subscribes to node type forum he will also recieve notifications from the access restricted areas. That is why sending notification not by cronjob is not a solution.
Comment #7
roychri commentedThe memory allocation exausted problem in subscription module has been fixed by a patch:
http://drupal.org/node/149996
Comment #8
jenlamptonThe patch at the above link is for 4.7, but I'm still having this error in my 5.2 module. Has anyone created a working patch for 5.x yet?
Comment #9
jenlamptonI took the patch for 4.7 and made the same changes to 5.x-1.9. It seems to be working for me, please test.
Comment #10
jenlamptonbleh, ok so that already existed. no testing required, sorry! :-)
Comment #11
(not verified) commentedComment #12
nicholas.alipaz commentedSorry to "bring back from the dead" a really old issue, but broken in 6.x as well.
I found that no matter my php memory limit I get the error. The limit was set to 64M and I got the error saying it tried to allocate 197bytes and couldn't. Once I disabled "Display summary watchdog entries per cron job" the errors stopped. Now my cron runs fine.
Comment #13
salvisWhat's your PHP version?
It's very unlikely that this is a bug in Subscriptions.
Comment #14
nicholas.alipaz commentedphp 5.2.6
The errors only occur when the subscriptions setting "Display summary watchdog entries per cron job" is enabled.
Comment #15
salvisHehehe, you've found a bug, but not the one you thought you found.
The bug is that the subscriptions_watchstats variable controlled through the checkbox that you mention is not used at all. Its intended purpose is to control whether the watchdog call at the end of the subscriptions_mail_cron() function in subscriptions_mail.module is made. But the call is always made.
So, as we know, placebos do help sometimes, but this is the first time that I read that they even help with web servers. The behavior that you're seeing is definitely not a bug in the current Subscriptions.