Skip to content
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

Flower is not starting #398

Open
kgorshkoff opened this issue Jul 15, 2021 · 9 comments
Open

Flower is not starting #398

kgorshkoff opened this issue Jul 15, 2021 · 9 comments

Comments

@kgorshkoff
Copy link

kgorshkoff commented Jul 15, 2021

Good day.

Couple days ago Flower stopped working and giving me next error, when trying to start the container.

ERROR: for flower Cannot start service flower: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "--broker=amqp://guest@queue:5672//": stat --broker=amqp://guest@queue:5672//: no such file or directory: unknown

I cross-checked all configs and they seem to be identical to ones in template itself.

All the other containers start and work just fine

EDIT: not working on macOS 11.4 with Docker Engine v20.10.7 as well as Ubuntu 20.04.2 LTS

@AntonOfTheWoods
Copy link

AntonOfTheWoods commented Jul 16, 2021

I can confirm the same problem on Ubuntu 20.04 in both WSL2 and a normal VM. WSL2 doesn't appear to work at all, whereas in the normal VM just the flower service appears to not be working

@AntonOfTheWoods
Copy link

@kgorshkoff The problem is that mher/flower in the docker compose file points to latest, and latest is no longer compatible with the docker compose file. If you override the image and point to mher/flower:0.9.7 then everything works fine.

I'll submit a PR to at least get things installing again

@kgorshkoff
Copy link
Author

kgorshkoff commented Jul 16, 2021 via email

br3ndonland added a commit to whythawk/full-stack-fastapi-postgresql that referenced this issue Jul 19, 2021
fastapi#398
fastapi#399

Error:

```text
ERROR: for flower  Cannot start service flower: OCI runtime create
failed: container_linux.go:380: starting container process caused:
exec: "celery --broker=amqp://guest@queue:5672//":
stat celery --broker=amqp://guest@queue:5672//:
no such file or directory: unknown
```
@asker-github
Copy link

mher/flower:0.9.7

thank you!

@dmitrybabanovforreal
Copy link

@tiangolo I think this bug needs to be addressed in the code. I used this stack template a few times in the last few weeks and every time I get this error in the beginning and then search for this issue in the browser history to get the backend working

@AntonOfTheWoods
Copy link

@dmitrybabanovforreal , I'm pretty sure this repo has reached the end of updates from @tiangolo . There are now lots and lots of PRs for the many bugs, and the maintainer has shown no signs of life on the repo for months. Looks fairly abandoned to me...

@kielerrr
Copy link

@kgorshkoff The problem is that mher/flower in the docker compose file points to latest, and latest is no longer compatible with the docker compose file. If you override the image and point to mher/flower:0.9.7 then everything works fine.

I'll submit a PR to at least get things installing again

I wish I saw this 12 hours ago. This fixed it for me.

@AntonOfTheWoods
Copy link

@kielerrr , this is unfortunately one of the disadvantages of open source software that you don't pay for. Popular repositories get abandoned by well-known FOSS developers with absolutely zero indication the repo/project has been abandoned/no longer works, etc. People have the expectation that such community figures won't just casually abandon very widely used software. Many simply don't care that hundreds or even thousands of people waste many hours, which a simple update at the top of the readme would avoid. @tiangolo has abandoned this repo, and obviously won't let anyone else maintain it, meaning some issues (like the flower issue) already have several PRs fixing it.

It seems ridiculous that people who donate hundreds/thousands of hours of amazing work to the community would cause such easily avoidable frustration but this happens to LOTS of popular repos. The other option is that we write everything ourselves from scratch...

@kielerrr
Copy link

It seems ridiculous that people who donate hundreds/thousands of hours of amazing work to the community would cause such easily avoidable frustration but this happens to LOTS of popular repos. The other option is that we write everything ourselves from scratch...

This stack has saved me so much time in other ways I can forgive a little time wasted on a fixable issue in the repo. Maybe its time to fork or see if tiangolo wants to turn over PR control to someone with more time.
It does feel tragic knowing an unpatched repo is being cloned hundreds of times with a bug that is going to cost thousands of hours of time, all while the fix is sitting in a PR queue. I guess it's a lesson to check the issues tab before diving into a day long debug adventure. I should have done it the other way around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants