I have set up supercron and it is not pulling in anything. It runs without doing anything and without producing any errors. However when I invoke the task manually, it works just fine.

I am starting to hate with passion such modules that are almost there but ...

Rolling one's own would take lot less effort then to have to figure out what some poet had in mind.

Comments

MisterSpeed’s picture

MisterSpeed commented

Well, 574 people seem to have no problem at all. Could you pls. tell me which modules you have installed, and how is your cron main file called ?

MisterSpeed’s picture

MisterSpeed commented
Status: Active » Postponed (maintainer needs more info)
MisterSpeed’s picture

MisterSpeed commented
Priority: Critical » Normal
tesliana’s picture

tesliana commented

The relevant modules or at least the ones that appear in Supercron configuration are:

captcha .... Invoke 2010-01-07 22:28:22 0.00 sec 0.00 sec
ctools ....... Invoke 2010-01-07 04:13:19 0.00 sec 0.00 sec
dblog ........ Invoke 2010-01-07 04:13:19 0.00 sec 0.00 sec
feedapi ..... Invoke 2010-01-21 06:59:24 7.00 sec 4.18 sec
filter ......... Invoke 2010-01-07 04:13:20 0.00 sec 0.00 sec
googleanalytics ... Invoke 2010-01-07 05:12:34 0.00 sec 0.00 sec
node ........ Invoke 2010-01-07 04:13:20 0.00 sec 0.00 sec
system ..... Invoke 2010-01-07 04:13:20 0.00 sec 0.00 sec
update ..... Invoke 2010-01-07 04:13:20 0.00 sec 0.00 sec

The only one that is of interest and the only one that is currently enabled is "feedapi".
When I click on Invoke to the right of "feedapi" then it works fine.

www.mosso.com has an extremely simple online form for setting up cron tasks and in the program to run, I have http://www.mysite.com/supercron.php ... with supercron.php copied up to the root directory.

The tasks runs every hour but it does nothing ...

This is an automatically created email, sent to inform you that your scheduled task has completed. Here are the results of the execution of your task:

Task Started at Thu Jan 21 06:12:01 CST 2010
--------------------------------------
Command to be executed is: /usr/bin/curl http://www.mysite.com/supercron.php
Task ID of this command is: 17886
Where should log be written: /mnt/ ...... /www.mysite.com/logs
Email address: myemail@gmail.com

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
--------------------------------------
Task ended at Thu Jan 21 06:12:02 CST 2010

Nothing gets written to the logs directory.

*** And why did you change the status, if I am responding within hours ? The same for critical vs normal. It is critical until it is resolved or some stupidity on my part explained ... no ?

MisterSpeed’s picture

MisterSpeed commented
Category: bug » support

Tesliana: the status indicates the priority in the grand scheme of things, not the importance to you. If it was the importance to the submitter, everything would always be critical. Also, reducing our work to "what some poet had in mind" is very dismissive and insulting. We are sharing a system that was carefully engineered and that we know is mission-critical to many sites and we take that very seriously. This is not a brainfart or a half-baked module, or an amateurish piece of code by any stretch of the imagination.

That being said, let's go back to business:

Two possibilities:

1. If the automatic cron behaviour behaves differently from the manual behaviour, it is nearly always the case that the cron task is being called under different access rights. On a Linux or BSD-based system, make sure that supercron operates under the same username (or one with the same rights) as that which the web server and php interpreter operates under when executing your site. Does feedapi need to create files or access directories ? if so you definitely want to make sure that the access rights are the same, and if you are calling supercron.php from the outside that supercron.php is owned by the same user and has the same access rights as well.

2. Far less likely, but still a possibility: It may be that feedapi relies on non-public flags or structures on cron (so far we've seen one other module do that, out of hundreds). In that case, this would be a limitation of that module. This being said, in the last case, we've simply synthesized a new structure to mirror that of cron and help the other module perform correctly. The elephant in the room, though, is still the rights issue so before open up feedapi pls. take a look at your settings.

As #1 is far more likely, I will treat this as a support request until we know more.

tesliana’s picture

tesliana commented

Actually, now that you put it that way, in your opening remarks.
You are 100% correct and I apologize - unconditionally.
Thanks a lot and I will now proceed to explore your suggestions.
In any case, I will report the outcome and especially if it makes even a bigger dork out of me.
Sorry, again.

tesliana’s picture

tesliana commented

I am a dork, but for a different reason - for never even having considered to run cron.php from cron ;)

---
www.mosso.com has an extremely simple online form for setting up cron tasks and in the program to run, I have http://www.mysite.com/supercron.php ... with supercron.php copied up to the root directory.
---

While the above does not work, when I change supercron.php to just cron.ph then all works - without having changed anything else. The problem with this is that it's total waste of cycles to be running a dozen different things each and every hour, just to be able to run the single feed api piece. But *it* works.

MisterSpeed’s picture

MisterSpeed commented

No problem. If feedapi requires file system access, then the "default" set-up of the LAMP stack makes it so that cron has higher privileges than the web server process, so things that are impossible under one set of Linux privileges become possible (shell calls for example). Granted, the learning curve of figuring out the very intricate rights system in Linux is very high and could be made a lot easier; as it stands it is very frustrating for the casual user and even a lot of the power users.

Not sure if it is in 1.3 or just in 1.4-beta, but you also can call SuperCron.php in such a way that it also allows a single hook to be called. This would be in the advanced tab. It may resolve the wasted cycles issue. Let me know if I can help with that.

tesliana’s picture

tesliana commented

I am still confused as to how come cron.php works just fine but supercron.php does not - under the same "default" set-up !?!

MisterSpeed’s picture

MisterSpeed commented

Not sure. But we'll push 1.4-beta in the next few weeks with some major upgrades, maybe that'll help fix the problem.

MisterSpeed’s picture

MisterSpeed commented

Pls try the new version and let me know if it resolves your issue:

http://ftp.drupal.org/files/projects/supercron-6.x-1.4-beta1.tar.gz