slavenode.go:215: [test_helper] read unix ->: EOF

[typeoneerror]

zeus start produces this error after upgrading to 0.15.12.

slavenode.go:215: [test_helper] read unix ->: EOF

[daliborfilus]

@alsutton Thanks! This worked in my case on zeus v0.15.14:

Available Commands: [waiting] [crashed] [ready]
zeus console (alias: c) [run to see backtrace]
zeus server (alias: s) [run to see backtrace]
zeus generate (alias: g) [run to see backtrace]
zeus destroy (alias: d) [run to see backtrace]
zeus dbconsole [run to see backtrace]
zeus rake [run to see backtrace]
zeus runner (alias: r) [run to see backtrace]
zeus test (alias: rspec, testrb) [run to see backtrace]
slavenode.go:226: [default_bundle] read unix ->: EOF
noice ~/code/crystalmails.com/crystalmails (master)

$ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

$ zeus --log=./zeus.log start
Starting Zeus server v0.15.14
....
Available Commands: [waiting] [crashed] [ready]
zeus dbconsole
zeus rake
zeus runner (alias: r)
zeus console (alias: c)
zeus server (alias: s)
zeus generate (alias: g)
zeus destroy (alias: d)
zeus test (alias: rspec, testrb)

[anthony-bernardo]

How to debug when we have an error ? This is really annoying...

run to see backtrace

Run what ?

This project seems to be die.

[stevenleeg]

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?

[ecbrodie]

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.

[dyoung522]

Had the same problem:

slavenode.go:226: [bundler] read unix ->: EOF

Just to reiterate what others have said, logging the output is key to figuring out the problem:

zeus --log ./zeus.log start

In my case, I was getting:

2018/01/31 10:41:52.794658 [/Users/phil/Source/go/src/github.com/burke/zeus/go/processtree/slavenode.go:402] boot/(44312) root process exited with an error before it could boot: exit status 1; output was: /usr/local/var/rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/gems/bundler-1.16.1/lib/bundler/runtime.rb:313:in check_for_activated_spec!': You have already activated byebug 9.1.0, but your Gemfile requires byebug 10.0.0. Prependingbundle exec` to your command may solve this. (Gem::LoadError)

and setting "byebug", "~> 9.1" in my Gemfile resolved the issue.

[cheshire137]

I'm on zeus 0.15.13.pre and started getting this error slavenode.go:215: [test_helper] read unix ->: EOF. I tried running bin/bundle and rerunning bin/zeus start but that didn't work. I also tried export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES before running bin/zeus start (I'm in macOS) but it also didn't work. The log file doesn't give details about what happened to test_helper, just that it crashed: it went from entering state SBooting to entering state SCrashed.

[kigster]

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.

[cheshire137]

Thanks! I got it working again, using this combination in the same terminal: script/bootstrap + bin/rake db:migrate db:test:prepare + bin/zeus start.

[botimer]

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 method_source because the newer pry I had installed generally (0.11) was pulling in a new version of method_source (0.9). It took some doing to find out where that previously activated version of method_source was coming from.

So, I think the main issue is that pry is getting loaded but not in the cautious way that method_source is. Two ideas are to 1) do something like the check for method_source, or 2) patch pry after the default bundle is loaded, and only if Pry is defined.

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.

[bjeanes]

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 config/zeus.rb to load the Gem::Specification for zeus, then manually setting up bundler load paths, then requiring zeus by adding its load path manually:

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.md

This 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

[bjeanes]

I started getting this again but this time it was @alsutton's OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES fix that made it work again.

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 fork syscall works in macOS). I tweaked their fix (which is puma specific) to make an equivalent one for Zeus. Add this to the top of your config/zeus.rb:

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

[smlparry]

Leaving this here as a solution to those who recently upgraded to Rails 5.2 (which added Bootsnap)

From: https://github.com/burke/zeus/issues/641#issuecomment-408753975

in boot.rb:

 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 :)

[adfineberg]

@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?

[botimer]

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 bundle exec commands.

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.