In experimenting with the latest OpenPublish release (2.3), I discovered some odd behaviour on 0.4-beta1. Platform verification works just fine, but site creation appears to hang, continuing to show the throbber for the "install" task. However, the site actually installs correctly, and via the welcome email, is accessible and functional.
I've marked this issue as "major" since it blocks any further action (backup, migrate, etc.) on this otherwise functional site.
The (complete) install log shows:
Log message
Task starts processing
Running: /usr/local/bin/php /var/aegir/drush/drush.php --php=/usr/local/bin/php --uri='op2.ergonlogic.net' provision-save '@op2.ergonlogic.net' --backend
Drush bootstrap phase : _drush_bootstrap_drush()
Found command: provision-save (commandfile=provision)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @self
Load alias @server_master
Loading mysql driver for the db service
Loading nginx driver for the http service
Load alias @platform_OpenPublish23
Load alias @op2.ergonlogic.net
Template loaded: /var/aegir/.drush/provision/provision_drushrc_alias.tpl.php
Generated config Drush configuration file
Changed permissions of /var/aegir/.drush/op2.ergonlogic.net.alias.drushrc.php to 400
Command dispatch complete
Peak memory usage was 7.65 MB
Running: /usr/local/bin/php /var/aegir/drush/drush.php --php=/usr/local/bin/php @op2.ergonlogic.net provision-install --backend
Comments
Comment #1
omega8cc commentedI believe you should post this as an Open Publish bug. This is not an Aegir bug (IMO), so changing this to support request. Aegir projects is not responsible for making all existing Drupal distros Aegir-compatible. It is a distros authors job. I debugged some of them in the past and it was always distro and not Aegir fault. See also: https://github.com/omega8cc/nginx-for-drupal/commit/3561a54d7ce94cc0abbf...
Comment #2
ergonlogicOkay, I agree that some root problem may be on OpenPublish's part. My point in filing this issue wasn't so much trying to get OpenPublish to work properly, but rather that the way in which Aegir fails is odd. It seems to me that the install task should either succeed or fail, but not stay in some kind of limbo state. In fact, OpenPublish's install actually succeeds, but this is never recognized by Aegir. Alternatively, if the problem really is with the platform, then perhaps a check could be introduced so that the platform won't verify.
As an update, clicking "enable" makes all the other regular functions available. But the install task maintains its throbber icon, and the install tasks log never progresses beyond the "provision-install" stage.
Comment #3
omega8cc commentedThat kind of distro's fail is rather hard to catch and report by the Aegir backend, since it is caused by php-cli process timeout, so by definition, there is no chance to "stop" this task and report the problem, thus, it must be fixed in the distro's install profile and there is nothing we could do in Aegir, IMO.
Comment #4
Anonymous (not verified) commentedThe issue of the task getting stuck in a queued state may mean that the frontend never gets a return from the backend, which could even be a Drush bug.
You would at least expect php to time out and even exit with an error as a result though.
This should probably be investigated with --debug to see what exactly is causing it to hang.. or why it doesn't give up hanging.
Comment #5
omega8cc commentedBTW: latest OpenPublish 2.3 release works without issues, however provisioning a site takes ~5 minutes, so it is important to not introduce any too low (timeout) limits for php-cli and MySQL.
Comment #6
Anonymous (not verified) commentedSo if this actually works as Grace says, but depends on a timeout value in php, I suggest this be added to the FAQ
Comment #7
pindaman commentedsame problem here,
install hangs after succesfull email.
- standard drupal 7 site
Task starts processing
Running: /home/aegir/drush/drush.php --uri='site.nl' provision-save '@site.nl' --backend 2>&1
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Bootstrap to phase 0.
Found command: provision-save (commandfile=provision)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @self
Load alias @server_localhost
Load alias @server_master
Loading apache driver for the http service
Loading mysql driver for the db service
Loading apache driver for the http service
Load alias @platform_drupal7
Initializing drush commandfile: user
Load alias @site.nl
Template loaded: /home/aegir/.drush/provision/provision_drushrc_alias.tpl.php
Changed permissions of /home/aegir/.drush/site.nl.alias.drushrc.php to 600
Generated config Drush configuration file
Changed permissions of /home/aegir/.drush/site.nl.alias.drushrc.php to 400
Command dispatch complete
Peak memory usage was 8.74 MB
Running: /home/aegir/drush/drush.php @site.nl provision-install --backend 2>&1
has it been fixed?
Comment #8
alfthecat commentedI am changing this to a bug report, for I am experiencing this (hostmaster 1.1) as well, regardless of the profile I select. I suspect this issue is caused by manually deleting of sites / tasks. In my case it suddenly happened to new install tasks, verifying works fine but install tasks hang (in one case after 13 hours it is still going).
Sites appear to be created but no email is sent and the install icon keeps rotating, not allowing access to the sites from the front end.
I tried verifying hostmaster and the hosting website several times, updated the db, flushed caches but nothing helps. Installing sites just simply stopped working.
Status: Processing
Started: Sun, 08/07/2011 - 01:17
Processing time: 13 hours 16 min
Log message
Task starts processing
Running: /usr/bin/php /var/aegir/drush/drush.php --php='/usr/bin/php' --uri='test3.vps7285.[..].net' provision-save '@test3.vps7285.[..].net' --backend 2>&1
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Bootstrap to phase 0.
Found command: provision-save (commandfile=provision)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @self
Load alias @server_localhost
Load alias @server_master
Loading apache driver for the http service
Loading mysql driver for the db service
Load alias @platform_DEV13
Initializing drush commandfile: user
Load alias @test3.vps7285.[..].net
Template loaded: /var/aegir/.drush/provision/provision_drushrc_alias.tpl.php
Generated config Drush configuration file
Changed permissions of /var/aegir/.drush/test3.vps7285.[..].net.alias.drushrc.php to 400
Command dispatch complete
Peak memory usage was 9.68 MB
Running: /usr/bin/php /var/aegir/drush/drush.php --php='/usr/bin/php' @test3.vps7285.[..].net provision-install --backend 2>&1
Comment #9
omega8cc commentedUnless there are steps to reproduce, it is not a bug.
It doesn't really hang, it simply timed out already, see for reference: http://omega8.cc/aegir-task-fails-or-spins-forever-126
You may want to increase limits for php-cli (memory+time) and maybe mysql limits if that is not platform specific.
Comment #10
alfthecat commentedHi omega88cc, thanks for your reply. I had found that article, but thanks anyway for the gesture.
I had to completely wipe the server and re-install Aegir to get it fixed. As I'm not sure what caused the issue I'm afraid I can't provide any steps to reproduce the issue. The only clue I can give is that (perhaps) the deletion of nodes causes this.
And in terms of 'really hanging', in my case not all sites were being created whilst the install task kept running. The ones that appeared to be created were not accessible by visiting their respective url's. So to me it felt like the task was 'really hanging'...
Comment #11
anarcat commented