-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web client hanging forever #639
Comments
Having the same issue with RabbitMQ broker. Workers work as expected but flower (0.9.1) hangs. |
|
|
My problem was ssl connection problems. Unrelated to flower... was a certificates permissions error on the filesystem |
I'm having the same issue with Redis in OSX El Capitan. Going to: http://localhost:5555/ hangs. It doesn't display anything. |
I've having the same issue. Flower hanging indefinitely. Seems to start normally and displays all registered task. |
Same issue, hangs forever. There is nothing descriptive logs on debug mode |
I ran into this issue while using Redis Sentinel to connect to Flower. Celery couldn't resolve a DNS name I passed in but Flower didn't display an error message. It would hang when I tried to connect to it. It's extremely frustrating that there's no error message when Flower fails to connect to its broker and it's unclear to me why this failure results in an inability to set up the web client. Here's my start up log:
|
Every time i have experienced this is usually a celery config issue with the log suppressed by flower. |
Same issue here ... Happened after I switched to eventlet or gevent to run my tasks. |
I'm having the same issue here. If you are using WSL/Bash on Windows, this might be a result of a known compatibility issue between In my case, I was using I quickly ran a Hope this can help. |
Just ran into this issue. I added the following lines to the beginning of my Flask app to fix an issue with websockets. import eventlet
eventlet.monkey_patch() Commenting this out resolved the issue with Flower, so as @ocervell mentioned eventlet is involved somehome. Will need to find a workaround. Update: Downgrading amqp to 2.1.1 did not resolve the issue. |
Having similar problems with |
I encountered similar problem as well with: |
Same issue: flower==0.9.2 |
Having the same problem: |
I switched from |
Flower was hanging for me, added gevent via pip3 and started with
|
Any solution for this issue ? |
with --pool gevent I cannot see any workers online |
I'm getting this when trying to click one the workers and inspect it's configs and details , any idea how to solve this or how to make flower be able to resolve DNS for the worker if that is indeed the problem? |
I performed a 'FLUSHALL' on redis via the redis-cli and then restarted flower and it started to work. |
Having the same problem with docker. Running directly on the machine flower works normally, but inside the container it hangs forever.
|
I believe you have to start the redis server first. If there is no active redis server, flower does not give you an error but it will just keep looking for one and trying to connect to it resulting in it hanging. So to start a simple redis server just type redis-server in your terminal. After that run flower. |
I have the same issue, in my case it can be resolved by adding --config argument.
checkout this jira for detail: |
For my case, I examed the connection between flower and rabbitmq / redis, got the issue resolved after the connectivity works well. |
I'm not sure if this is the same issue or not but I've been having problems where my celery was getting heartbeat timeout issues with rabbitmq as a broker. I followed a few workarounds where people disabled the hearbeat for rabbitmq and celery. This fixed the timeout problem but ended up causing this bug with flower where about 5 seconds after booting up flower, the webclient would hang forever. After adding the heartbeat back, my flowers webclient has gone back to normal. |
I have flower-0.9.3 and tornado-5.1.1. After downgrading Tornado to v4.5.2 Flower works correctly (see #788 (comment)) |
Can someone try https://github.com/mher/flower/compare/issue639 fix? |
Any fix in 2020? Mine is working well in dev server, but it won't work in prod server.
|
@sillycube any output from flower? Everything appears to be running fine on prod for us, but we're also experiencing no response/hanging..
With EDIT: I added |
I believe the problem has been narrowed down to |
Hi @ckcollab, I tried to change the ports from 5555:5555 to 5556:5555 and I can access flower with the new link. But I don't know what I did wrong |
The problem for us ended up being the hostname wasn't resolving over docker properly, on the different port. On port |
This is due to flower not being able to connect to the broker.
Here, "--broker=amqp://rabbitmq:5672" is used to connect to the "rabbitmq" container |
Hi, In my case it was able to connect with the broker, so this was not the issue. I tried the version from branch issue639 but it did not solve the problem. So for the ones that still have not found how to solve this, this might be one of the possible cause to investigate. |
I have the same issue with Airflow configured with CeleryExecutor and Flower. We run everything using the stable Airflow Helm chart, and in the pod that runs Flower I can confirm that I can access my Redis broker using OpenSSL
I provide the remote certificate as a PEM in That said, the Flower server itself does not seems to work. It hangs after some initial logs. It is not reachable through port 5555 (even if the socket is listening). I've published a couple of PRs for puckel's Docker image of Airflow in order to be able to use manual configuration for Airflow using Docker: puckel/docker-airflow#495 And I use the following configuration for every Airflow component including Flower:
While it works for Airflow itself (i.e. the scheduler), it does not work for Flower. In my opinion the issue is that Flower does not decrypt the TLS connection the same way as the other Airflow components. As stated in the Celery documentation: https://docs.celeryproject.org/en/stable/userguide/configuration.html#id22
But the issue here is that Airflow does not seem to handle that kind of configuration very well. So at the moment, the way the Airflow Helm chart is done, it's either Airflow working, or Flower working, but not both... TL;DR
Edit: See
Thus, Airflow and Flower cannot share the same configuration. And there is no easy way to provide an alternate configuration to Flower that I can see. Here is a ticket I've just opened in the Airflow JIRA: https://issues.apache.org/jira/browse/AIRFLOW-6985 |
Please try the latest master version. I've pushed a fix for this issue. |
@mher I clone down latest master, but no use |
Im trying to run flower on my local celery deployment. When I try to connect via web browser to localhost:5555 or via curl , it just hangs forever (waiting for localhost). I can telnet to port 5555, but other than that no response. Below is some debug info:
celery -A myproject flower --broker=redis://localhost:6379/0 --broker_api=redis://localhost:6379/0 --debug --inspect_timeout=10
[I 161120 20:08:01 command:136] Visit me at http://localhost:5555
[I 161120 20:08:01 command:141] Broker: redis://localhost:6379/0
[I 161120 20:08:01 command:144] Registered tasks:
[u'app.tasks.generate_scheduled',
u'celery.accumulate',
u'celery.backend_cleanup',
u'celery.chain',
u'celery.chord',
u'celery.chord_unlock',
u'celery.chunks',
u'celery.group',
u'celery.map',
u'celery.starmap',
u'app.tasks.generate_result',
'normalize_time_task',
u'myplatform.celery.debug_task',
u'tasks.bake_block',
'tasks.baker',
'tasks.mailman']
[D 161120 20:08:01 command:146] Settings: {'cookie_secret': 'pnKuJkmuRPW43p1N4KYmvRAZjwFJtE+dvDWUNGrHTl8=',
'debug': True,
'login_url': '/login',
'static_path': '/usr/local/lib/python2.7/site-packages/flower-0.9.1-py2.7.egg/flower/static',
'static_url_prefix': '/static/',
'template_path': '/usr/local/lib/python2.7/site-packages/flower-0.9.1-py2.7.egg/flower/templates'}
[D 161120 20:08:01 control:29] Updating all worker's cache...
[I 161120 20:08:01 mixins:224] Connected to redis://localhost:6379/0
The text was updated successfully, but these errors were encountered: