run cron on remote servers instead of locally

Changing the issue title.

You are probably right here, and I agree the cron should be run local to the server.

As a workaround, you should be able to use the wget-style cron, but lookout for #1090678: wget cron method broken for d7 sites.

This is also needed to support modules like backup_migrate which which operate on the site's files/tmp directory. Consider the following code which is called via backup_migrate_cron():

backup_migrate/includes/files.inc:

  // Delete temp files abandoned for 6 or more hours.
  $dir = file_directory_temp();
  // Altered for testing!!!!
  //  $expire = time() - variable_get('backup_migrate_cleanup_time', 21600);
  $expire = time() - variable_get('backup_migrate_cleanup_time', 1);
  if (file_exists($dir) && is_dir($dir) && is_readable($dir) && $handle = opendir($dir)) {
    while (FALSE !== ($file = @readdir($handle))) {
      // Delete 'backup_migrate_' files in the temp directory that are older than the expire time.
      // We should only attempt to delete writable files to prevent errors in shared environments.
      // This could still cause issues in shared environments with poorly configured file permissions.
      if (strpos($file, 'backup_migrate_') === 0 && is_writable("$dir/$file") && @filectime("$dir/$file") < $expire) {
        unlink("$dir/$file");
      }
    }
    closedir($handle);
  }

If cron is called via drush, this code will attempt to clean up the *hostmaster* copy of the site instead of the live site on the remote webserver. Clients with a lot of data (consider the backup_migrate_files sister module) could fill up their file system quickly if this isn't running on the correct server.

Switching to wget as mentioned above remedies the problem.

Is this a drush problem with remote aliases? Shouldn't it run on the remote if the alias says the server is remote?

I have a concern or two about running cron via wget.

1. Some hosting setups behind firewalls are NATed and do not resolve the domain to an internal IP to access the site.
2. Not specific here, but it is kinda nice to be able to segregate cron jobs to run on a separate machine from the web front ends.

I've run into a similar problem with a site that's using Feeds Imagegrabber to grab images out of a feed, store them locally and attach them to a filefield as part of a cron job. The problem is that when cron is run via Drush from the Aegir master, the images get downloaded to the Aegir master, and not to the remote server where thy should be.

As mentioned above, switching to the web based cron gets around the issue, but it's not my preferred method of running cron.

Really, Drush should be being run directly on the remote server, not on the Aegir master.

This isn't going to get fixed in the 1.x branch, the solution there is to use wget cron. We'll get this done in 2.x however, marking as critical for that branch, as the current way of doing it is really stupid (although much simpler!)

Also seems to effect clearing the boost cache - my assumption is that its trying to remove the files locally, which is why the cached files get left on the remote server.

The plan for remote servers, as I understand it, is to make them 'smarter'. This would move us from our current hub/spoke model to a mesh model. That is, have them run Provision, manage their own queue, etc. I can't seem to find the issue where this was being discussed though... Anyway, I'm pretty sure that'll solve this issue, as the remotes will have aliases for the sites running on them.

This work will be undertaken in 7.x-3.x. Also, 'critical' and 'feature request' are usually mutually exclusive.

i wish we had that 3.x version already - can't we create a dev release or something? :)

Due to the error message in this thread I wasn't able to do a migrate task in Aegir.
Setting the option "On failure" at /admin/config/search/apachesolr/settings to "Show no results" at least helped me further.

Question: Is the actual unix crontab utilized at all right now? Is the queue runner the thing that triggers cron on hosted sites?

Since unix crontab is a service and we can restart it, why not start using it, much like we do with apache?

On site verify, we could add a crontab entry for the site on whatever server it is on, and restart it.

If we do that, not only would we be able to setup cron on remote servers, we could have the cron timing configurable per site, which would be really useful.

I think adding more sudo restart privileges for different services is a good thing if it allows us to automate more things.