foreman only shows line with “started with pid #” and nothing else - ruby-on-rails

When I run foreman I get the following:
> foreman start
16:47:56 web.1 | started with pid 27122
Only if I stop it (via ctrl-c) it shows me what is missing:
^CSIGINT received
16:49:26 system | sending SIGTERM to all processes
16:49:26 web.1 | => Booting Thin
16:49:26 web.1 | => Rails 3.0.0 application starting in development on http://0.0.0.0:5000
16:49:26 web.1 | => Call with -d to detach
16:49:26 web.1 | => Ctrl-C to shutdown server
16:49:26 web.1 | >> Thin web server (v1.3.1 codename Triple Espresso)
16:49:26 web.1 | >> Maximum connections set to 1024
16:49:26 web.1 | >> Listening on 0.0.0.0:5000, CTRL+C to stop
16:49:26 web.1 | >> Stopping ...
16:49:26 web.1 | Exiting
16:49:26 web.1 | >> Stopping ...
How do I fix it?

I’ve been able to resolve this issue by 2 different ways:
From https://github.com/ddollar/foreman/wiki/Missing-Output:
If you are not seeing any output from your program, there is a likely
chance that it is buffering stdout. Ruby buffers stdout by default. To
disable this behavior, add this code as early as possible in your
program:
# ruby
$stdout.sync = true
By installing foreman via the heroku toolbelt package
But I still don’t know what’s happening nor why this 2 ways above resolved the issue…

My solution was to put $stdout.sync = true at the top of config/environments/development.rb.
Then everything that loads the development environment (incluing thin) will not buffer stdout.

"Foreman will display to the terminal output anything written to stdout by the processes it launches." - ddollar See foreman-issues#57
BTW, you can use tailf into Procfile to see logs
web: bundle exec rails server thin -p $PORT
log: tail -f log/development.log
Tip: tailf doesn't exist in OSX, using tail -f -n 40 log/development.log works.

I also had the same problem but with a different solution. (ruby 1.9.2p290, rails 3.1.0, ubuntu 10.04.3)
I changed the line in my Procfile from:
web: bundle exec thin start -p $PORT
to:
web: bundle exec rails server thin -p $PORT
and it no longer gave me an issue.

I have the same problem (ruby 1.9.3-p0, rails 3.2rc2, OSX 10.7).
Resolved the issue by using foreman-0.27.0 by adding this line into my Gemfile.
gem 'foreman', '0.27.0'

If you are using Foreman to run a Python project, rather than a Ryby project, and you're having the same issue, here are some solutions for you. If you are using a Procfile to invoke the python CLI directly, then you can use the '-u' option to avoid stdout buffering:
python -u script.py
If you are using a Procfile to manage a WSGI server, such as invoking gunicorn, flask, bottle, eve, etc., then you can add a ".env" file to the root of your python project, containing the following:
PYTHONUNBUFFERED=True

Related

Puma Rails server won't start in daemon mode on MacOS 13 Ventura after update from MacOS 12

I just updated from MacOS 12.x to 13.0.1
Starting a Rails app with
➜ rails s
works fine
=> Booting Puma
=> Rails 5.2.8.1 application starting in development
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.12.6 (ruby 2.6.6-p146), codename: Llamas in Pajamas
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
But when I try with
➜ rails s -d
Output stops at
=> Booting Puma
=> Rails 5.2.8.1 application starting in development
=> Run `rails server -h` for more startup options
And no server is started
➜ ps -ef | grep puma
501 69877 51917 0 6:45 ttys000 0:00.00 grep puma
➜ ps -ef | grep rails
501 72493 51917 0 6:49 ttys000 0:00.00 grep rails
Well, I found a workaround. This is by no means perfect but if it helps anyone with the same problem:
nohup rails s </dev/null >/dev/null 2>&1 &
The & at the end will make it run in the background. All output/input goes to/from /dev/null and nohup makes sure it will run even after you quit the session.
The reason has nothing to do with the fact that you updated to MacOS Ventura.
Puma daemonization has been removed without replacement since version 5.0.0, and it has been extracted to the puma-daemon gem, which currently works only with Puma version ~> 5.
Therefore now you have two ways to make it work: with puma-daemon, or put it in no hanghup background mode.
METHOD 1: USING PUMA DAEMON GEM
bundle add puma-daemon
Add these line to your application’s Gemfile:
gem 'puma-daemon', require: false
gem 'puma', '~> 5'
Add these lines to config/puma.rb:
require 'puma/daemon'
daemonize
and ensure you have set up at least one worker (workers 1)
Now you should be able to run puma webserver as a daemon with rails server (please notice that you must remove any -d or --daemonize from the command line)
PUT IT IN NO HANGHUP BACKGROUND MODE
Just run rails server --no-log-to-stdout & to put the server in background and stop the output, and enclose it in a nohup >/dev/null command to get rid of the nohup.log file:
nohup rails server --no-log-to-stdout >/dev/null &
This method works with any Puma version and doesn't require the gem.
Don't mess around with the two ways.

No logging/info with Rails and Heroku local

My Rails app is on Heroku and needs access to S3. As such, I have a .env file at the root of my directory with the AWS authentication bits. Simply running rails s will not use the env file, so I need to test my server with heroku local. However, this will not spit out any of the standard rails output. I did try heroku logs and heroku logs -t.
My procfile:
web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}
My env file:
RACK_ENV=development
PORT=3000
AWS_ACCESS_KEY_ID=MYSECRETACCESSKEYID
AWS_SECRET_ACCESS_KEY=mySECRETaccessKEY
S3_BUCKET=my-bucket
AWS_REGION=us-east-1
After running heroku local:
[OKAY] Loaded ENV .env File as KEY=VALUE Format
1:33:45 PM web.1 | Ignoring http_parser.rb-0.6.0 because its extensions are not built. Try: gem pristine http_parser.rb --version 0.6.0
1:33:46 PM web.1 | Puma starting in single mode...
1:33:46 PM web.1 | * Version 4.3.5 (ruby 2.6.3-p62), codename: Code Name
1:33:46 PM web.1 | * Min threads: 5, max threads: 5
1:33:46 PM web.1 | * Environment: development
1:33:48 PM web.1 | * Listening on tcp://0.0.0.0:3000
1:33:48 PM web.1 | Use Ctrl-C to stop
Expected results: whenever I make a request to the endpoint, I expect it to log the endpoint, the SQL commands, and the errors, like it usually does.
I think I figured it out. Since we are not calling rails s directly, (my procfile is calling bundle exec puma), I looked on StackOverflow for similar questions involving puma and found this.
I needed to open a second terminal and run tail -f logs/development.log.

Using Foreman with Sidekiq, Neo4j and Ruby on Rails

In a Rails project I'm currently using neo4j instead of ActiveRecord. I added the Sidekiq and Foreman to be able to start Sidekiq and Rails server at the same time. This is what I have in the Procfile:
worker: bundle exec sidekiq
web: rails server
When I enter "foreman start" I'm getting this error:
14:39:29 worker.1 | LockClient[8447] can't wait on resource RWLock[SCHEMA(0), hash=754245282] since => LockClient[8447] <-[:HELD_BY]- RWLock[SCHEMA(0), hash=754245282] <-[:WAITING_FOR]- LockClient[8448] <-[:HELD_BY]- RWLock[SCHEMA(0), hash=754245282]
14:39:29 worker.1 | /home/user/.rvm/gems/ruby-2.1.2/gems/neo4j-core-3.0.8/lib/neo4j-server/cypher_response.rb:163:in `raise_error'
14:39:29 worker.1 | /home/user/.rvm/gems/ruby-2.1.2/gems/neo4j-core-3.0.8/lib/neo4j-server/cypher_session.rb:210:in `_query_or_fail'
14:39:29 worker.1 | /home/user/.rvm/gems/ruby-2.1.2/gems/neo4j-core-3.0.8/lib/neo4j/label.rb:42:in `create_constraint'
... further stack trace
If I don't use Foreman and instead start Sidekiq and Rails in separate tabs, it works just fine. Anyone else had any similar issues?

ruby and rails server is already runing [duplicate]

This question already has answers here:
Server is already running in Rails
(20 answers)
Closed 8 years ago.
I want to start my server through this command but it show me warning server is all ready running. How can stop the server forcefully ?
jaskaran#jaskaran-Vostro-1550:~/rails_project$ rails s
=> Booting WEBrick
=> Rails 4.0.2 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
A server is already running. Check /home/jaskaran/rails_project/tmp/pids/server.pid.
Exiting
if it is already running then it not working why?
Run this command:
ps ax | grep rails
This will show you the processes running having to do with Rails. The first number shown is the process ID. Look for the process that is running the Rails server, grab it's process ID, and type:
kill -9 processID
This will kill the Rails server that's running.
Run this command :-
ps aux | grep ruby
OR
ps -ef | grep ruby
It will show all the processes of ruby and also the running rails server
Then kill that processid as:-
kill -9 procesid
You can also remove the file inside:
/home/jaskaran/rails_project/tmp/pids/
i.e
server.pid
and start server again.

Thin Foreman stopped working

I'm using Thin webserver with RoR on my iMac.
I start it with $ foreman start
It was working fine, but now I'm getting this in the console:
09:27:10 web.1 | => Booting Thin
09:27:10 web.1 | => Rails 3.1.3 application starting in development on http://0.0.0.0:5000
09:27:10 web.1 | => Call with -d to detach
09:27:10 web.1 | => Ctrl-C to shutdown server
09:27:10 web.1 | >> Thin web server (v1.3.1 codename Triple Espresso)
09:27:10 web.1 | >> Maximum connections set to 1024
09:27:10 web.1 | >> Listening on 0.0.0.0:5000, CTRL+C to stop
09:27:10 web.1 | Exiting
09:27:11 web.1 | process terminated
09:27:11 system | sending SIGTERM to all processes
And the $ prompt shows up - so the webserver isn't running.
Any ideas?
I just ran $ thin start
and got:
Using rack adapter
/Users/burtondav/.rvm/gems/ruby-1.9.2-p290/gems/bundler-1.0.22/lib/bundler/runtime.rb:31:in `block in setup': You have already activated rack 1.4.1, but your Gemfile requires rack 1.3.6. Using bundle exec may solve this. (Gem::LoadError)
What bundle exec command should I try?
Add the gem 'thin' in your application Gemfile and execute the bundle exec thin start to resolve the version conflict problem.

Resources