slavenode.go:215: [test_helper] read unix ->: EOF #617
Comments
|
Went ahead and blasted my gemset and reinstalled all gems and seems to work now. Must've been a temporary fail. |
|
Might be a dependency interaction, I had the same some time ago with an earlier version. |
|
I'm still experiencing this issue, on both ruby-2.3.3 and 2.4.0. |
|
Ugh thats not good have you tried removing and reinstalling the zeus gem? |
|
Hmm, I could have sworn I tried that but indeed |
|
Sorry for that I would really like to know what is going on but can't think of a way to debug... Thanks for your quick feedback. |
|
I'm also seeing this, some time after upgraded to and remove / reinstall gem does not help, so I'm kinda stuck here. Oddly enough, zeus still works for another project, so there seems to be project-specific persistent state somewhere. |
|
Oops sorry, it occurred when there's an error in an initializer where ERB evaluation fails due to a stupid syntax error in a yml file. Sorry for confusion. |
|
Yeah I think it's one of the cases for #555 to be honest, it should be clearer in what is actually going wrong... |
|
@kenn how did you identify what file was the problem? I'm getting this same error message but don't know what's wrong |
|
@blimmer have you tried to run the command without zeus? |
|
@blimmer run without zeus, and confirm the issue is not related to zeus. Problems vary, but that's a start 😉 |
|
I can run When I run |
|
Does anyone know how to get more information about this error? cc @sideshowcoder I've finally figured out how to clone this, build the app, but it seems like Go only exposes the I was hoping that a It really seems like there has to be a way to get even just a little more information about this issue, but I don't really know any golang 😞 also, this is the log I get if I ask zeus to give me more info: |
|
@blimmer yeah I've been looking into this as well, one option would maybe be to try using a debugger, maybe https://github.com/derekparker/delve/ would do the trick. Sadly / luckily I don't have a project which experiences this, but I would really hope to be able to improve the error messages as well. |
|
My current process for testing this out to is clone the repo, run The other crazy part about all of this is that the issue only exhibits itself (on the exact same codebase / macOS latest / etc) for some people on my team, not everyone. |
|
Oh that sounds like its gonna be fun to debug... But yes delve should be able to help there see https://github.com/derekparker/delve/blob/master/Documentation/usage/dlv_attach.md for attaching to a running process |
|
@blimmer I was having problems with this too but got it working . Gem uninstalls and reinstalls ended up making it work. It does not work when running Something to note is that when I run
|
|
@seyonv those messages look fine to me actually they are the trace log right? |
|
Yeah they're fine, shouldn't have mentioned them. Broader point is bundler causing failure and uninstalling, reinstalling different gems helped. As mentioned elsewhere, I believe the wrong versions of method_source and json were causing problems. |
|
Cool sorry for the confusion 👍 yes this seems to help and I've seen it before as well, I got no idea why so 🐼 |
|
I "fixed" this on my machine by running |
|
In my case it was caused by these two lines in spec_helper require 'database_cleaner' I am using ruby 2.4 with Rails 5.0.1 |
|
@tanmayforgit how did you resolve it? |
|
Had a similar error today while running zeus start. Updating zeus from 0.15.10 to 0.15.13 fixes it. Not sure if it was the upgrade or simply a reinstall that fixed it. Could've been a conflict with a gem or Go library added to my system recently. Environment
|
|
In my case, updating bundler from 1.13.7 to 1.14.6 helps. |
|
yeah, this is really annoying. Would be nice if zeus could have this fixed internally so everybody doesn't have to pristine the gems. Didn't work for me though. Still having trouble |
|
Hey, guys — I have spent a few days setting up Zeus in our dev environment, and I ended up learning a lot about what to expect when various weird things happen. The good news is that I think I've been able to resolve majority of our initial issues with Zeus, so let me walk through some use cases and what I've found, perhaps it will be helpful to somebody.
My setup:
Since Zeus is not supposed to be in your CrashesWe also experienced a bunch of SEGV crashes, that I was able to trace to the following gems. Each was exploding in a different place.
With these cleaned up, Zeus appears very stable. Hope this helps! |
|
@kigster awesome detective work! of all your SEGV xp's, I have |
|
@kigster What was your workflow to trace SEGV crashes? With |
|
I experienced the same problem on Fedora 26 today. Though it was working on my Ubuntu. I just removed the Gemfile.lock file and used |
|
I'm now getting failures on We're now on Ruby 2.4.2 for over a month (still on rbenv) and Bundler version 1.15.4. |
|
Possibly related change: I'm on OS X Sierra and yesterday I had updated Xcode and command line tools to Version 9.0.1 and 9.0 respectively... |
|
My workflow with SEGV is rather simple: Look at the 5-7K lines of a stacktrace (make sure to set iterm2 screen history to unlimited), and find the first 100 or so lines. It the top of this stack will invariably be one of the gems I listed. If I see a new stack with no listed gems, I’d try to see the last few stacks: typically it’s a gem doing something via a native extension C callback. However, segv is a good problem to have: you know when you have one. But I’ve also seen Zeus not start and almost nothing in any logs. In that case I would try to run by hand a non-Zeus command, for example “rails console” instead of “Zeus console”: most of the time it explodes somewhere until fixed. When ruby VM that Zeus boots up throws parsing errors, there will be very little info why Zeus fails to start. So just manually start a new vm and hopefully you will see some errors. HTH |
|
Also getting the same exact problem as @dmcinnes. Had to reformat the other day. None of these solutions seem to apply to me in getting zeus to work. On High Sierra with ruby 2.1.1 |
|
I was getting AnwarShahs solution worked for me.
|
|
You can set |
|
I found one additional issue that was happening to me. In my environment I use {
"command": "rbenv exec ruby -rubygems -r./lib/zeus/custom_plan.rb -eZeus.go",
}Notice the |
|
@alsutton Thanks! This worked in my case on zeus v0.15.14: |
|
How to debug when we have an error ? This is really annoying...
Run what ? This project seems to be die. |
|
Running into this same issue and it doesn't look like any of the solutions above have fixed things for me. Is anyone else still seeing this? |
|
I'm running into this problem too now. I use Ruby 2.4.1 on a Rails 4.2.8 project. It was working fine yesterday, now everything has broken today. |
|
Had the same problem:
Just to reiterate what others have said, logging the output is key to figuring out the problem: zeus --log ./zeus.log startIn my case, I was getting:
and setting |
|
I'm on zeus 0.15.13.pre and started getting this error |
|
Are using using rbenv? Try changing ruby to `rbenv exec` in the Zeus.json.
Are you sarting Zeus with —log option? If not you should.
Have you tried running `bundle exec rspec` without Zeus? Does it work?
Try upgrading `pry-byebug` gem if you are using it. Make sure to remove the spring gem.
Hope this helps. If not, please describe your environment (ruby version, if you are
using rbenv, rvm or another ruby), to help others help you. Best of luck.
|
|
Thanks! I got it working again, using this combination in the same terminal: |
|
I've just been tracking this down for a couple of hours (on High Sierra / zeus 0.15.14). I'm not sure whether there should be a new issue opened or what, exactly. The first thing I found was that pry is getting required without respect for the Gemfile.lock. This surfaced first as a version conflict with So, I think the main issue is that The secondary issue is that there seem to be lots of ways to get that basically silent failure, even with logging on. I guess that's probably over on the Go client side. I'm having a hard time getting my environment set up to build that (some constant uint64 overflow in a vendored dependency). I'm going to have a look and see if option 2 above sorts this out. |
|
I'd like to see #654 merged to resolve the issue that caused this for me, but until then, this is how I've worked around it. I changed my diff --git i/config/zeus.rb w/config/zeus.rb
index 0702e339a..7714c1557 100644
--- i/config/zeus.rb
+++ w/config/zeus.rb
@@ -1,3 +1,10 @@
+zeus = Gem::Specification.find_by_name('zeus')
+
+require 'bundler/setup'
+
+$LOAD_PATH.concat Dir[zeus.lib_dirs_glob]
require 'zeus/rails'
# see https://github.com/burke/zeus/blob/master/docs/ruby/modifying.mdThis more or less forces Zeus to load the version of pry (and therefore byebug, as in my case) that is locked by your Gemfile. If you don't have pry in your Gemfile, then this will cause zeus not to load its Pry patches at all, but if that's the case you probably aren't experiencing this Zeus failure for the same reason as myself and @botimer |
|
I started getting this again but this time it was @alsutton's I googled that environment variable and found puma/puma#1421 pretty quickly which also discusses the underlying issue (which is related to changes in the way the if /darwin/ =~ RUBY_PLATFORM
require 'fiddle'
# Dynamically load Foundation.framework, ~implicitly~ initialising
# the Objective-C runtime before any forking happens
Fiddle.dlopen '/System/Library/Frameworks/Foundation.framework/Foundation'
end |
|
Leaving this here as a solution to those who recently upgraded to Rails 5.2 (which added Bootsnap) From: #641 (comment) in require "bundler/setup" if File.exist?(ENV["BUNDLE_GEMFILE"])
-require 'bootsnap/setup'
+require 'bootsnap/setup' unless ENV["ZEUS_MASTER_FD"]This fixed it for me, when none of the other suggestions worked :) |
|
@smlparry amazing! all the other ways failed, we also just upgraded to Rails 5 and I couldn't find any indication that this is the issue. How did you find that this is the problem? |
|
We ran into something a week or so ago with bootsnap -- not zeus-specific, but may share some roots. We found that bootsnap -> sassc -> libsass was terminating with an illegal operation while loading the bundle for any We were doing deployment of a vendored bundle across two machines with the same kernel, ruby, libffi, but the extension was somehow incompatible across them. We worked around it rather than solving, but I had some suspicion that ffi's extconf.rb was sniffing something about libffi / cpu flags incorrectly... Maybe a red herring, but seems potentially related. |
and others
zeus startproduces this error after upgrading to 0.15.12.The text was updated successfully, but these errors were encountered: