No logging/info with Rails and Heroku local - ruby-on-rails

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.

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.

Running Standard Notes on self-hosted Standard File Server with Ruby Implementation

I'm trying to have Standard Notes to run on my self-hosted Ubuntu 16.04 server. I've followed the basic instructions given here on Github, which is to say, install Ruby 2.2+, Rails 5, MySQL 5.6+ database. All done, and running.
After that, in a subdirectory, I pulled the the Standard File Server git clone, set up the .env file with this content:
RAILS_ENV=production
SECRET_KEY_BASE=use "bundle exec rake secret"
RAILS_SERVE_STATIC_FILES=true
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db_name
DB_USERNAME=db_user
DB_PASSWORD="db_password"
SALT_PSEUDO_NONCE=use "bundle exec rake secret"
Initialized the project with:
bundle install
bower install
rails db:create db:migrate
Again, all fine. When I start the server with rails s, this is the output:
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.1/lib/active_support/xml_mini.rb:51: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.1/lib/active_support/xml_mini.rb:52: warning: constant ::Bignum is deprecated
=> Booting Puma
=> Rails 5.0.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.1/lib/active_support/core_ext/numeric/conversions.rb:138: warning: constant ::Fixnum is deprecated
Puma starting in single mode...
* Version 3.10.0 (ruby 2.4.1-p111), codename: Russell's Teapot
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
I think the two warnings can safely be ignored. The thing that doesn't make sense is that the .env file is not read as it's running in dev instead of prod, and on port 3000 instead of 3306. Any idea why?
typo at:
AILS_ENV=production
should be:
RAILS_ENV=production

Why is Puma unable to load Bundler when user who owns Puma process can?

For reasons beyond my control, I need to run a Rails 4 app on CentOS 7. Currently, it is running successfully on a Red Hat with rvm and Passenger. I'd like to migrate it over to rbenv and Puma but I am stuck with this issue.
I am trying to run a test installation on a VirtualBox virtual machine. I believe I've wired everything together correctly. I have disabled SELinux. When I run cap deploy, puma starts successfully:
04:03 puma:start
using conf file /var/www/rails-app/shared/puma.rb
01 bundle exec puma -C /var/www/rails-app/shared/puma.rb --daemon
01 * Pruning Bundler environment
01 [6464] Puma starting in cluster mode...
01 [6464] * Version 3.9.1 (ruby 2.1.10-p492), codename: Private Caller
01 [6464] * Min threads: 4, max threads: 16
01 [6464] * Environment: vm
01 [6464] * Process workers: 1
01 [6464] * Phased restart available
01 [6464] * Listening on unix:///var/www/rails-app/shared/tmp/sockets/puma.sock
01 [6464] * Daemonizing...
✔ 01 deploy#localhost 0.537s
But the Puma access log spins out this error in an infinite loop:
/home/deploy/.rbenv/versions/2.1.10/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- bundler/setup (LoadError)
... stack trace clipped ...
Listing the processes associated with my Puma user shows:
$ ps aux | grep deploy
deploy 12645 0.0 0.2 115384 2084 pts/0 S 18:18 0:00 -bash
deploy 18517 0.7 1.7 271344 18076 ? Sl 18:27 0:00 puma 3.9.1 (unix:///var/www/rails-app/shared/tmp/sockets/puma.sock)
deploy 23279 7.0 0.0 0 0 ? Z 18:29 0:00 [ruby] <defunct>
deploy 23283 4.0 1.7 273400 17464 ? Rl 18:29 0:00 puma: cluster worker 0: 18517
I have confirmed that I can successfully run Bundler as the deploy user that owns the Rails application and the Puma process:
cd /var/www/rails-app/current && bundler --version
Bundler version 1.15.4
So I am not sure why am I seeing this error. After hours of research and troubleshooting, I'm stuck. I can provide config files if needed but they're pretty standard and I think would only clutter up this question at this point.
Does this issue look familiar to anyone?
Few steps to solve this type of issue:
Make sure that bundler is properly installed. Looks like yes in your case, but still a good thing to start by running a gem install bundler
Make sure that all your path is properly configured. Here is an example that looks similar to your case, where bundler was installed but path wasn't correct and bundler versions were mixed: cannot load such file -- bundler/setup (LoadError)
If you are using RVM you might want to take a look at: LoadError: cannot load such file -- bundler/setup

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.

foreman only shows line with “started with pid #” and nothing else

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

Resources