Debugging scheduled job that is not running

[skyrun]

I have several scheduled jobs that for the most part run without any issues. i have one job that has recently stopped running correctly (leaves state=2). when i run the job from the scheduled list (check and press 'run'), it works fine, but when it's running automatically, it doesn't complete and leaves the state at 2.

any tips on how to debug this?

i checked jos_fabrik_log and it shows the jobs as starting but no 'referring url' or 'message' there.

i turned display messages on also and i'm not getting any messages.

the job creates a .pdf report and then emails it. it runs in about 60 seconds. could there be a time out issue?

ALSO NOTE i'm on V2 (posted here since i don't think thre is a silver forum for v2)

 

[skyrun]

new info: it appears that it is happening when i run the same php script multiple times simultaneously from cron (manual or automatic).

regardless, would be nice to get some debugging tips where i can perhaps see an error of some sort to put me on the right track.

 

[cheesegrits]

There is a 2.x Silver, I'll move the thread.

We shouldn't ever run multiple copies of the same script concurrently. That's the point of the '2' status, we set it before the plugin is run, in the main plugin controller, and set it back to 1 when the plugin completes. This is so we know not to run another copy of it, if the first copy takes longer to run than the scheduled time.

You didn't say which plugin(s) are affected? If it's a PHP one running your own code, you can just toss some extra logging in it:

Somewhere at the top of your code, grab the log instance and set up the basics:

$log =& JTable::getInstance('Log', 'Table');
$log->id = null;
$log->referring_url = $_SERVER['HTTP_REFERER'];
$log->message_type='plg.cron.your_name.debug';

Then at various points in your code, start dumping out debug info:

$log->message = "Something useful for your debug: $some_variable_name";
$log->store();

If it's one or more of our out-of-box plugins, you can add in extra logging lines. Some plugins already have a $log instance, so you can just use that, or you may have to add the JTable::getInstance() at the top.

-- hugh

 

[skyrun]

addition

sorry i misled you but yes, each schedule is only running once. i have 3 that are calling the same program (runphp, but with the same custom php). they are set to run an hour apart, but apparently that doesn't always happen and when it doesn't, it gets set to state 2. my current theory is that there is something in that script that is single-threaded and causing the issue. i don't think it's a fabrik issue, just wanted a debugging tip and yours was spot on.

also, when i used your code i had to add a '$log->id = null;' along with setting the message before calling $log->store(); otherwise only the last message i put in got written to the log. maybe $log->store() sets the id or something... but with the $log->id=null each time, it stores every line in the log.

 

[skyrun]

i'm pretty sure only one schedul plugin runs even if multiple are 'ready'

ok. with my debugging in place, i'm pretty sure that i am observing that even if 3 individual schedules are set to run via their date/time being in the past, only one of them is getting run when the plugin is triggered.

worse, the date on the other 2 is still getting changed (and state is staying 1), so the other 2 don't ever run. as long as they're spaced out by an hour or so, then all 3 run, but since it's in the middle of the night and page-views/plugin-triggers could be hours apart, they're getting bunched up and then one or two don't run if more than one is triggered.

possible?

 

[skyrun]

running more than one plugin on the same page reload.

ok, i think i figured out what's going on. when more than one plugin is set to run, it runs them all as a group meaning if you have 'require_once' or define a class or use a function in code. and that code is called twice because two plugins run, then the others error out.

i think the easiest fix may be to run just one plugin each webpage reload so that any potential conflicts are avoided.

you can do that by adding ORDER BY lastrun ASC LIMIT 1; to the end of the queries in fabrikcron.php on lines 85 and 89 (approx depending on version)

...
            $query = "SELECT id, plugin, lastrun, unit, frequency, $nextrun AS nextrun FROM #__fabrik_cron\n"
            ."WHERE state = '1' AND $nextrun < '". JFactory::getDate()->toMySQL() ."'
             ORDER BY lastrun ASC LIMIT 1";
        } else {
            $query = "SELECT id, plugin FROM #__fabrik_cron WHERE state = '1' ORDER BY lastrun ASC LIMIT 1";
...

this runs one eligible scheduled task each page load. (note that you also can't can't check more than one on the backend and press 'run' or it will still error).

 

[cheesegrits]

That's possible.

The problem we're working round here is that J! doesn't have a scheduler. So we use a system plugin that runs on as the last operation on any J! page load, after the page content has been sent, which does a quick check to see if we have any jobs that need running. But as you observed, this can cause "bus stop" issues (no bus arrives for hours, then 5 arrive all at once) if the site isn't visited constantly.

So what I typically do to work round that on less busy sites, is run a UNIX 'cron' job which fires off something like a wget on your site every X minutes, and uses the 'query string trigger' option set on the cron job.

-- hugh

 

[cheesegrits]

I might look at the suggestion of only running one eligible cron job per page load, although I'd probably want to make that a configurable max. I know some folk that rely on having two tasks running in sequence on the same page load.

-- hugh

 

[troester]

If you use a wget cron job e.g. once a day will it run ALL fabrik crons with "Query string" (and wating at the "bus stop") at the same time?

How about to require the jobID (and maybe a password) in case of querystring activation (as it is done in Akeeba)?

 

[jfquestiaux]

I too think this would be useful to specify which cron should run on "Query string", in case you have several CRON having to be fired at different times.