Create Account or request a free Test Drive
Already 900+ hosts powering thousands of Drupal sites are running on our high-performance Aegir BOA stack
© 2009-2023 Omega8.cc | ul. Zlota 59, 14th floor Skylight Building, 00-120 Warsaw, Poland | Twitter
Smokin’ Fast Drupal Hosting in Amsterdam · Chicago · Frankfurt · London
Madrid · New York · San Jose · Singapore · Sydney · Toronto · Warsaw
© 2009-2023 Omega8.cc | ul. Zlota 59, 14th floor Skylight Building, 00-120 Warsaw, Poland | Twitter
Smokin’ Fast Drupal Hosting in Amsterdam · Chicago · Frankfurt · London
Madrid · New York · San Jose · Singapore · Sydney · Toronto · Warsaw
Important
Always try to debug the issue before deleting the node in Aegir, since it will delete also all associated task nodes, and you will lost also all connections to any existing backups created for this site in Aegir before.
Hint about tasks "spinning forever"
Sometimes the task doesn’t fail, but keeps “running”, while in fact it already timed out in the Aegir backend and only failed for some reason to report failure (or success!) in the frontend.
It happens for sites with big ‘files’ directories, since Aegir creates full, compressed archive from entire sites/domain directory and it may take longer than allowed server limit, but it is still possible that this never ending, “running” in the frontend task in fact already cloned or migrated the site successfully.
To fix this problem you need to:
1. Disable JavaScript in your browser.
2. Click on the “View” link of the “running” task.
3. Click on the Edit tab on the task node.
4. Replace /node/123/edit with /node/123/delete in the URL.
5. Hit Enter on your keyboard.
6. Confirm to delete the task node.
7. Now re-verify the platform to allow Aegir discover the site (if created).
8. Re-verify the site if found. Done.
Note: you can safely use this procedure only when the task keeps spinning longer than 15 minutes.
Hint about Clone or Migrate tasks "spinning forever"
This may sound tricky, but it is also easy to fix, just not as simple as previous examples.
The problem is, that the timed out Migrate task already moved the site to different platform (probably – you can always make sure where the site really is by checking both platforms directories via FTP or SSH). And the same with Clone task, if its target platform was different – so effectively causing migration.
In this case you also need to delete the “spinning” task to unlock the tasks queue (as any next tasks will wait forever until this timed out task finishes – while there is no chance it will happen without your intervention).
But before you will go to the steps nr 7 and 8 above (platform and site re-verify), you must delete also the migrated/cloned site node in Aegir first. Otherwise Aegir will not discover the site in the newer platform (because it refuses to create duplicate sites with the same domain) and will also fail to re-verify the site in the old platform, because in fact the site is no longer there!
Warning! Don’t mix up deleting site’s or platform’s node with using the Delete task!
Large sites/default/files - more trouble than it's worth?
I’m not using omega8’s hosting, but I am following their (awesome) advice and using their (awesome) Aegir scripts on my VDS.
I’ve recently had some rather unpleasant experiences trying to pull in a site on a shared host with a sites/default/files folder that was around 2GB.
“All i wanted to do” was clone the site on my own server so i could smash out some debugging without affecting the live server, but when following the Omega8 import recipe, the migrate task hung (overnight) and the platform was unusable after following these instructions and trying again – themes were breaking because Drupal couldn’t find system paths, and re-verifying the platform/site didn’t help.
after much Googling and desperation (like many Drupal developers out there, i’m still a bit of an Aegir noob) i reimported the site without the files folder, then used Devel Generate to wipe the now-broken nodes and replace them with dummy content after i was 100% sure the import worked.
struggling with a large “1:1” import including files+content = 2+ days
pulling in code+database only and using dummy content = 15 minutes
Always symlink large files directory
Aegir by default creates full, compressed archive from entire sites/domain.name directory on every Clone, Migrate, and of course Backup task, so it will fail on servers without enough RAM and CPU power to handle this before PHP-CLI or SQL connection will timeout.
It is known issue and there are plans to move files directory away from sites/domain.name by default and only symlink it there, but it is not implemented yet, so you need to use manual workaround for large files directories and move them away, anywhere in the tree, for example to /data/disk/USER/static/domain_files and then ln -s /data/disk/USER/static/domain_files /path/to/platform/sites/domain.name/files.
so, what you’ve just written
so, what you’ve just written there should replace Step 5 here: http://omega8.cc/import-your-sites-to-aegir-in-8-easy-steps-109
Not exactly
I added it as a Hint nr 6 there, as it should be used only when the files directory is really big, and not by default. Thanks.
ah, that certainly would have
ah, that certainly would have helped us a week ago >.< i’m sure we’ll be doing something similar again in the future so thanks!
no need to disable javascript
A simpler method: right click on the “View” link of the running task, and select Open in New Window or New Tab.