Foreman Proxy won't start due to ruby load error (Concurrent::Edge::Future)

Is there another workaround? I’m new to foreman and hit this issue as well installing remote execution on the same smart proxy everything else is on on foreman host. Would it function if I deployed a new smart proxy on another OS for ansible / remote execution? Older debian package on that other host? Foreman was deployed to Ubuntu 18.04 fwiw. Just trying to see what my options are, if any, as I’m pretty new to foreman ecosystem.

As far as I know deployments on EL-derivatives don’t suffer from this issue. Using older debian packages should work in theory, if you can find them somewhere.

Is there any work-a-round for installing foreman-proxy? Just ran into this issue while trying to install foreman 1.20. Now I can’t revert back to 1.19 due to this error.

Any updates to this or any way to install foreman-proxy 1.20 on Ubuntu 16.04? Thanks

Happy New Year. I still have this problem, is there any work-a-round?

I found this issue which has a work-a-round! Its now working for me.
https://projects.theforeman.org/issues/25716

Hey @Conzar, this appears to be unrelated to the error message seen here. Can you confirm what your situation was?

The foreman proxy failed to start. Installation is managed by the foreman puppet modules not the foreman installer script. Ensuring the package ‘ruby-logging’ installed fixed the problem with foreman proxy from not being able to start. Hope that answers your question.

Okay it’s just that while the symptom is the same, e.g. the proxy isn’t starting, the error is different.

Here it’s…
smart-proxy[977]: /usr/lib/ruby/vendor_ruby/dynflow/director.rb:16:in \`block in <class:Director>': uninitialized constant Concurrent::Edge::Future (NameError)

While in solution you linked to, it’s…
smart-proxy[7075]: /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- logging (LoadError)

So while the workaround worked for you, it’s not related to fixing this issue. I think. :stuck_out_tongue:

We seem to have overlapping discussion with Service[foreman-proxy]: Systemd restart for foreman-proxy failed!.

Is there any news on this issue? Today I upgraded our foreman instance to 1.20.2, hoping we could finally start using the tasks, but sadly I still get the same Concurrent::Edge::Future on Debian 9.8.

A work-around would also be fine. The only solution I found was removing the foreman-task package.

i confirm having the same issue with Ubuntu 18.04.
Foreman version 1.21.2

/usr/lib/ruby/vendor_ruby/dynflow/director.rb:16:in `block in
class:Director’: uninitialized constant Concurrent::Edge::Future
(NameError)`

Hi!
Is there any progress on this issue?

I’ve read on the ruby-concurrency github page “Features developed in concurrent-ruby-edge are expected to move to concurrent-ruby when final.”

So, I assumed that in recent Debian 9 / Ubuntu 18.04 LTS packages, where concurrent-ruby-edge are not available any more, that it could have been declared final by the devs.
I’ve successfully started foreman-proxy, by replacing every occurance of “Concurrent::Edge::Future” by
“Concurrent::Future”.
In Detail:
/usr/lib/ruby/vendor_ruby/dynflow/director.rb +16
/usr/lib/ruby/vendor_ruby/dynflow/world.rb +135
/usr/lib/ruby/vendor_ruby/dynflow/dispatcher/client_dispatcher.rb +7

I’m not a ruby programmer, and also don’t know how to get this fixed upstream.

Getting the same error after upgrading. Unfortunately replacing these instances only allowed me to start the foreman-proxy service, now when the proxy is getting queried I am getting a new error. Will there be a fix soon? It seems like the latest version is completely broken for Debian/Ubuntu.

2019-05-09T14:15:07 [D] accept: 10.240.3.65:35976
2019-05-09T14:15:07 [D] Rack::Handler::WEBrick is invoked.
W, [2019-05-09T14:15:07.186187 #9502] WARN – : Could not open DB for dynflow at ‘’, will keep data in memory. Restart will drop all dynflow data.
2019-05-09T14:15:07 [W] Error details
NoMethodError: undefined method future' for Concurrent:Module /usr/lib/ruby/vendor_ruby/dynflow/world.rb:365:inspawn_and_wait’
/usr/lib/ruby/vendor_ruby/dynflow/world.rb:24:in initialize' /usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/core.rb:18:innew’
/usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/core.rb:18:in create_world' /usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/core.rb:6:ininitialize’
/usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/core.rb:74:in new' /usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/core.rb:74:inensure_initialized’
/usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/core.rb:101:in block in web_console' /usr/lib/ruby/vendor_ruby/dynflow/web.rb:10:ininstance_exec’
/usr/lib/ruby/vendor_ruby/dynflow/web.rb:10:in block in setup' /usr/lib/ruby/vendor_ruby/sinatra/base.rb:2024:inclass_eval’
/usr/lib/ruby/vendor_ruby/sinatra/base.rb:2024:in new' /usr/lib/ruby/vendor_ruby/dynflow/web.rb:10:insetup’
/usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/core.rb:89:in web_console' /usr/lib/ruby/vendor_ruby/smart_proxy_dynflow_core/launcher.rb:40:inblock in route_mapping’
/usr/lib/ruby/vendor_ruby/rack/builder.rb:55:in instance_eval' /usr/lib/ruby/vendor_ruby/rack/builder.rb:55:ininitialize’
/usr/lib/ruby/vendor_ruby/rack/builder.rb:160:in new' /usr/lib/ruby/vendor_ruby/rack/builder.rb:160:inblock in generate_map’
/usr/lib/ruby/vendor_ruby/rack/builder.rb:160:in each' /usr/lib/ruby/vendor_ruby/rack/builder.rb:160:ingenerate_map’
/usr/lib/ruby/vendor_ruby/rack/builder.rb:145:in to_app' /usr/lib/ruby/vendor_ruby/rack/builder.rb:160:inblock in generate_map’
/usr/lib/ruby/vendor_ruby/rack/builder.rb:160:in each' /usr/lib/ruby/vendor_ruby/rack/builder.rb:160:ingenerate_map’
/usr/lib/ruby/vendor_ruby/rack/builder.rb:145:in to_app' /usr/lib/ruby/vendor_ruby/rack/builder.rb:153:incall’
/usr/lib/ruby/vendor_ruby/rack/handler/webrick.rb:88:in service' /usr/lib/ruby/2.5.0/webrick/httpserver.rb:140:inservice’
/usr/lib/ruby/2.5.0/webrick/httpserver.rb:96:in run' /usr/lib/ruby/2.5.0/webrick/server.rb:307:inblock in start_thread’
/usr/lib/ruby/vendor_ruby/logging/diagnostic_context.rb:474:in block in create_with_logging_context' 2019-05-09T14:15:07 [E] undefined methodfuture’ for Concurrent:Module (NoMethodError)
2019-05-09T14:15:07 [D] close: 10.240.3.65:35976

Hi,
I manage to avoid the problem (not to solve it) doing this steps:

  • Changing “Concurrent::Edge::Future” by “Concurrent::Future” as sseitz said in those files
  • Disabling dynflow, edit /etc/foreman-proxy/settings.d/dynflow.yml and change :enabled: to false
  • Restart foreman-proxy service
  • run foreman-installer --no-enable-foreman-proxy-plugin-dynflow

I think that all this concurrent::future stuff is directly related to dynflow console, and disabling it avoids the problem, but, take into consideration that this may also disables other features.

Hope that this helps

I was able to fix this issue on Debian 9.9 by pinning ruby-concurrent to version 1.0.0-3. We have Debian backports enabled by default, and the version of ruby-concurrent that was installed from backports caused the trouble for us.

1 Like

Still stuck in the water here. It seems this issue has been around a while and not making much progress. Given this affects current distributions of Ubuntu and there is no workaround, I feel it should be prioritized to some extent.

I realize it only affects a couple modules, but at least in my mind they are fairly big/popular modules.

As others have noted, you’ll likely hit issues with foreman upgrades (I’ve had several issues come up indirectly related to the broken installation of dynflow) and requires you to manually go in and make changes to get upgrade to succeed, and then you still have disable once your upgraded just to get foreman-proxy to be usable.

https://github.com/ruby-concurrency/concurrent-ruby/pull/812 is the current effort, there’s not really more we could do on our end.

The same problem occurred after I tried to update to 1.22.1
(We are still running Ubuntu 16.04.6)
The workaround marioabajo described above did not work for us.
The last post is from Jun so is there any progress on fixing this issue?

I updated the system to 18.04 to see if it would fix the problem.
Surprise, surprise, it did not!
The renaming workaround described above does not work for me.
Is there any other workaround? Maybe to remove distro packages and install
the gems directly? Is it better to use RedHat instead?
This bug or whatever it is lasts for months now this is really annoying!

We get your frustration and we don’t like it either, but we are still blocked by external dependency and until things get fixed there, it is not going to work on Debian and we can’t do anything about it.

RedHat based distros should be fine in this regard, so if you can, that would be the best way out of this mess.