Drupal 10, the latest version of the open-source digital experience platform with even more features, is here.After update to BOA-2.2.0 Stable Edition tasks in queue aren't running on master and o1 instance.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | barracuda.cnf_.txt | 2.23 KB | wickwood |
| #18 | barracuda_log.txt | 11.23 KB | wickwood |
| #10 | a02-drush_AThostmaster_hosting-dispatch_-d.txt | 15.06 KB | realityloop |
| #10 | a01-drush_AThostmaster_hosting-dispatch_-d.txt | 24.11 KB | realityloop |
| barracuda.cnf_.txt | 1.83 KB | zolee |











Comments
Comment #1
zolee CreditAttribution: zolee commentedComment #2
realityloopI'm experiencing this as well so far on 2 out of 2 servers it's happening
Comment #3
realityloopI've just upgraded to 2.2.1 and tasks still aren't running.
The time that they are expected to run just keeps incrementing.
Comment #4
omega8cc CreditAttribution: omega8cc commentedWe can't reproduce this, but please try to run manually and let us know if this results with any visible errors on command line:
$ bash /var/xdrago/run-USER(replace USER with your instance system username)Comment #5
omega8cc CreditAttribution: omega8cc commentedComment #6
cvining CreditAttribution: cvining commentedI've the same problem after upgrade to 2.2.1Never mind! After running barracuda, my queues had stopped getting processed. But I hadn't actually run the instance upgrade with:
octopus up-stable o1
I guess I'd assumed running barracuda upgraded instances too, but the docs clearly state what to do.
Comment #7
omega8cc CreditAttribution: omega8cc commentedYep, you have to upgrade all Satellite instances after running Master instance upgrade. We have tried to minimize major upgrade side effects, so not yet upgraded Satellite instances continue to work after Master upgrade (the websites), but things like backend tasks will stop working until you will upgrade also Satellite instance(s).
Comment #8
omega8cc CreditAttribution: omega8cc commentedI think we can close this?
Comment #9
realityloopThis is debug output from a server that was updated to 2.2.0 and then 2.2.1 where tasks are still not running
Comment #10
realityloopa01 was upgraded via 2.2.0, a02 was straight to 2.2.1
Comment #11
realityloopComment #12
omega8cc CreditAttribution: omega8cc commentedThis is a bug report. Tasks queue doesn't work on the Master Instance.
Comment #13
omega8cc CreditAttribution: omega8cc commentedFixed in HEAD: https://github.com/omega8cc/boa/commit/29974d2070b3bd9c9cc9ed9b85c583f71...
On stable please run the hot fix: https://github.com/omega8cc/boa/blob/master/CHANGELOG.txt#L39
Comment #16
realityloopTasks are processing again, thanks, also.. I did get the following output from the script:
Comment #17
omega8cc CreditAttribution: omega8cc commentedThis error is expected when you didn't install Octopus.
Comment #18
wickwood CreditAttribution: wickwood commentedPardon me for reopening this issue, but I just upgraded BOA-2.2.2 (both Barracuda and Octopus up-stable all) on my Linode Ubuntu 10.04 VPS and my queues are not executing either. (I skipped BOA-2.2.0 and BOA-2.2.1)
I tried running
bash /var/xdrago/run-wwm-hosting-adminand got this output:Not sure what to do now.
Thanks for your help in advance!
Steve
P.S. You will see in my barracuda_log.txt file that I ran the update 3 times today. The first time I forgot to change _SSL_FROM_SOURCES to YES, but it upgrade my OpenSSH anyway. But just to be sure I ran it again with SSL_FROM_SOURCES set to YES. I ran it again when with _STRICT_BIN_PERMISSIONS=NO because I could no longer use any commands in the Linode non-root user. See this issue: https://drupal.org/node/2236425
Comment #19
wickwood CreditAttribution: wickwood commentedActually upon further inspection of the last runs on /admin/hosting/queues, it appears that none of the queues (Task, Advanced Cron, Backup, Backup GC, and Task GC) have run since I did the upgrade this morning. Cron Queue is set to run every88 weeks and I have CiviCRM sites installed so that's why they are not included.
Comment #20
omega8cc CreditAttribution: omega8cc commentedPlease enable _STRICT_BIN_PERMISSIONS=YES, since you can't really disable this option once it was already used. Then run the upgrade again.
And then maybe read: https://github.com/omega8cc/boa/issues/296
Comment #21
omega8cc CreditAttribution: omega8cc commentedAlso, does your Octopus system user is "wwm-hosting-admin" ? The system tells you that there is no such user in the system: "Unknown id: wwm-hosting-admin"
Comment #22
wickwood CreditAttribution: wickwood commentedThat's what I thought it meant, but I am logged in on my Aegir Hosting System by Octopus as user "wwm-hosting-admin" and this is the user I have been using now for years, so I don't know why it would not be recognized now on the server side. However, for some reason I have 2 files in /var/xdrago/ - run-wwm-hosting-admin and run-wwmhosting-admin.
It's been a very long time since I originally set my BOA up, and I do recall having some issue with my user naming, so this is probably coming back to bite me now.
Also, I did read https://github.com/omega8cc/boa/issues/296, but failed to mention that whitelisting my non-BOA user solved the issue. However, i did not re-enable _STRICT_BIN_PERMISSIONS. I have done that now and I have re-run the
barracuda up-stable.After that I re-ran
octopus up-stable alland got message saying it was already up to date, but I could force reinstall of Aegir, Platforms or Both. I decided to force reinstall just Aegir.Upon doing this I noticed when it loaded the
/root/.wwmhosting-admin.octopus.cnfthat_USER="wwmhosting-admin".Also, the queues starting running again.
So I don't know what has gone wrong here, but I guess the question now is, do I have username issue here and if so how do I resolve this issue? I will start another thread if would like me to.
Thanks for your help!
Steve
Comment #23
mattman CreditAttribution: mattman commentedJust to chime in on this. I finished an upgrade from 2.1.3 > 2.2.2 yesterday and I just checked 1 of my two sites running on an o1 instance. Cron run says it's been 1 day and 5 hours. So I'm assuming, without having checked on the box yet, that cron runs are not happening for me.
I don't know if this is related to my other issue of #2237267: Troubleshooting https for aegir instance but it would seem that tasks have broken on my upgrade too.
Comment #24
omega8cc CreditAttribution: omega8cc commented@wickwood Having multiple dashes in the important system usernames is a bad practice. We can't really provide any assistance if you have managed to confuse both BOA and yourself to have scripts created for non-existing accounts, sorry.
Comment #25
omega8cc CreditAttribution: omega8cc commentedPlease don't re-open this *fixed* issue with incomplete and confusing reports. Instead make sure to debug this on your end and submit proper new issue with all required config files included, and in the correct queue.
Comment #26
wickwood CreditAttribution: wickwood commentedMy apologies, Omega8cc.
I did not intend to confuse or offend, indeed I was trying to do to the opposite.
Also, I did not know that having multiple dashes in the important system usernames is a bad practice that could cause an issue for BOA. I will open another issue later after I have done some additional debugging on my end.
Sincerely,
Steve
Comment #28
BarwonHack CreditAttribution: BarwonHack commentedserver:~# bash /var/xdrago/run-NAME
load is 184 while maxload is 350
... now doing CTL...
/data/disk/NAME/aegir.sh: line 4: /opt/local/bin/php: No such file or directory
CTL done
Investigation saw that /opt/local/bin/php was infact /opt/local/bin/php-old
I renamed and worked okay. Queues ran.
Chive working again too
Comment #29
BarwonHack CreditAttribution: BarwonHack commentedComment #30
omega8cc CreditAttribution: omega8cc commentedPlease read and follow docs and don't reopen already fixed issues just because you didn't read the docs or previous comments yet.