Installation check warning: cron.php?

687 views
Skip to first unread message

Yadin Flammer

unread,
Feb 9, 2016, 11:47:24 AM2/9/16
to ResourceSpace
Last scheduled task execution (days)     68    
WARNING
Relevance matching will not be effective and periodic e-mail reports will not be sent. Ensure batch/cron.php is executed at least once daily via a cron job or similar.

I can find nothing about this in the documentation.  Any help on what is going on here and how to address it?


Allison M Stec

unread,
Feb 9, 2016, 12:29:08 PM2/9/16
to resour...@googlegroups.com
You need to set up a cron to run "../pages/tools/cron_copy_hitcount.php"
--
ResourceSpace: Open Source Digital Asset Management
http://www.resourcespace.org
---
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to resourcespac...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
--
ResourceSpace Developer
Reseller of Colorhythm's Prismpoint Portal DAM

Ask me about ResourceSpace AWS Plugins

Yadin Flammer

unread,
Feb 9, 2016, 12:38:06 PM2/9/16
to ResourceSpace
I see the one I listed calls the one you listed.
Can I just call that file directly from cron or is there a specific syntax needed?  I've only ever called bash scripts from cron, not php files.
Did I miss this in the install documentation somewhere or is this an omission?

Bruce Harper

unread,
Feb 12, 2016, 10:08:13 AM2/12/16
to ResourceSpace
On Tuesday, February 9, 2016 at 12:38:06 PM UTC-5, Yadin Flammer wrote:
I see the one I listed calls the one you listed.
Can I just call that file directly from cron or is there a specific syntax needed?  I've only ever called bash scripts from cron, not php files.
Did I miss this in the install documentation somewhere or is this an omission?

This flummoxed me for the longest time, trying to get this to work on a Mac. I finally found elsewhere that the launchctl program that Apple dropped into the system to "replace" cron still recognizes and runs cron jobs automatically. The next step was getting the cronjob configured right. I finally worked out that I had to feed a full URL to wget to get it to run the program:

/opt/local/bin/wget -q -r http://www.<my site>/pages/tools/cron_copy_hitcount.php

Once I got that set up, the indexing has worked fine (prior to that, the trick was to click on "batch/cron.php" in the Installation Check to get the program to run.

Bruce in Blacksburg

Jeffrey Rickeard

unread,
Feb 12, 2016, 9:38:43 PM2/12/16
to ResourceSpace
If you're looking for a reference to this in the documentation, the Ubuntu install notes is one location (last item). There may be others.
http://wiki.resourcespace.org/index.php/Installing_on_Ubuntu_Linux

Yadin Flammer

unread,
Feb 19, 2016, 4:45:27 PM2/19/16
to ResourceSpace
I set up per that wiki article, and even added the x bits which I'm pretty sure are needed but not mentioned, however the install check still shows the same error.  Is the install check not checking properly for this?  Or is something else wrong?

Jeffrey Rickeard

unread,
Feb 20, 2016, 2:54:54 AM2/20/16
to ResourceSpace
I guess you mean the POSIX eXecute bits, so presuming you can manually run the cron daily bash script and confirm that cron is active on your system (e.g. http://www.cyberciti.biz/faq/howto-check-cronjob-is-running-not/), then from what I can see in the last few lines of the hitcount php file, the sysvars table is updated with the most recent execution of the php script. 

Here's what I found as an example when querying the relevant MySQL table.


Hopefully you can trace back and find out what is not calling what. I don't want to send you in the wrong direction, so beyond this I'll let the experts put you on the right track.

Yadin Flammer

unread,
Feb 22, 2016, 9:45:05 PM2/22/16
to ResourceSpace
Unfortunately it seems those instructions do not work, or RS doesn't respond to that setup in some way, because the last scheduled task execution keeps going up every day and that check still fails.  I'll try sticking something in root cron instead of using the cron.daily and see if that does anything.

Allison M Stec

unread,
Feb 23, 2016, 6:47:57 AM2/23/16
to resour...@googlegroups.com
cron.daily is actually anacron (similar to cron) and should be run as root. Consider trying cron with:

sudo crontab -e

Also, consider writing the output to a log so you can review any successes and errors/failures.

This Ubuntu documentation on cron should be enough to get you started:

https://help.ubuntu.com/community/CronHowto
--
ResourceSpace: Open Source Digital Asset Management
http://www.resourcespace.org
---
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to resourcespac...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Yadin Flammer

unread,
Mar 7, 2016, 5:38:05 PM3/7/16
to ResourceSpace
My bad, I didn't notice that there were inconsistencies in the documentation compared to my implementation, like http vs https, and server name and whatnot.  I hit the script in browser which made the install check show OK and then just pasted that url into my cron so it should work from here out, but yes I have it logging now too  ;)

However, now I look at that script and its directory and I see it and many others are executable to the world where many others are not.  Having scripts executable to all tends to make me nervous, is that really needed?  I would assume only the server (www-data) needs execute on things...  Any thoughts or insights on this?  Is there any article on general hardening of this product?

Yadin Flammer

unread,
Jul 15, 2018, 7:57:22 PM7/15/18
to ResourceSpace
It seems that an update broke this and negates the documentation.  We updated from 8.2 to 8.5 and I just noticed that the scheduled task has not worked since.

The error in the Installation check is still as above from years ago and still says /batch/cron.php
However, that does NOT match the documentation at https://www.resourcespace.com/knowledge-base/systemadmin/install_ubuntu which references /pages/tools/cron_copy_hitcount.php which is also mentioned above from years ago.  This indicates this inconsistency has never been addressed for some reason.  I can hit both of those scripts, and they both run fine.  
Why are there two if they do the same thing?

However, they don't work, because the Installation check still says it's been 38 days since it ran.  This indicates the scripts don't work and the documentation is wrong or there is a serious bug.

Any ideas what's broken and how to fix it?

Yadin Flammer

unread,
Jul 25, 2018, 1:59:49 PM7/25/18
to ResourceSpace
Still hoping for some response and advice on this... pretty sure the cron job not working is an issue for various things... 
Reply all
Reply to author
Forward
0 new messages