hosting queue runner doesn't restart properly on 1.10 to 2.0 upgrade

Any logs?

The drupal module is enabled?

What does an manual restart command have to say?

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

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

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.