Feeds not refreshing on cron

Does the admin/reports/dblog page contain "Cron run completed." lines?

Ok.
Do you know that at cron time, all of the feeds are refreshed only after the last refresh + 1800 seconds?
In practice:
- you have one feed
- just refreshed it manually
- after that, you immediately click on "run cron manually link"
- the feed won't be touched, because the last refresh + 1800 seconds time is not elapsed

After the above, is this a problem anymore?

I am having the same issue with the current *dev version. The feeds do not get updated via cron. Even if I run cron manually, nothing happens. I'm only getting feeds refreshed if I manually go through and refresh each one (with a number of feeds this takes quite a while).

a bit more info...

cron runs are completing successfully.

I have stripped back to the point where there is only 1 feed that is setup, so it shouldn't be a problem of having too many feeds trying to refresh.

I have cleared the cron_semaphore variable, but this has not allowed feeds to refresh on cron.

I have allowed up to 36 hours to pass (to ensure that the failure to refresh is not related to the +1800 issue mentioned above.

I have increased the php max_execution time to 300 seconds to make sure that there is sufficient time to complete any 'long' tasks.

As far as I can see all other updates that are related to cron are completing without problem.

Hoping this can be resolved soon, as I'd really like to use feedapi in my production site

fumbling,

can you give me some more detail on how you've setup your 'alternate' cron system?

I also tried reverting back to 1.4, but that didn't help me either.

I've been looking at using SimpleFeed instead of Feedapi, but it doesn't have the same number of features. It lacks the feedapi_mapper, which is really useful.

What's your OS and other modules? Maybe we can track down where our systems are similar and find the issue.

Thanks

Thanks for the info.

I, too, have many contrib modules so I'll need to take the site down for a period to turn things off and on to see if there is a conflict somewhere. Alternatively, I may try to create the same configuration on another server (same spec) and see if I can track it down there.

I don't think the problem is to do with processes being too intensive, I have reduced down to only a few feeds and they are not getting refreshed that often. Still the problem persists.

I'm having this problem too. Details: like fumbling, I can refresh manually. When I run cron via command-line ("php cron.php"), I get nothing. Poormanscron does squat too.

I've tried this with older feeds as well as brand new fresh ones, doesn't seem to be working for me.

EDIT: also, forgot to mention that I only have about four feeds going on my site, and only one of them is updated with any frequency.

dubitable,

fumbling is correct. There are a number of issues related to poormanscron (not just with FeedAPI). If you do a search, here on the Drupal site, you'll find quite a few forum and issue threads pointing out some of the problems.

As with fumbling, I'm not using poormanscron, so the cron refresh issue is repeatable and not necessarily related to poormanscron.

Yeah...sorry if I've added unnecessary noise. I just was poking around something else and realized that at least some of my problems are being caused by poormanscron...I see errors in the error log for that. So, maybe my problems are unrelated. I'll set up a regular cron job and see if that helps, perhaps it wasn't working when I tested before for some other reason.

Thanks for the pointers--

DD

Fumbling are you running the Amazon module?

I've not confirmed that this is the problem, but on another site (which has a very similar setup) I've noticed that the Amazon module was keeping my cron from running properly. I would always get 'cron failed to run' (whether manually or automatically) or I was getting log messages saying 'cron failed to run because it was already running' (or similar wording). I also noticed that I was getting messages from the Amazon module stating that it could not update items. When I disabled Amazon, cron starting running normally.

I'll keep digging, but let me know if you've got Amazon installed.

Well, it's not the Amazon module. So, that didn't help us...

I wait with baited breath... I'd really like to get FeedAPI back in working order.

Do let me know if you find the culprit.

I think I've found the problem! I've just turned off all of the modules associated with the File Framework project, and FeedAPI is now refreshing on cron runs. Which is a good result. However, now I've got a problem as I don't have access to all the files that have been uploaded to fileframework.

Does anyone know how to change the order of cron runs? it would seem that fileframework kills the cron run on completion of its tasks.

I tried adjusting the weight of the modules (which is supposed to effect the order in which cron tasks are performed) but that does not seem to have fixed the problem.

gmak, as a temporary measure you could also disable the File Framework's automatic maintenance cron runs at admin -> settings -> file which does indeed allow FeedAPI to resume updating its feeds.

fumbling, did you also have File Framework installed?

this seems like a duplicate of #419588: Feedapi not refreshing feed via anonymous cron but works with cron by authed user which i'm running into. i can manually run cron as the admin and they update fine but when the anon cron occurs nothing gets updated.

Just my two cents guys. First, my site is totally driven by cron fed feedapi and feedapi mapper to bring in a georss feed of weather data and turn it into nodes. I require a high refresh rate, I opened the other ticket #419588: Feedapi not refreshing feed via anonymous cron but works with cron by authed user and now at last I have my feeds working, here is what I did:

1) I edit the feedapi.module (Every time) and change: line 15:
to say:

define('FEEDAPI_CRON_MIN_REFRESH_TIME', 60);

This says I can have a refresh every 60 seconds if I want.

2) in my simple pie parser settings on the feed node ( seem to only be able to use simple pie) I set the Cache lifetime to 30 seconds

It took this, and a reboot and wating a few hours to see the results but now my crontab calls the cron.php on localhost every 5 minutes and I have every record by 15 minutes after the hour now.

I dont know if this is related but since very few people have solved this issue I thought I would share anyway

Thanks for pointing me to this issue too DREWISH!

F

I haven't read through the entire thread, but please note, that #255852: Poormanscron and FeedAPI don't work together.

If you are researching bugs like this, please always use the latest version of FeedAPI and try to isolate it on a vanilla Drupal installation. Does this problem persist on 6.x 1.x ?

Problems described on #255059: Switching user to feed author during cron seem to be related.

I have the same problem, the feeds are not refreshed on cron, but I solved myself. If somebody using any module with set_time_limit(0) command in the hook_cron function, and the module weight in the system table is smaller than FeedAPI's, the feeds are not refresed on cron, because the return value of the feedapi_cron_time function is always 0. In my case, the FeedAPI's original weigth was 5, and the Localization Server's weight was 0. I changed the weigth of the FeedAPI to -5, and the feeds are refreshed again. It is a good solution, or somebody knows a better?

Thank you for reporting this issue. It's a tricky one :)
As i found out, 0 has a special meaning, but i'm in doubt that the script will run forever, other timeouts will apply. For FeedAPI, i'd allow 1000 seconds to run when this limit is 0.
What do you think?

I think, it is too long interval, 1000 seconds is more than 15 minutes. I have more than 150 feeds from d.org, but in this case all feeds are refreshed at every cron run (my provider will be happy, because my cron frequency is 5 minutes.) I think, one or maximum two minutes better, if the time limit is zero.

Thank you for your insights. Just committed the patch.
Well, i think there is no 'good' value in this case, it's possible to argue pro and con, isn't it? :)