Once in a while, while migrating a CiviCRM website, the operation fails but doesn't roll back. In the following example, we're attempting a migration from 4.1.3 to 4.1.5. The aegir log of the 4.1.3 platform ends with the following messages:

dir(/var/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/membres.koumbit.org/files/civicrm/custom/CiviMail.processed): failed to open dir: Permission denied provision.inc:132

Drush command terminated abnormally due to an unrecoverable error. Error: Call to a member function read() on a non-object in /usr/share/drush/commands/provision/provision.inc, line 133

Output from failed command : CiviCRM upgrade was successful. Return to CiviCRM home page. [...] 
Fatal error: Call to a member function read() on a non-object in /usr/share/drush/commands/provision/provision.inc on line 133

As far as Aegir is concerned, the migration fails and the website keeps using the 4.1.3 platform. However, the website has already migrated to the 4.1.5 platform, and appears to be working fine. The drushrc.php is gone from the 4.1.3 platform. We can make the website visible again as a 4.1.5 platform in Aegir by running a few MySQL requests against the hostmaster database to assign the site to the newer platform, but isn't that overly hackish and risky?

It looks like the source of the problem may be (yet another) permission issue. And the failure could be more graceful...

Comments

urlisse’s picture

urlisse commented

Apparently, running cron from the URL under Aegir may cause the files/civicrm/custom/CiviMail.processed folder to belong exclusively to www-data and not to the aegir user. In this case, it caused the migration to fail.

Running cronjobs using the following command should avoid this permission issue.

drush @example.com -u civicron cvapi Job.execute

Still, a more graceful failure would be nice.

samuelsov’s picture

samuelsov commented

Maybe linked to this problem : http://drupal.org/node/1649250

bgm’s picture

bgm commented
Status: Active » Closed (cannot reproduce)

2 years without activity, closing issue. The recommended option to run the CiviCRM cron is now using the hosting_civicrm front-end module (which implements a CiviCRM cron queue). If you still have this issue using that option, please re-open the bug. Thanks.