I upgraded a few boxes from 1.10 + hosting queue runner to 2.0, and hosting-queued wasn't enabled.

Comments

helmo’s picture

helmo CreditAttribution: helmo commented

Any logs?

The drupal module is enabled?

What does an manual restart command have to say?

anarcat’s picture

anarcat CreditAttribution: anarcat commented

the drupal module wasn't enabled. didn't look at logs. manual restart returns without an error but doesn't restart it.

drush @hostmaster en hosting-queued makes the daemon startable, but then i got hosting-dispatch tasks piled up.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

it seems that enabling the module doesn't properly disable the task queue... this leads to horrors because the hosting-dispatch tasks pile up waiting for the lock that hosting-queued holds (guessing here).

anarcat’s picture

anarcat CreditAttribution: anarcat commented

the full workaround:

drush @hostmaster vset hosting_queue_tasks_enabled 0
drush @hostmaster en hosting_queued
ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

I haven't been able to replicate "enabling the module doesn't properly disable the task queue". In my tests this works just fine.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

I've run into the issue where running '/etc/init.d/hosting-queued start' doesn't provide any feedback when the module wasn't enabled on the hostmaster site. Should the init script catch that and enable the module? It should, at least, provide some useful feedback, no?

But even so, we don't even try to start/re-start the queue daemon on 1.x to 2.x upgrades, afaict:

[...]
                echo "upgrading the frontend from $drupal_root to $NEW_PLATFORM"
                if su -s /bin/sh aegir -c 'drush @hostmaster pm-list --status=enabled --pipe' | grep -q hosting_queued; then
                    service hosting-queued stop
                fi
                cd "$drupal_root"
                su -s /bin/sh aegir -c "drush hostmaster-migrate $FLAGS '$site_uri' '$NEW_PLATFORM'"
                echo "upgrade finished, old platform left in $drupal_root"
                # restart daemon if enabled
                if su -s /bin/sh aegir -c 'drush @hostmaster pm-list --status=enabled --pipe' | grep -q hosting_queued; then
                    service hosting-queued start
                fi
[...]

For that matter, we don't stop the hosting-queue-runner service either, so other queued tasks might end up being triggered during the migration.

On 1.x->2.x upgrades, I think we should:

  1. stop the hosting-queue-runner service
  2. disable hosting_queue_runner, if it exists
  3. remove the hosting-queue-runner init script
  4. enable hosting_queued by default
  5. start the hosting-queued service
anarcat’s picture

anarcat CreditAttribution: anarcat commented
Priority: Critical » Major
Issue summary: View changes

this doesn't strike me as critical, and there's an easy workaround, downgrading.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented
Status: Active » Closed (outdated)

The 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open, or better yet, create a new issue referencing this one.