I am trying passenger on Ubuntu 18.04, pretty much generic install and the passenger-status call crashes. Not super clear how to set the path that it uses for local socket communication.
Version : 6.0.12
Date : 2021-11-17 23:20:19 +0000
Instance: PdoRpeL5 (Apache/2.4.29 (Ubuntu) Phusion_Passenger/6.0.12)
Traceback (most recent call last):
6: from /usr/sbin/passenger-status:349:in `<main>'
5: from /usr/sbin/passenger-status:346:in `start'
4: from /usr/sbin/passenger-status:62:in `command_show_status'
3: from /usr/sbin/passenger-status:124:in `show_status'
2: from /usr/lib/ruby/vendor_ruby/phusion_passenger/admin_tools/instance.rb:94:in `http_request'
1: from /usr/lib/ruby/vendor_ruby/phusion_passenger/admin_tools/instance.rb:94:in `new'
/usr/lib/ruby/vendor_ruby/phusion_passenger/admin_tools/instance.rb:94:in `initialize': too long unix socket path (116bytes given but 108bytes max) (ArgumentError)
Looking at that code, #path is /tmp/systemd-private-af50a27a57d04fec9366f72dd251a3be-apache2.service-Dy9bBV/tmp/passenger.PPuC2RN which makes the socket name /tmp/systemd-private-af50a27a57d04fec9366f72dd251a3be-apache2.service-Dy9bBV/tmp/passenger.PPuC2RN/agents.s/core_api
Seems like a passenger internal issue but I'm looking for a workaround...
Have you tried editing your web server service file, nginx.service or apache2.service? I had this problem and solved it by removing the line:
PrivateTmp=true
from /etc/systemd/system/multi-user.target.wants/apache2.service.
Then:
sudo systemctl daemon-reload
sudo systemctl restart apache2
https://github.com/phusion/passenger/issues/2397
"this is because the path generated by the systemd private tmp feature is 80 chars long, which only leaves 27 chars for an application to use, and passenger uses 35 chars in its path to its socket."
Related
I've changed from Mac to Linux (Ubuntu) a couple of days ago and I cloned the repo from my team project in GitHub. (It was working before this with Mac). But now, I've got this problem.
I was trying to start the server on local Unix socket (3000) by running
bundle exec puma
but it shows me these errors instead.
[3217] Puma starting in cluster mode...
[3217] * Version 4.3.3 (ruby 2.6.5-p114), codename: Mysterious Traveller
[3217] * Min threads: 1, max threads: 16
[3217] * Environment: development
[3217] * Process workers: 1
[3217] * Preloading application
Traceback (most recent call last):
13: from /home/shaun/.rvm/gems/ruby-2.6.5/bin/ruby_executable_hooks:24:in `<main>'
12: from /home/shaun/.rvm/gems/ruby-2.6.5/bin/ruby_executable_hooks:24:in `eval'
11: from /home/shaun/.rvm/gems/ruby-2.6.5/bin/puma:23:in `<main>'
10: from /home/shaun/.rvm/gems/ruby-2.6.5/bin/puma:23:in `load'
9: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/bin/puma:10:in `<top (required)>'
8: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/cli.rb:80:in `run'
7: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/launcher.rb:172:in `run'
6: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/cluster.rb:413:in `run'
5: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/runner.rb:161:in `load_and_bind'
4: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/binder.rb:90:in `parse'
3: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/binder.rb:90:in `each'
2: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/binder.rb:151:in `block in parse'
1: from /home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/binder.rb:328:in `add_unix_listener'
/home/shaun/.rvm/gems/ruby-2.6.5/gems/puma-4.3.3/lib/puma/binder.rb:328:in `listen': Address already in use - listen(2) (Errno::EADDRINUSE)
I've then tried to run
bundle exec puma -C config/puma.rb -b tcp://127.0.0.1:3001
but the server stops right away without running it.
[3263] Puma starting in cluster mode...
[3263] * Version 4.3.3 (ruby 2.6.5-p114), codename: Mysterious Traveller
[3263] * Min threads: 1, max threads: 16
[3263] * Environment: development
[3263] * Process workers: 1
[3263] * Preloading application
[3263] * Listening on tcp://127.0.0.1:3001
[3263] Use Ctrl-C to stop
I've also tried the methods given in this post: Address already in use - bind(2) (Errno::EADDRINUSE)
Like
lsof -wni tcp:3000
but nothing was shown for me to kill the Pid process.
Can someone please help?
These are the software versions I'm using:
Ubuntu 18.04 LTS
Ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]
Puma version 4.3.3
This is the code in config/puma.rb
# vars
app_dir = File.expand_path("../..", __FILE__)
shared_dir = "#{app_dir}/shared"
# Specifies the `environment` that Puma will run in.
environment ENV.fetch("RACK_ENV") { "production" }
# pidfile and state
pidfile "#{shared_dir}/pids/puma.pid"
state_path "#{shared_dir}/pids/puma.state"
# Threads for serving requests
threads 1, 16
# Workers (cpu cores)
workers ENV.fetch("WEB_CONCURRENCY") { 1 }
preload_app!
# Unix socket to for nginix reverse proxy
bind "unix://#{shared_dir}/sockets/puma.sock"
# Port for local server use
port ENV.fetch("PORT") { 3000 }
# Debugging
debug
# Logging
stdout_redirect "#{shared_dir}/log/puma.stdout.log", "#{shared_dir}/log/puma.stderr.log", true
activate_control_app
rackup "#{app_dir}/config.ru"
It looks like you're running another program on port 3000. Run lsof -i:3000 and stop it using kill command when there are some result from the command.
I'm running a script (running on an AWS EC2 instance) that continually pulls state legislative data from an API, and persists it to a SQLite3 .db file. When I try to run the script as a daemon in the background, the process immediately stops and I'm given the following error.
stateleg.rb: process with pid 4666 started.
Traceback (most recent call last):
11: from stateleg_daemon.rb:4:in `<main>'
10: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons.rb:149:in `run'
9: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/cmdline.rb:121:in `catch_exceptions'
8: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons.rb:150:in `block in run'
7: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/controller.rb:59:in `run'
6: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/application.rb:307:in `start'
5: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/application.rb:228:in `start_load'
4: from /usr/local/rvm/gems/ruby-2.5.1/gems/daemons-1.3.1/lib/daemons/application.rb:228:in `load'
3: from /home/ubuntu/stateleg.rb:8:in `<top (required)>'
2: from /home/ubuntu/stateleg.rb:8:in `new'
1: from /usr/local/rvm/gems/ruby-2.5.1/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:89:in `initialize'
/usr/local/rvm/gems/ruby-2.5.1/gems/sqlite3-1.4.1/lib/sqlite3/database.rb:89:in `open_v2': unable to open database file (SQLite3::CantOpenException)
When I try to run the script in the foreground, the script runs perfectly, and the necessary information is written to the .db file.
How can I make this daemon open the database file? Are SQLite3 and Ruby daemons in some way incompatible? Any information at all would be tremendously helpful.
This is the entirety of the daemon script.
require 'daemons'
Daemons.run('stateleg.rb')
When something is "daemonized" it's usually running in a different working directory than the one you expect. This is especially true for services that are spun up on boot, such as through systemd, or on cron.
In order to account for this you need to specify the full path to files you're intending to work with. These are called absolute paths since they're not impacted by the current working directory. /a/b/c is an absolute path, it starts with /, but b/c is relative. If you're in /a it's equivalent, but it won't work outside of that scope.
If you know the location of that file relative to your script, you can usually do this:
Daemons.run(File.expand_path('stateleg.rb', __dir__))
Where __dir__ is the directory in which the currently executing script file is stored.
What is the proper way to prevent Sinatra from displaying the full backtrace, when it fails to properly run the server (for example, due to the port being already in use)?
This is a sample sinatra app:
# test.rb
require 'sinatra'
require 'bundler/inline'
gemfile do
gem 'sinatra'
gem 'puma'
end
set :bind, "0.0.0.0"
set :port, 3000
get '/' do
"hello"
end
Then, running it with ruby test.rb once, to occupy the port.
Then, running it again in another terminal window, and this full error backtrace is shown:
$ ruby test.rb
== Sinatra (v2.0.4) has taken the stage on 3000 for development with backup from Puma
Puma starting in single mode...
* Version 3.12.0 (ruby 2.5.0-p0), codename: Llamas in Pajamas
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:3000
== Someone is already performing on port 3000!
Traceback (most recent call last):
5: from /store/gems/ruby-2.5.0/gems/sinatra-2.0.4/lib/sinatra/main.rb:26:in `block in <module:Sinatra>'
4: from /store/gems/ruby-2.5.0/gems/sinatra-2.0.4/lib/sinatra/base.rb:1464:in `run!'
3: from /store/gems/ruby-2.5.0/gems/sinatra-2.0.4/lib/sinatra/base.rb:1464:in `ensure in run!'
2: from /store/gems/ruby-2.5.0/gems/sinatra-2.0.4/lib/sinatra/base.rb:1439:in `quit!'
1: from /store/gems/ruby-2.5.0/gems/puma-3.12.0/lib/puma/launcher.rb:147:in `stop'
/store/gems/ruby-2.5.0/gems/puma-3.12.0/lib/puma/single.rb:27:in `stop': undefined method `stop' for nil:NilClass (NoMethodError)
Traceback (most recent call last):
3: from /store/gems/ruby-2.5.0/gems/sinatra-2.0.4/lib/sinatra/base.rb:1545:in `block in setup_traps'
2: from /store/gems/ruby-2.5.0/gems/sinatra-2.0.4/lib/sinatra/base.rb:1439:in `quit!'
1: from /store/gems/ruby-2.5.0/gems/puma-3.12.0/lib/puma/launcher.rb:147:in `stop'
/store/gems/ruby-2.5.0/gems/puma-3.12.0/lib/puma/single.rb:27:in `stop': undefined method `stop' for nil:NilClass (NoMethodError)
Since I am using it as an embedded server, I would like the output to simply and with the friendly error that Sinatra is already showing:
== Someone is already performing on port 3000!
and avoid showing the backtrace.
Ruby by default outputs error messages to the STDOUT. But if you're on *nix system you can do this:
ruby test.rb > /dev/null 2>&1
For windows you can probably do
ruby test.rb > NULL
windows powershell
ruby test.rb > $null
but for windows also see Is there a /dev/null on Windows?
But if you want programmatically suppress output when server is running this should work on *nix but not sure on windows
# test.rb
require 'sinatra'
require 'bundler/inline'
gemfile do
gem 'sinatra'
gem 'puma'
end
set :bind, "0.0.0.0"
set :port, 3000
get '/' do
"hello"
end
unless `ps aux | grep sinatra`.match('tcp://0.0.0.0:3000')
STDOUT.reopen('/dev/null', 'w')
STDERR.reopen('/dev/null', 'w')
end
See suppresing output to console with ruby
You can test to see if the port is in use by attempting to listen on the port before allowing Sinatra and Puma to take over. This isn't 100% effective because there's a race condition where you may open and close the port, but before Sinatra/Puma finish initializing some other process comes along and listens on the same port, but it should work for your use-case (which appears to be a cosmetic hack only).
Insert this code anywhere in test.rb:
require 'socket'
include Socket::Constants
begin
# Open and close the port
socket = Socket.new(AF_INET, SOCK_STREAM, 0)
sockaddr = Socket.pack_sockaddr_in(3000, '0.0.0.0')
socket.bind(sockaddr)
socket.listen(1)
socket.close
rescue Errno::EADDRINUSE => error
# Traps the same error that is trapped by Sinatra and exits if raised
puts error.message
exit
end
Start the first one with ruby test.rb:
== Sinatra (v2.0.4) has taken the stage on 3000 for development with backup from Puma
Puma starting in single mode...
* Version 3.12.0 (ruby 2.6.0-p-1), codename: Llamas in Pajamas
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
Start the second one with ruby test.rb:
Address already in use - bind(2) for 0.0.0.0:3000
You can flesh out what you want printed to the console inside the rescue block.
This appears to be caused by an issue with Puma, that is fixed by this PR.
When a machine gets rebooted. it fails on chef-client run(run from rc.local) but if i run it manually it gets success and same error return on next auto chef-run.when i restart the chef-client the error stop coming .
in fact when chef-client was failing on auto run ,ohai was giving the correct output.
root#something:~# ohai | grep 'fqdn'
"fqdn": "something.someone",
root#something:~# chef-client -v
Chef: 12.20.3
root#something:~# ohai -v
Ohai: 8.23.0
root#something:~# hostname -f
something.someone
Output of stacktrace
root#something:~# cat /var/chef/cache/chef-stacktrace.out Generated at
2018-04-02 15:36:30 +0000 Chef::Exceptions::CannotDetermineNodeName:
Unable to determine node name: configure node_name or configure the
system's hostname and fqdn
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:299:in
node_name'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:313:in
register'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:416:in
do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:213:in
block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:207:in
fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/client.rb:207:in
run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application.rb:237:in
run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application/client.rb:338:in
block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application/client.rb:327:in
loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application/client.rb:327:in
run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/lib/chef/application.rb:55:in
run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.14.2/bin/chef-client:26:in
' /usr/bin/chef-client:23:in load'
/usr/bin/chef-client:23:in'root#web1.cst.webpod1-cph3:~#
You've clearly got a mismatch in what you are running. Your CLI says Chef 12, but the stack trace says Chef 11. I'm guessing you installed one via our Omnibus packages and the other via Rubygems? No matter the cause, fix that conflict and you'll probably be happier.
I am trying to setup redmine on my server which is Redhat 6.2
I intend it to run with Nginx using thin ruby gem.
I was following http://www.redmine.org/projects/redmine/wiki/HowTo_configure_Nginx_to_run_Redmine
I did following things
gem install thin
thin install
this gives me init script under /etc/rc.d/thin The YML file config is as follows:
---
chdir: /app/redmine-root/
environment: development
address: 0.0.0.0
port: 5000
timeout: 30
log: log/thin.log
pid: tmp/pids/thin.pid
max_conns: 1024
max_persistent_conns: 100
require: []
wait: 30
servers: 4
daemonize: true
Now when I do /etc/rc.d/thin start it shows
Starting server on 0.0.0.0:5000 ...
Starting server on 0.0.0.0:5001 ...
Starting server on 0.0.0.0:5002 ...
Starting server on 0.0.0.0:5003 ...
but when I see pids under /app/redmine-root/tmp/pids there are no Pids.
therefore, I can't see any service running. This is issue number 1
Second thing I'd like to ask that, in Nginx conf as suggested by the above link the upstream block is like as follows:
upstream thin_cluster {
server unix:/tmp/thin.0.sock;
server unix:/tmp/thin.1.sock;
server unix:/tmp/thin.2.sock;
server unix:/tmp/thin.3.sock;
}
But the pid file is in /app/redmine-root/tmp/pids should this work?
Third, At the time of Install I marked the env as production
RAILS_ENV=production rake db:migrate
But whenever I do thin config -C /etc/thin/redmine.yml it changes to development.
Please note that I have RVM also. And the user & owner of /app/redmine-root/ is apache.
My nginx runs with apache and I am trying to run thin also as apache.
I have no background in Ruby. Any help is much appreciated.
EDIT
After suggestions, I found this in log.
/usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/backends/tcp_server.rb:16:in `connect': cannot load such file -- thin/connection (LoadError)
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/backends/base.rb:55:in `block in start'
from /usr/local/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `call'
from /usr/local/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
from /usr/local/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/backends/base.rb:63:in `start'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/server.rb:159:in `start'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/controllers/controller.rb:86:in `start'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:187:in `run_command'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/lib/thin/runner.rb:152:in `run!'
from /usr/local/lib/ruby/gems/2.0.0/gems/thin-1.5.1/bin/thin:6:in `<top (required)>'
from /usr/local/bin/thin:23:in `load'
from /usr/local/bin/thin:23:in `<main>'
is it because, I am trying to configure on UNIX socket or its something else??
You should add gem thin to your Gemfile
PS: see at https://github.com/macournoyer/thin/issues/115 for example.