My cron job suddenly stopped working. Anyone have any thoughts?
Marc??
Thanks, J
I noticed a slowdown on the servers again....
my cron job seemed to disappear for half an hour....
check to see if it is running again and then post a complaint to support. I have been telling them there are problems but they seem to be unawares - LOL
my cron job seemed to disappear for half an hour....
check to see if it is running again and then post a complaint to support. I have been telling them there are problems but they seem to be unawares - LOL
I continue to have problmes with cron running. i contact dreamhost 3 times. these are their responses:
1. The script works fine and all, I found a lock file for that cronjob that
is probably the culprit. I removed the lock file, so it should start
working again. I really can't tell for another hour, so let me know if
it's still not working.
2. Well, I can tell you what I've been doing, but it shouldn't be locked
again. The other thing you can do is go to the Goodies / Cronjob part of the web panel select your cronjob:
https://panel.dreamhost.com/index.cgi?tree=goodies.cron¤t_step=Inde
x&next_step=ShowEdit&cronjob_id=25264
and Uncheck "use cron locking."
3. I'm sorry for the trouble. Have you tried disabling locking? I noticed
there was another lockfile that still existed from an earlier cron run
which I've removed. Please try running your job with locking disabled.
It's possible there's an issue with the locking mechanism. One way to
know for sure is if the job runs just fine without it. Let me know if
that helps.
How often are you running cron and are you getting reports and is cron ever completing? It looks like cron is either aborting and leaving the lock file or like it is hanging somewhere. You might try turning the cron job off and then just running cron from the command line with some debugging
[yourservername]$ wget --output-document=/dev/null --debug --output-file=debuginfo http://yourmoodle.org/admin/cron.php
[yourservername]$ wget --output-document=/dev/null --debug --output-file=debuginfo http://yourmoodle.org/admin/cron.php
Well, its only been three months ;=}
But I have now updated the DH wiki to in part at least address some of the confusion regarding the cron lock file issues with Moodle on DH.
First off, the DH tech person should have known better than to suggest removing the lockfile. "Old school" apps, like UUCP, created lockfiles when they ran that contained the PID of the process and removed them when they exited, so a lockfile left from an ended process could be a problem. But DH creates and uses a static lockfile via setlock (which itself typically uses flock). This means that rather than checking for the existence of a file to see if there is a lock, the application changes the perms on a specified file from 600 to 400.
See:
http://www.unixguide.net/unix/programming/2.5.shtml
http://en.wikipedia.org/wiki/File_locking
http://cr.yp.to/daemontools/setlock.html
If you use the DH Control Panel to create your cron job the Control Panel does not just insert the command you enter. If you check "Locking" as the Control Panel suggests, the cron command you insert invokes setlock, which uses the same specific lock file each time the cron command is run to prevent the command from running while an instance of the command is already running. You can configure shell access to view the actual crontab contents via crontab -l at the command line and then do an ls -al at the command line to verify that this is set to 600 (the file will look something like /tmp/cronlock.1234567.12345 - the digits in the file should be unique to this job.)
Since the command used by DH creates the lock file if it doesn't exist it technically doesn't hurt to remove it. Additionally, if the file is set 400, then removing it will have the same practical effect as changing the perms (which is as easy as "chmod 600 /tmp/cronlock.1234567.12345" (remembering that you have to use the name of the unique file identified in your crontab). That being said, the failure of the tech support person to actually report what the perms were indicate they were not acting in a competent manner in this regard.
Did DH give you any good advice? Barely. By removing the use of setlock you ARE removing the basis for the error message. BUT YOU ARE ALSO NOW ALLOWING MULTIPLE INSTANCES OF CRON TO RUN. This is equivalent to taking the battery out of your monoxide or smoke detector - LOL....
So what to do......
What is likely happening is that the shared system you are on is incapable of managing your cron job in an expeditious manner and most likely this is taking place when you have it set to do your weekly backups. Of course, if you are seeing dozens of the cronlock messages it is possible that you have your cron file set to run every 5 seconds instead of every 5 minutes.... but barring that, my guess is that the shared host you are on is barely able to manage with the current load, and that when cron.php starts doing any heavy lifting, things slow to a crawl and the next cron fails because the cron doing the heavy lidting has failed...... and this is not necessarily a bad thing..... indeed, one could argue that this functionality should be removed to cron.php, which would arguably obviate all the discussion about moving invocation of cron.php to the command line.....
So, you can argue with DH that the load on your system is too great - good luck with that. You could modify the script so that the error message is sent to /dev/null (in which case you never find out that there was a problem) or you live wth it, monitor the times and frequencies and if warranted create a little batch script in which to place the command which e-mails DH tech support everytime the cron fails providing them the error message and your appropriate salutations ..... You can tell where I am leaning here....
See also
http://wiki.dreamhost.com/Cron
and
http://wiki.dreamhost.com/Moodle
But I have now updated the DH wiki to in part at least address some of the confusion regarding the cron lock file issues with Moodle on DH.
First off, the DH tech person should have known better than to suggest removing the lockfile. "Old school" apps, like UUCP, created lockfiles when they ran that contained the PID of the process and removed them when they exited, so a lockfile left from an ended process could be a problem. But DH creates and uses a static lockfile via setlock (which itself typically uses flock). This means that rather than checking for the existence of a file to see if there is a lock, the application changes the perms on a specified file from 600 to 400.
See:
http://www.unixguide.net/unix/programming/2.5.shtml
http://en.wikipedia.org/wiki/File_locking
http://cr.yp.to/daemontools/setlock.html
If you use the DH Control Panel to create your cron job the Control Panel does not just insert the command you enter. If you check "Locking" as the Control Panel suggests, the cron command you insert invokes setlock, which uses the same specific lock file each time the cron command is run to prevent the command from running while an instance of the command is already running. You can configure shell access to view the actual crontab contents via crontab -l at the command line and then do an ls -al at the command line to verify that this is set to 600 (the file will look something like /tmp/cronlock.1234567.12345 - the digits in the file should be unique to this job.)
Since the command used by DH creates the lock file if it doesn't exist it technically doesn't hurt to remove it. Additionally, if the file is set 400, then removing it will have the same practical effect as changing the perms (which is as easy as "chmod 600 /tmp/cronlock.1234567.12345" (remembering that you have to use the name of the unique file identified in your crontab). That being said, the failure of the tech support person to actually report what the perms were indicate they were not acting in a competent manner in this regard.
Did DH give you any good advice? Barely. By removing the use of setlock you ARE removing the basis for the error message. BUT YOU ARE ALSO NOW ALLOWING MULTIPLE INSTANCES OF CRON TO RUN. This is equivalent to taking the battery out of your monoxide or smoke detector - LOL....
So what to do......
What is likely happening is that the shared system you are on is incapable of managing your cron job in an expeditious manner and most likely this is taking place when you have it set to do your weekly backups. Of course, if you are seeing dozens of the cronlock messages it is possible that you have your cron file set to run every 5 seconds instead of every 5 minutes.... but barring that, my guess is that the shared host you are on is barely able to manage with the current load, and that when cron.php starts doing any heavy lifting, things slow to a crawl and the next cron fails because the cron doing the heavy lidting has failed...... and this is not necessarily a bad thing..... indeed, one could argue that this functionality should be removed to cron.php, which would arguably obviate all the discussion about moving invocation of cron.php to the command line.....
So, you can argue with DH that the load on your system is too great - good luck with that. You could modify the script so that the error message is sent to /dev/null (in which case you never find out that there was a problem) or you live wth it, monitor the times and frequencies and if warranted create a little batch script in which to place the command which e-mails DH tech support everytime the cron fails providing them the error message and your appropriate salutations ..... You can tell where I am leaning here....
See also
http://wiki.dreamhost.com/Cron
and
http://wiki.dreamhost.com/Moodle
I'd appreciate if someone looked over my cron.php and give advice if it is doing what it should. This seemed to work, but I checked notifications and found that the cron hadn't run. We had a crash a while back, so maybe this got knocked off then.
I received this note:
So, I ran it manually and it posted out email messages and other functions, but I'm not sure if it is doing everything it should. I"ve checked in DH and it is enabled and the lock box is checked.
I have dreamhost, and this is the cron:
wget -q -O /dev/null http://www.moryafederation.net/portal/admin/cron.php
so far so good, but I'm not sure what I should have IN my cron.php. Is everything standard or what should I look for to ensure that it is working optimally, taking care of all crony business?
AND, then I get this:
Is my site not secure?
What can I do?
What do I have to set my dataroot to, and where do I do this?
thanks so much,
Vic
I received this note:
The cron.php maintenance script has not been run for at least 24 hours. 
So, I ran it manually and it posted out email messages and other functions, but I'm not sure if it is doing everything it should. I"ve checked in DH and it is enabled and the lock box is checked.
I have dreamhost, and this is the cron:
wget -q -O /dev/null http://www.moryafederation.net/portal/admin/cron.php
so far so good, but I'm not sure what I should have IN my cron.php. Is everything standard or what should I look for to ensure that it is working optimally, taking care of all crony business?
AND, then I get this:
Your site configuration might not be secure. Please make sure that your dataroot directory (/mnt/local/home/mfnet/moryafederation.net/portal/moodledata) is not directly accessible via web.
Is my site not secure?
What can I do?
What do I have to set my dataroot to, and where do I do this?
thanks so much,
Vic
In reply to V S
Re: cron job Dreamhost , site configuration not secure, cron.php
by Richard Enison -
VS,
Looking at the URL for your cron script and the pathname for moodledata, it is immediately obvious why you got that warning. From the URL, portal is the main Moodle directory. And where is moodledata? Right under it! Bad location, big time. See Installing Moodle#Creating_the_data_directory (when all else fails, read the instructions).
What can you do about it? Move it out of the web document root. If DH won't let you do that, use web server configuration settings to make it inaccessible to the drooling hackers out there with web browsers, chomping at the bit to get their paws on your moodledata directory. If your site uses Apache, put an .htaccess file in it, containing the line
deny from all
as documented in the above link. But then, there probably already is one there. See Tracker issue MDL-16957. If it uses IIS, change the permissions for moodledata, denying access to IUSR_servermachinename. See http://moodle.org/mod/forum/discuss.php?d=77868, especially posts by RH.
RLE
Looking at the URL for your cron script and the pathname for moodledata, it is immediately obvious why you got that warning. From the URL, portal is the main Moodle directory. And where is moodledata? Right under it! Bad location, big time. See Installing Moodle#Creating_the_data_directory (when all else fails, read the instructions).
What can you do about it? Move it out of the web document root. If DH won't let you do that, use web server configuration settings to make it inaccessible to the drooling hackers out there with web browsers, chomping at the bit to get their paws on your moodledata directory. If your site uses Apache, put an .htaccess file in it, containing the line
deny from all
as documented in the above link. But then, there probably already is one there. See Tracker issue MDL-16957. If it uses IIS, change the permissions for moodledata, denying access to IUSR_servermachinename. See http://moodle.org/mod/forum/discuss.php?d=77868, especially posts by RH.
RLE
In reply to Richard Enison
Re: cron job Dreamhost , site configuration not secure, cron.php
by V S -
Thank you, RLE.
As this installation was a one-click, and the instructions have not been easy for me to follow, if not find, or know all the settings I have or versions I need to know -- I have been remiss in knowing how to do this. I have a request in to DreamHost folks to see if they can assist.
Meanwhile, for my information --
If I move the moodledata directory -- will all my resource links be broken?
thank you,
Vic
As this installation was a one-click, and the instructions have not been easy for me to follow, if not find, or know all the settings I have or versions I need to know -- I have been remiss in knowing how to do this. I have a request in to DreamHost folks to see if they can assist.
Meanwhile, for my information --
If I move the moodledata directory -- will all my resource links be broken?
thank you,
Vic
Question:
This is the essence of my setup:
wget -q -O /dev/null http://www.mydomain.net/moodle/admin/cron.php
In looking at this page, about cron setup
the screenshot has this
mydomain / moodle / admin / cron.php
These are not different, so why is mine incorrect?
I do admit, I'm in way over my ahead doing a below average job.
I finally have school starting in a few weeks, and I'm still futzed with the cron and (after the crash?) did my data directory get moved? It used to work, and be secure.
Very confused, if anyone can take pity and baby step me through this. I wish I could understand moodle a bit. (I have been working on computers since 1983, and this program may finally do me in.)
Vic
This is the essence of my setup:
wget -q -O /dev/null http://www.mydomain.net/moodle/admin/cron.php
In looking at this page, about cron setup
the screenshot has this
mydomain / moodle / admin / cron.php
These are not different, so why is mine incorrect?
I do admit, I'm in way over my ahead doing a below average job.
I finally have school starting in a few weeks, and I'm still futzed with the cron and (after the crash?) did my data directory get moved? It used to work, and be secure.
Very confused, if anyone can take pity and baby step me through this. I wish I could understand moodle a bit. (I have been working on computers since 1983, and this program may finally do me in.)
Vic
you put moodle in the portal subdirectory
A search on wget and cron here will pull up these two discussions, one of them providing cron entries useful for debugging:
http://moodle.org/mod/forum/discuss.php?d=97603&parent=432477
http://moodle.org/mod/forum/discuss.php?d=109111&parent=479213
I missed the part about a crash??
A search on wget and cron here will pull up these two discussions, one of them providing cron entries useful for debugging:
http://moodle.org/mod/forum/discuss.php?d=97603&parent=432477
http://moodle.org/mod/forum/discuss.php?d=109111&parent=479213
I missed the part about a crash??
VS,
the DH one clicks are typically very effective and very simple. Your initial problem is that you did not use a subdomain for moodle (the easiest way to accomplish Moodle on DH) and you got confused then as to the location of moodledata.....
Changing things about may result in having to manually fiddle your config file and running replace.php, or if you want you can blow away your portal subdir and create a subdomain named portal and then install moodle to that subdomain from oneclick, but use the db you already created (if you want to keep the data there) or just create a new db. If you keep the current db, you will need to run replace.php after the moodle install is done to make sure the contents of the db point to the correct moodle locations.
how are you trying to run cron.php, from CLI or via URL? If you set your site policies to only run CLI then the wget command won't work.... I just ran it from the web so it looks like you are using the URL method.
wget -q -O /dev/null http://www.moryafederation.net/portal/admin/cron.php
should work just fine if you have the rest of the panel set correctly.... if it doesn;t then post to tech support because you have it set correctly.
There is also a DH wiki page on Moodle.
the script has to be enabled and the user has to be the username of the account owner or some who has perms to run the cron tab. Set the cron to "custonm" "every ten minutes" every hour, every day, every month, every day of the week./
There is nothing you have to do to cron.php you are using the crontab to run cron.php.
the DH one clicks are typically very effective and very simple. Your initial problem is that you did not use a subdomain for moodle (the easiest way to accomplish Moodle on DH) and you got confused then as to the location of moodledata.....
Changing things about may result in having to manually fiddle your config file and running replace.php, or if you want you can blow away your portal subdir and create a subdomain named portal and then install moodle to that subdomain from oneclick, but use the db you already created (if you want to keep the data there) or just create a new db. If you keep the current db, you will need to run replace.php after the moodle install is done to make sure the contents of the db point to the correct moodle locations.
how are you trying to run cron.php, from CLI or via URL? If you set your site policies to only run CLI then the wget command won't work.... I just ran it from the web so it looks like you are using the URL method.
wget -q -O /dev/null http://www.moryafederation.net/portal/admin/cron.php
should work just fine if you have the rest of the panel set correctly.... if it doesn;t then post to tech support because you have it set correctly.
There is also a DH wiki page on Moodle.
the script has to be enabled and the user has to be the username of the account owner or some who has perms to run the cron tab. Set the cron to "custonm" "every ten minutes" every hour, every day, every month, every day of the week./
There is nothing you have to do to cron.php you are using the crontab to run cron.php.
Dear Marc:
Thank you so much for these replies.
(You guys are a lifeline -- )
Also, I got a good note back from DreamHost. I noticed on their site that they have a .htaccess, WebDav (for those on DH: https://panel.dreamhost.com/index.cgi?tree=goodies.webdav¤t_step=DS&next_step=Add)
______________________
The DH guy said he set me up for Webdav, but I don't see (in DH) my site configured with it (yet) ... and I still get this in moodle:
The moodle notification 'your site may not be secure'.
However, I'm assuming this is due to the placement of the moodledata directory, and that the web FTP block is solving the situation?
Or, perhaps the setting hasn't yet been put in place; I'm following up with DH now, but it sounds like this is the fix for this situation.
About your comment on the subdomain -- I never thought about that at all. When I went to install, I did the one-click. I don't really understand subdomains, but don't recall being asked to create one.
Thanks again for any hints, or 'dire warnings'!
Vicktorya
Thank you so much for these replies.
(You guys are a lifeline -- )
Also, I got a good note back from DreamHost. I noticed on their site that they have a .htaccess, WebDav (for those on DH: https://panel.dreamhost.com/index.cgi?tree=goodies.webdav¤t_step=DS&next_step=Add)
"Restrict access to any of your domains through the use of an .htaccess file. You can use this web interface to create usernames and passwords for your friends and associates to access password-protected sections of your websites. You can even use an .htaccess file to help prevent hotlinking of your website files by outside parties.
Enabling WebDAV will allow you to edit and publish your website collaboratively on our web servers."
from DH: "It will not block the FTP connections, but it WILL block web connections.That's a good thing. You don't want outside people getting to your data."
______________________
The DH guy said he set me up for Webdav, but I don't see (in DH) my site configured with it (yet) ... and I still get this in moodle:
The moodle notification 'your site may not be secure'.
However, I'm assuming this is due to the placement of the moodledata directory, and that the web FTP block is solving the situation?
Or, perhaps the setting hasn't yet been put in place; I'm following up with DH now, but it sounds like this is the fix for this situation.
About your comment on the subdomain -- I never thought about that at all. When I went to install, I did the one-click. I don't really understand subdomains, but don't recall being asked to create one.
Thanks again for any hints, or 'dire warnings'!
Vicktorya
gadzooks, now I get this error on my backups:
Why are they being skipped or having errors ... ?
(sigh)
investigating again,
v
Summary ================================================== Courses: 60 OK: 0 Skipped: 46 Error: 14 Unfinished: 0
Why are they being skipped or having errors ... ?
(sigh)
investigating again,
v