Open ArglosStudios opened 5 months ago
this happened both when running via the puma plugin or starting solid_queue via Procfile.
It still run jobs if I enqueue them. However the worker crashes often.
Workaround so far is to run inside docker
I think I have the same issue on my mac. A piece of the message is solid_queue | /Users/natannobrechaves/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/pg-1.5.4/lib/pg/connection.rb:690: [BUG] Segmentation fault at 0x000000011d5b0b0e
.
I'm running inside Procfile.dev.
using rosetta to run your terminal (iterm for me) also seems to do the trick!
nvm.. pulled trigger too early. fails with rosetta as well
@natannobre I'm also having the same issue. Seems like it has been solved earlier here: https://github.com/rails/solid_queue/issues/145#issuecomment-1954024164
Hey @ArglosStudios, is this still happening for you? Did https://github.com/rails/solid_queue/issues/145#issuecomment-1954024164 help at all?
I have this issue but with a MySQL backend (I don't have the option to swap it for another DB).
Hey @rjhancock, does this still happen for you? Are you running the last version?
Just tested with latest gems for everything and this is the error I get.
Thanks a lot for testing š This one seems to be similar or the same as https://github.com/brianmario/mysql2/issues/1163 š¤ It seems it affects Rails's parallel testing too: https://github.com/rails/rails/issues/41176
There's a suggested solution here: compile mysql2
with a MySQL 5.7 client. Do you think this could work for you?
Sadly no as deployed MySQL is 8.0 same with local MySQL via Homebrew.
That's ok! You can continue using MySQL 8.0, this is just for the mysql2
gem. You can compile it against a MySQL 5.7 client and continue using it to access a MySQL 8.0 server.
This is what @johnmaxwell proposed here:
gem uninstall mysql2
brew install mysql-client@5.7
gem install mysql2 -- --with-mysql-dir="/usr/local/opt/mysql-client@5.7/"
When I test my Solid Queue code, I just run it within Docker Compose. Not ideal but works. I'd rather not add another monkey patch to the instructions and code base for a bug in one of two libraries that would bring my development environment more out of line from the production environment.
That makes sense! I wonder why you get the error then š¤ In theory, this happens only in macOS, so I assumed you were running everything in your local machine.
Only happens on macOS. When running via Docker Compose, runs fine. The servers are all Ubuntu boxes running dockerized containers with Ruby 3.3.4 as the base image.
I try not to run the images inside Docker while working on the code as it greatly slows things down over all. I generally don't need to test the Job system as it's already well tested.
Most of the code I can run without working with queues so it doesn't impact too much. Just wish the bug could be found as looking through the solutions it looks like this has been a bug somewhere for the last several years.
I recently switched to Omakub and ubuntu for development due to a number of macos related issues after the ARM on mac transition for this exact reason.. Like you, I run on production using kamal and docker containers (on x86_64 hw) so being on ubuntu helps me more accurately replicate production. Would be nice to identify a root cause on mac though.
Hello, I am running a project with solid_queue.
When doing some development on my windows pc with WSL, solid_queue runs greatly! However, when running on my macbook, I get either get file descriptors or weird reading errors:
Bad file descriptors:
end of file reached error: