cron task replacement logic uses deprecated command without --uri, breaks cron
adrinux - October 24, 2009 - 10:09
| Project: | Hosting |
| Version: | 6.x-0.4-alpha2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Description
mig5 spotted this whilst discussion my problem on irc ;)
Hosting inserts the correct crontab command if crontab is clean.
*/1 * * * * (php '/var/aegir/drush/drush.php' hosting dispatch --root='/var/aegir/drupal-6.14' --uri=aegir.example.com)but if hosting setup is run a second time, or a previous crontab entry exists and needs to be replaced we get:
*/1 * * * * (php '/var/aegir/drush/drush.php' --root='/var/aegir/drupal-6.14' hosting dispatch > /dev/null)and cron fails.
#1
So I think I have a fix for this.. Adrian does this look sane? (wasn't sure about the regex, also not sure if I should account for the chance that --uri isn't passed as an argument)
#2
Looks good at first glanced, haven't tested.
#3
I don't think it's working. Don't know what's wrong with me.
#4
Committed a working version, some cleanup and code documentation too.
#5
I'm getting this in DRUPAL-6--0-4-ALPHA2
(everything else, drupal, drush todays stable versions, as instructed in install.txt)
Does 'fixed' mean 'fixed in dev' only? It is critical (install just does not work) against -4-ALPHA2 so another release soon may be good.
I figured it out and updated the crontab manually in the meantime.
#6
Yes it meant fixed in HEAD, I didn't supply a hotfix for alpha2 sorry. Yes, if you've solved it, I'd sit on it til alpha3 is released (which is very imminent)
Cheers!
P.S it shouldn't stop install from working as you say: this issue only appears if 'hosting setup' is run more than once (i.e an upgrade from an older version). If your install is not working, you may have a separate issue.
#7
Well, I had about 17 goes at it, making various mistakes as I went (the back buttons on the hostmaster setup wizard don't actually work), but this was the only one I could see that didn't seem to be my own incompetence (and I could fix myself). So yeah, there probably were multiple runs happening. :-}
I'm not using sites/default at all. this seems to confuse drush sometimes.
I'm getting what looks like a similar issue with provisioning as well. if URI is really always required (boring?) then that may be why I'm seeing provisioning errors. Could be anything else though :-/
Mostly battling through though.
For now I've added a default uri in
~aegir/.drushrc.phpand I've not seen so many problems since<?php// drush always needs uri set if not in the actual site dir. (and we have no sites/default ?)
// Our default will be the master site
$options['uri'] = 'http://aegir.monster';
?>
#8
Correct, we don't use /sites/default, the aegir site is a site in its own right on that platform. In order to bootstrap any other site, the --uri argument is needed, or else it falls back to sites/default.
But this is outside the scope of this (fixed) issue, please do open a separate support request if you need.
Cheers
#9
Automatically closed -- issue fixed for 2 weeks with no activity.