Okay, as soon as I got the module set the way I wanted I subscribed to a node. Now, when cron runs, I get a watchdog warning: "Cron run exceeded the time limit and was aborted." (Right now, cron is set to run once a day, but I get this once an hour.)

Also, if I run cron manually I get a wonderful PHP error: "Fatal error: Call to a member function on a non-object in /home/xxxxxxx/public_html/includes/common.inc(1352) : eval()'d code on line 7"

Any suggestions where to look?

Comments

salvis’s picture

salvis
he/his
commented
Status: Active » Postponed (maintainer needs more info)

Search through all of your source code for "_cron(" to find out which of your modules run hook_cron() and report the result.

Look for the line
$available_seconds = $total_seconds - $lost_seconds;
on line 33 of subscriptions_mail.module. Insert

watchdog('cron', "Subscriptions has $available_seconds of $total_seconds seconds available.");

immediately below it. Try running cron (manually and hourly) and report the result.

mrtoner’s picture

mrtoner commented

Okay, the enabled modules running hook_cron are:

Google Analytics
Panels
Spam
Subscriptions Content
Subscriptions Mail
Trackback

A couple of log entries:
Subscriptions has 239.38179 of 240 seconds available.
Subscriptions has 239.31284 of 240 seconds available.

Unfortunately, I got this info after I began disabling modules to see if there was a conflict. When I had disabled all third-party modules except for Mail Editor, Subscriptions, Subscriptions Content and Subscriptions Mail, cron still gave an error. When I disabled Subscriptions Content, cron operated without an error. After re-enabling all the modules, cron continues to work.

mrtoner’s picture

mrtoner commented

Whoops! It appears I was a bit hasty. When I updated some content and ran cron manually, no error. I didn't test by updating content and letting cron do it's thing automatically. Now...

The same errors have returned, both when cron is run manually and when run hourly. The log error ("Cron run exceeded...") is preceded by notices similar to "Subscriptions has 237.17141 of 240 seconds available." The error occurs at the same minute the notice appears.

salvis’s picture

salvis
he/his
commented

Interesting, so you're not really running out of the four minutes.

Could the "Cron run exceeded the time limit and was aborted." message be generated by one of your other modules?

In your OP you wrote:

Right now, cron is set to run once a day, but I get this once an hour.

This can't be — something must run every hour for this to happen...

Let's try to focus on the PHP error: what version of Drupal and PHP do you have?

mrtoner’s picture

mrtoner commented

Sorry, cron is set to run once an hour. I took a look at the status report, saw that it hadn't run in 21 hours, and got it into my head that it runs every 24. Since cron is failing, though, it doesn't mark the activity as completed.

I'm running Drupal 5.7, PHP 4.4.7. I didn't have these problems before upgrading to Subscriptions 2.0rc1 from -- I think -- the dev version. The error occurs when running only Subscriptions Content and Subscriptions Mail (with Subscriptions and Mail Editor, of course), so I don't believe another module in the list above is to blame.

I just upgraded to the 2.0 release of Subscriptions. Cron still wouldn't run. I then disabled Content Subscriptions (along with the modules that depend on it) and ran cron. No problem. Next, I updated a node that I've subscribed to and let cron run automatically. No problem.

I'll keep you posted.

salvis’s picture

salvis
he/his
commented

I don't want to shrug this off, but quite a few people have been running various beta versions, some for many months, even on production sites, and no one has reported anything like that.

Your site must be different in some way...

I didn't have these problems before upgrading to Subscriptions 2.0rc1 from -- I think -- the dev version.

5.x-1.9-dev?

chx’s picture

chx commented

you are not running the suhosin patch for PHP are you? that caused some interesting glitches in the past.

mrtoner’s picture

mrtoner commented

No, I stayed away from 1.9 when I saw your warning. And I'm not familiar with suhosin. I'm running on a hosted, shared server and that name doesn't pop up when I do a phpinfo(). Should I ask my host?

BTW, the errors I'm getting show up between these two lines in subscriptions_mail.module:

          $mailvars_function($mailvars, $object, $field, $s);
          $mailvars += module_invoke_all('subscriptions_get_mailvars', $object);

I believe the problem is that $object is NULL.

salvis’s picture

salvis
he/his
commented

I have to let chx pursue the suhosin track.

Some 50 lines earlier there's an if statement that wouldn't let control go inside if $object were NULL, and there is no assignment to $object in between. I'm puzzled about how it could suddenly turn NULL...

If you've narrowed it down this far, you can add something like

watchdog('debug', '#1: $object is '. (isset( $object ) ? 'set' : 'null'));

in strategic places to really pin it down. Increment the number for every call that you add, to make it easier to tell them apart.

mrtoner’s picture

mrtoner commented
Version: 5.x-2.0-rc1 » 5.x-2.0

Okay, that wasn't the problem at all. Seems that Subscriptions doesn't work with a node with an input format of PHP code. Any suggestions for getting that to work? (Oh, I've updated to 2.0.)

salvis’s picture

salvis
he/his
commented

That may be a nasty issue. Are you sure that your PHP code can work in cron?

Maybe we should just drop nodes with PHP format...

Give me a sample of what's in your PHP nodes and I'll take a look.

mrtoner’s picture

mrtoner commented

It's code taken from http://www.giveawayoftheday.com/gfs/ that parses an XML feed and then displays the data when the page is viewed.

<?php

require_once("path-to/settings.php");
require_once("path-to/lib.php");

while( $gaotd->have_items() ) {
?>

...

<?php
}
?>

I want users to be notified daily of the update. While I know that Drupal doesn't know when this content updates automatically, I thought perhaps I could use another cron task to force the update, which Drupal would notice. However, I can't test that until Subscriptions plays nice with PHP nodes.

Hmm. There does appear to be something wrong with my code, because when I replace that node with a simple "echo 'here';" statement the cron job runs fine. Don't know why the page itself displays without an error. I'm sorry to have taken your time with this issue.

salvis’s picture

salvis
he/his
commented

Ah, now we can understand why cron times out: apparently it hangs on that one message until the time is up.

But, does it not hang when you run it from the status page? When you run cron.php from a browser that's not logged in? (Not that it makes a difference, I'd just like to know so I'm better prepared the next time something like this comes up.)

mrtoner’s picture

mrtoner commented

Yes, it does hang when run from the status page as well. The problem appears to be that the node is loaded twice in cron, but the require_once statements (at least the second one) mean the $gaotd object is created only once.

(I put a watchdog notice just after the require_once statements. Two log entries appear when I run cron, one with $gaotd set and another without it set. That's the error that's reported.)

I tried changing the require_once to require, but then I get a "Cannot redeclare class gaotd" error. Hmm. How about a "global $gaotd;" statement at the top. Well, what do you know! That seems to work without an error.

Sorry, just thinking out loud. There doesn't seem to be a problem with Subscriptions at all, unless it's responsible for the node being loaded twice.

salvis’s picture

salvis
he/his
commented

The node needs to be loaded for every user, because different users may get different nodes. For example, some may get comments and some not. So, if you have two subscribed users, it will be loaded twice.

salvis’s picture

salvis
he/his
commented
Status: Postponed (maintainer needs more info) » Closed (fixed)