Posted by Anonymous on December 22, 2012 at 5:41pm
For the first time since I installed BOA a month ago I am logged in as o1.ftp user and have cd'd to the only site in the commerce 7.17 platform, and I did a "drush mup" - after 10 minutes on the command line I get a response: "Checked available update data for 632 projects"! About 8 hours later, nothing has happened on the command line with the ssh connection still open - no confirmation of any updates taking place ....
Is anything wrong here?
I am guessing that drush is in fact checking for updates on all the installed and enabled modules in all the platforms on the BOA server. Is this what is happening? If so, is it usual for it to take a half day or more?
Thanks for any confirmation if anyone has had this kind of experience.
Eddie
Comments
632 modules?
No, it checks for updates only for this one site only, but I can't believe you have 632 modules there?
Anyway, any drush task will terminate itself after 30 minutes (or 1 hour starting with BOA-2.0.5), so if something "runs" that long, it already timed out after 30 minutes.
thanks for your response
NO, it's just the default commerce 7.17 platform ... probably has 60 - 100 modules and only half or less enabled. I'll try again, but this has already happened once before. I'll investigate further.
273 modules deault fo commerce kickstart 7.17 - 70 enabled
Actually the commerce kickstart platform has 273 modules - and about 70 are enabled.
I try the same thing on the only site I installed on the nodestream 7.17 platform - it has core modules + 183 modules (many of which I added for i18n etc) and 124 are enabled - and the dbup returned a success (with no database updates needed), however after 20 min I got a return in the terminal command telling me the platform, the drupal core and xmlsitemap needed updating. I said OK and got an error - unable to download nodestream core - and the attempted rollback failed because
data/disk/o1/distro/001/nodestream-7.x-2.0-beta8-7.17.1/profiles/nodestream/modules/contib is not writable ...
that directory has a UID of 111 and a GID of 100 and is chmod 755 - does it need to be 775?
Does this error message give you any help understanding why in the other platform it "saw" 632 modules?
Number of modules
I had a similar thing a couple of days ago on a Drupal 7.17 site (on boa 2.0.4). A simple site with 20 contrib modules enabled (but a lot more available in sites/all/modules). I did "Check manually" on admin/reports/updates, and it reported something around 280 projects checked. I did not have the "Check for updates of disabled modules and themes" option enabled.
unable to update
I was able to update the contrib module (so says the termoinal but the site repost says it wasn't updated) but not the platform by changing UID to 999 and permissions to 775 (from 111 and 755) - perhaps only the 755 to 775 was needed?
But cannot update core (drupal root path is no writable) or platform as o1.ftp user.
Attempting to update the problematic commerce kickstart 7.17 platform gives me the same result - nothing at all
I'll read the guides more and see if I missed something about permissions...that need to be manually set
Same error no update on open deals platform
So next I cd'd to the only site I have on the open deals platform:
/data/disk/o1/distro/001/opendeals-1.11-7.17.1/sites/domain.com
and ran "drush mup" and the return was "Checked update data for 521 projects" - and there are not 521 modules on that platform. Still no response after 1 hour... What is going on here?
On the other hand, two sites in a static platform have successfully been updated - both the modules and the drupal core, with no errors in the terminal ... even though the terminal return gave "Checked update data for 1185 projects" - this must be for all the static platform sites, as the site it was checking for has 200 modules only.
Later going back and running "mup" and "dbup" again on each o the sites in the static platorm gave me terminal returns like "Checked update data for 1 project" or 20 projects... very bizarre behavior.
Note
We have now added new mapping, so now it should at least map the mup alias to the expected real command: http://drupalcode.org/project/barracuda.git/blob/HEAD:/CHANGELOG.txt#l83
Also,
If you can reproduce this (I can't), please open new issue in the Octopus project queue.
Working fine now after upgrade to BOA 2.0.5
This problem has disappeard for me after upgrading to BOA 2.0.5, so I can't even try to reproduce it. Thanks for your work.