Opposes in one localhost port ,, any Solution [closed] - ruby

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
i'm using sinatra to work with ruby , when i am run the file in the terminal the normal port for sinatra is "4567" , but for three days ago the terminal print this
Sinatra/1.4.5 has taken the stage on 4567 for development with backup from WEBrick
[2014-09-06 00:15:16] INFO WEBrick::HTTPServer#start: pid=770 port=4567
also the webrick port is "4567"

It's difficult to understand the problem you're seeing. Maybe this will help:
If I create a simple test server containing the sample Sinatra code:
require 'sinatra'
get '/hi' do
"Hello World!"
end
And save that to my Desktop as test.rb, I can run Sinatra using:
ruby test.rb
Sinatra tells me:
== Sinatra/1.4.5 has taken the stage on 4567 for development with backup from Thin
Thin web server (v1.6.2 codename Doc Brown)
Maximum connections set to 1024
Listening on localhost:4567, CTRL+C to stop
If I uninstall Thin:
gem uninstall thin
Remove executables:
thin
in addition to the gem? [Yn] y
Removing thin
Successfully uninstalled thin-1.6.2
And run the code again:
ruby test.rb
[2014-09-05 14:41:23] INFO WEBrick 1.3.1
[2014-09-05 14:41:23] INFO ruby 2.1.2 (2014-05-08) [x86_64-darwin13.0]
== Sinatra/1.4.5 has taken the stage on 4567 for development with backup from WEBrick
[2014-09-05 14:41:23] INFO WEBrick::HTTPServer#start: pid=26786 port=4567
In either case, the code does what it's supposed to. I can connect using curl and get "Hello World!" back:
curl http://localhost:4567/hi
Hello World!
Sinatra uses Webrick by default, but will pick other servers over it:
gem install puma
Fetching: puma-2.9.1.gem (100%)
Building native extensions. This could take a while...
Successfully installed puma-2.9.1
Parsing documentation for puma-2.9.1
Installing ri documentation for puma-2.9.1
Done installing documentation for puma after 3 seconds
1 gem installed
ruby test.rb
Puma 2.9.1 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:4567
== Sinatra/1.4.5 has taken the stage on 4567 for development with backup from Puma
gem install thin
Fetching: thin-1.6.2.gem (100%)
Building native extensions. This could take a while...
Successfully installed thin-1.6.2
Parsing documentation for thin-1.6.2
Installing ri documentation for thin-1.6.2
Done installing documentation for thin after 0 seconds
1 gem installed
ruby test.rb
== Sinatra/1.4.5 has taken the stage on 4567 for development with backup from Thin
Thin web server (v1.6.2 codename Doc Brown)
Maximum connections set to 1024
Listening on localhost:4567, CTRL+C to stop
curl http://localhost:4567/hi
Hello World!
Use -s to control which server Sinatra uses:
ruby test.rb -s puma
Puma 2.9.1 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:4567
== Sinatra/1.4.5 has taken the stage on 4567 for development with backup from Puma

Sinatra Docs:
:run - enable/disable the built-in web server Boolean specifying
whether the built-in web server is started after the app is fully
loaded. By default, this setting is enabled only when the :app_file
matches $0, i.e. when running a Sinatra app file directly with ruby
myapp.rb. To disable the built-in web server:
set :run, false
:server - handler used for built-in web server. String
or Array of Rack server handler names. When the :run setting is
enabled, Sinatra will run through the list and start a server with the
first available handler. The :server setting is set as follows by
default:
set :server, %w[thin mongrel webrick]
Sinatra README:
Sinatra is a DSL for quickly creating web applications in Ruby with minimal effort:
# myapp.rb
require 'sinatra'
get '/' do
'Hello world!'
end
Install the gem:
gem install sinatra
And run with:
ruby myapp.rb
View at: http://localhost:4567
It is recommended to also run gem install thin, which Sinatra will pick up if available.
By default, Sinatra first looks to see if you have the Thin server software installed--if yes, Sinatra uses Thin to respond to requests on port 4567. If you do not have Thin installed, next Sinatra checks if you have the Mongrel server software installed, and Sinatra uses Mongrel if it is installed, and finally Sinatra uses the always available Webrick server software, which comes with ruby.
The message you are seeing is Sinatra telling you which server software it is using to respond to requests on port 4567.

Related

Ruby: Unable to start worker - check_for_activated_spec

I am unable to run some of my jobs in sidekiq. And it seems to be somehow related to Bundler.. Maybe.
when I run my puma server with pumactl start in the logs I am getting:
[156149] ! Unable to start worker
[156149] /home/todd/.rbenv/versions/2.7.0/lib/ruby/gems/2.7.0/gems/bundler-2.3.25/lib/bundler/runtime.rb:309:in `check_for_activated_spec!'
Currently I'm on sidekiq 6.5.6 and Bundler 2.3.25
Anyone know of any issues with those two versions or anything else that may be causing this?
EDIT:
The interesting thing is when I start puma with bundle exec pumactl start I get a totally different error:
[ActionDispatch::HostAuthorization::DefaultResponseApp] Blocked host:
But my host is defined in my development.rb file.. in fact I've added the following, so NO hosts should be blocked:
config.hosts << /.*\.ngrok\.io/
config.hosts.clear
Then finally if I just start puma with a rails s all is fine, just my sidekiq worker won't run correctly.
Let's say that you want to start using Rails and one day you follow the general installation instructions which say that you should run this command:
gem install rails
And you get this output:
...
Successfully installed rails-7.0.1
You also start working with puma and sidekiq and install those gems for the convenience of running pumactl start and sidekiq:
gem install puma
...
Successfully installed puma-5.6.2
gem install sidekiq
...
Successfully installed sidekiq-6.4.2
Then after a day or a week or a month of tinkering you create a new Rails app:
rails new app
And since you want to use Sidekiq you add that to your Gemfile, which looks something like this:
# frozen_string_literal: true
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem "puma", "~> 5.6.2"
gem "rails", "~> 7.0.1"
gem "sidekiq", "~> 6.0"
But you know that there are newer versions of those gems so you update your Gemfile to look like this:
# frozen_string_literal: true
source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem "puma", "~> 6.0.0"
gem "rails", "~> 7.0.4"
gem "sidekiq", "~> 7.0"
And then you run bundle install and the gems update. Or maybe you don't change the versions, but some day run bundle update which uses the ~> versioning operator and updates the gems to newer versions.
Here's where you're going to start running into compatibility problems.
First problem:
When you installed the sidekiq and puma and rails gems to run their scripts like pumactl they were installed using gem install ... which installed them globally and with a specific version.
When you added them to your Rails app and updated the versions they were installed separately by bundler with specific versions that are noted in Gemfile.lock.
Now your global version of puma is 5.6.2 and your bundled version of puma is 6.0.0.
Trying to manage puma using an old version of the CLI with a new version of the gem isn't guaranteed to work and can introduce hard-to-pinpoint problems. The same is true of the rails and sidekiq gems and any gem with a CLI.
Second problem:
When you run scripts like pumactl they aren't necessarily going to look at your application's Gemfile.lock and they aren't guaranteed to see or respect bundler's configuration for your Rails app when it loads it.
When you run scripts prefixed with bundle exec (like bundle exec sidekiq) it uses bundler to look at your bundled environment and ensure that all the dependencies are properly loaded.
Trying to run a bundled application without bundle exec can introduce hard-to-pinpoint problems. The same is true for any gems that have CLI tools.
Short answer
Always use bundle exec ... to run gem CLIs in your app, whether it's bundle exec rails server or bundle exec puma or bundle exec sidekiq. This will ensure that your app is started or managed using the bundled gem rather than the global version.
If you see errors when starting your app using bundle exec ... then pay attention to them because they are indicative of actual problems that need to be addressed. Likewise, if you do see errors with bundle exec but don't see errors when starting your app using globally installed gems then pay attention to them because it means your app is not portable -- it's likely that it is papering over bugs to make the app run and that your app will not run on another computer.
Extended answer
pumactl start gives you an error -- probably because you aren't using bundle exec.
bundle exec pumactl start gives you a different error -- possibly because you're bypassing the standard way to start Rails; pumactl will read configu.ru and config/puma.rb and decide how it wants to start Rails. Use bundle exec rails server instead.
rails s doesn't load your sidekiq worker -- because you aren't using bundle exec rails s it likely can't see the things it's supposed to see to start properly, because it isn't using your bundled app config
Because the errors that you're reporting are due to a misconfiguration of your system and app I can't give you any more detailed answers. You need to fix your configuration first and determine which of the three different errors you're experiencing is valid. It's a lot of work to try to work through all three questions. A standard "vote to close" reason for questions is:
Needs more focus
This question currently includes multiple questions in one. It should focus on one problem only.
I'm not voting to close your question but I'm mentioning it in case it does get closed later.
I recommend that after you fix the misconfiguration you create a new post about that specific error with a minimal reproducible example.

How can I run dashing with ruby web server puma?

Dashing uses thin ruby web server as default.
I'm trying to used puma as my ruby web server since I got issue with memory consumption with the default web server.
I have read in some github forums that the rufus-scheduler which is used to schedule jobs might be the cause of memory issue.
I set up gem 'puma' in mg GemFile & bundled it.
But every time I run my application, it uses thin web server again.
dashing start
Thin web server (v1.6.4 codename Gob Bluth)
Maximum connections set to 1024
Listening on 0.0.0.0:3030, CTRL+C to stop
Please help on how to properly use puma web server on dashing.
Run your server using puma:
puma config.ru
Or run your server with rackup and specify puma as the server:
bundle exec rackup -s puma -p 3030
Explanation:
When you run dashing start, you're using the dashing CLI tool. The reason you can't run dashing with puma using the dashing CLI tool is because the use of thin is hard-coded. See the dashing CLI code.

Ruby with Sinatra not loading when adding SendGrid or Mandrill

I'm building a basic Ruby app with Sinatra and SendGrid.
When I try and run the file ruby app.rb the site does not load. When I remove require 'sendgrid-ruby' the app loads. Code below.
app.rb
require "sendgrid-ruby"
require "sinatra"
set :app_file, __FILE__
get '/' do
puts "hi"
end
Gemfile
gem 'sinatra'
gem 'sendgrid-ruby'
Any help? I don't have a config.ru or anything else at this point. No error logging. It just hangs at waiting for LocalHost.
== Sinatra (v1.4.7) has taken the stage on 4567
for development with backup from Thin
Thin web server (v1.6.4 codename Gob Bluth)
Maximum connections set to 1024
Listening on localhost:4567, CTRL+C to stop
Ruby version: ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin15]
EDIT:
Previously, I had require "sinatra" first and I didn't have set :app_file, __FILE__ in there at all.

sinatra hello world app doesn't work

I'm having trouble learning how to use Sinatra.
Versions are
Mac OSX 10.11.2
Ruby 2.2.2
Sinatra 1.4.6
I wrote the same code as the first code in this site.
# main.rb
require 'sinatra'
get '/' do
'Hello world!'
end
Then I tried a command in the same derectory
% ruby main.rb
== Sinatra (v1.4.6) has taken the stage on 4567 for development with backup from Thin
Thin web server (v1.6.4 codename Gob Bluth)
Maximum connections set to 1024
Listening on localhost:4567, CTRL+C to stop
Then I accessed http://localhost:4567 with Google Chrome, but the browser didn't recieve any data (ERR_EMPTY_RESPONSE). Also nothing logged in Terminal.
I tried other port (like 3000) by -p option, but it didn't work.
What am I doing wrong?
I updated gem and reinstalled sinatra, then it worked.
gem update --system
gem uninstall sinatra
gem install sinatra

Running Sinatra app with Mongrel on Windows

I'd like to start a Sinatra app from Mongrel on Windows, rather than Sinatra starting Mongrel in the background.
Is there a simple way to use Mongrel for Sinatra? It's looking for a rails app by default.
Edit: Suggested solution is to simply run a VMWare or SunBox with real Linux and deal with the corporate issues that way.
Check out http://sinatra-book.gittr.com/.
FastCGI is the chapter you're looking for within the page, because that's what mongrel is
if you have a rake config, like config.ru
then install thin gem
then
thin -p 3000 -r config.ru
I think.
-r

Resources