I'm trying to reload unicorn with a USR2 signal, but I get the following error on the logs:
E, [2012-04-13T21:27:00.801192 #24474] ERROR -- : old PID:23820 running with existing pid=/home/user/app.git/tmp/unicorn.pid.oldbin, refusing rexec
I've search the internets but don't have a clue. It seems that unicorn is trying to write to the pid file? I'm issuing a kill -s USR2 PID
Thanks
I ran into this today. I'm assuming you have previously sent USR2 to unicorn, and this is now the second time you're trying to do so.
Per the unicorn documentation on signals and USR2: "A separate QUIT should be sent to the original process once the child is verified to be up and running."
In this particular case, you'd pass the old PID to kill
kill -s QUIT 23820
Or, you can take advantage of the fact this old PID is stored a known file (referenced in your error message) alongside the "current" PID, and execute:
kill -s QUIT `cat /home/user/app.git/tmp/unicorn.pid.oldbin`
Related
I'm currently using cloud 9 for this project. When I run it using rails server -b $IP -p $PORt it gives me this:
=> Booting Puma
=> Rails 5.0.0 application starting in development on http://0.0.0.0:8080
=> Run `rails server -h` for more startup options
A server is already running. Check /home/ubuntu/workspace/saasapp/tmp/pids/server.pid.
Exiting
Does anyone know how to fix this? I already tried closing and re-opening the tabs again, and stop running the run project button. The language is ruby-on-rails and I'm sort of a beginner.
The error is happening because you most likely started your server, then closed the terminal before closing the server. I also had that error, but what I did was that I clicked the memory cpu disk icon on the top right corner, then clicked restart, and re-ran my server, and it started. I'm not sure if it's the proper way, but I was following a tutorial and that's what they showed.
This happens when you close the terminal tab before ending Rails.
To end Rails, find its process ID with lsof, then kill it:
lsof -i tcp:8080
[copy the PID]
kill -9 [paste PID]
bin/rails s
Alternatively, you can also find the process ID in Puma's temporary files using cat, then kill it:
kill -9 $(cat tmp/pids/server.pid)
bin/rails s
Open this file:
/home/ubuntu/workspace/saasapp/tmp/pids/server.pid as it states in the error.
The file should contain the process ID.
Copy the ID.
Open the terminal -> https://docs.c9.io/docs/terminal and run the command
sudo kill -9 {the copied ID}
Subsequently delete the ID from the server.pid file and try to start the server again
i've installed and running redmine in my domain. something went wrong and i cant access redmine admin panel. i tried to reset password and also did some google and changed password in database. but no luck still cant login. then i removed all app files but its still running same as before..
this was the code i used to run redmine server
bundle exec ruby script/rails server webrick -e -s production
now i'm trying to stop or restart but nothing is working.
is there any way to stop the server.
Thanks in advance.
Kill the process
kill -INT $(cat tmp/pids/server.pid)
Its cleaner to write a rake task to do that:
task :stopserver do
pid_file = 'tmp/pids/server.pid'
if File.file?(pid_file)
print "Shutting down WEBrick\n"
pid = File.read(pid_file).to_i
Process.kill "INT", pid
end
File.file?(pid_file) && File.delete(pid_file)
end
Delete the file tmp/pids/server.pid) and then restart the server.
Usually you'll hit Ctrl-C to stop webrick when it's started without -d option. The Ctrl-C makes INT signal, so youcould try with kill -INT <pid> to stop webrick started with -d option.
If it doesn't stop you can try with kill -9 <pid> sending a KILL signal, that's not a proper clean shutdown but seems the only way to stop it. It's not a 'best practice' but it's the only method i've ever found.
$ killall -9 ruby
this command wil kill all the running instance of ruby on your system and you can restart ur server again
I have a unicorn + nginx setup and suddenly when I run cap unicorn:upgrade (which sends a USR2 to the master process) it doesn't prefix the .pid file and it doesn't fork a new master process at all. When I open the log file I can see the line
reaped #<Process::Status: pid 32448 exit 10> exec()-ed
can anyone suggest something to do in order to see what's wrong?
Thanks
Does your unicorn config have preload_app(true) ? You may need to send a QUIT signal if it does.
I'm experiencing a rather strange problem with unicorn on my production server.
Although the config file states preload_app true, sending USR2 to the master process does not generate any response, and it seems like unicorn is ignoring the signal altogether.
On another server sending USR2 changes the master process to and (old) state and starts a new master process successfully.
The problematic server is using RVM & bundler, so I'm assuming it's somehow related (the other one is vanilla ruby).
Sending signals other than USR2 (QUIT, HUP) works just fine.
Is there a way to trace what's going on behind the scenes here? Unicorn's log file is completely empty.
I suspect your issue might be that your Gemfile has changed, but you haven't started your unicorn in a way that allows USR2 to use the new Gemfile. It's therefore crashing when you try to restart the app.
Check your /log/unicorn.log for details of what might be failing.
If you're using Capistrano, specify the BUNDLE_GEMFILE as the symlink, e.g.:
run "cd #{current_path} && BUNDLE_GEMFILE=#{current_path}/Gemfile bundle exec unicorn -c #{config_path} -E #{unicorn_env} -D"
Here's a PR that demostrates this.
I experienced a similar problem, but my logs clearly identified the issue: sending USR2 would initially work on deployments, but as deployments got cleaned up, the release that the Unicorn master was initially started on would get deleted, so attempts at sending a USR2 signal would appear to do nothing / fail, with the error log stating:
forked child re-executing... 53
/var/www/application/releases/153565b36021c0b8c9cbab1cc373a9c5199073db/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:439:in
`exec': No such file or directory -
/var/www/application/releases/153565b36021c0b8c9cbab1cc373a9c5199073db/vendor/bundle/ruby/1.9.1/bin/unicorn
(Errno::ENOENT)
The Unicorn documents mention this potential problem at http://unicorn.bogomips.org/Sandbox.html: "cleaning up old revisions will cause revision-specific installations of unicorn to go missing and upgrades to fail", which in my case meant USR2 appeared to 'do nothing'.
I'm using Chef's application recipe to deploy applications, which creates a symlinked vendor_bundle directory that is shared across deployments, but calling bundle exec unicorn still resulted in the original Unicorn master holding a path reference that included a specific release directory.
To fix it I had to call bundle exec /var/www/application/shared/vendor_bundle/ruby/1.9.1/bin/unicorn to ensure the Unicorn master had a path to a binary that would be valid from one deployment to the next. Once that was done I could deploy to me heart's content, and kill -USR2 PID would work as advertised.
The Unicorn docs mention you can manually change the binary path reference by setting the following in the Unicorn config file and sending HUP to reload Unicorn before sending a USR2 to fork a new master: Unicorn::HttpServer::START_CTX[0] = "/some/path/to/bin/unicorn"
Perhaps this is useful to some people in similar situations, but I didn't implement this as it appears specifying an absolute path to the shared unicorn binary was enough.
I've encountered a similar problem on my VDS. Strace'ing revealed the cause:
write(2, "E, [2011-07-23T04:40:27.240227 #19450] ERROR -- : Cannot allocate memory - fork(2) (Errno::ENOMEM) <...>
Try increasing the memory size, XEN memory on demand limits (they were too hard in my case), or maybe turn on overcommit, through the latter may have some serious unwanted side effects, so do it carefully.
I am running my rails application using the following
$script/server -d webrick
on my Ubuntu system , above command run the webrick server in background . I could kill the process using kill command
$kill pid
Does rails provide any command to stop the background running daemon server ?
like the one provided by rails to start the server , Thanks .
EDIT When it is appropriate to start the daemon server ? Any real time scenario will help Thanks
if it can be useful, on linux you can find which process is using a port (in this case 3000) you can use:
lsof -i :3000
it'll return the pid too
Like Ryan said:
the pid you want is in tmp/pids/
probably server.pid is the file you want.
You should be able to run kill -9 $(cat tmp/pids/server.pid) to bring down a daemonized server.
How about a rake task?
desc 'stop rails'
task :stop do
pid_file = 'tmp/pids/server.pid'
pid = File.read(pid_file).to_i
Process.kill 9, pid
File.delete pid_file
end
run with rake stop or sudo rake stop
The only proper way to kill the Ruby on Rails default server (which is WEBrick) is:
kill -INT $(cat tmp/pids/server.pid)
If you are running Mongrel, this is sufficient:
kill $(cat tmp/pids/server.pid)
Use kill -9 if your daemon hung. Remember the implications of kill -9 - if the data kept in Active Record caches weren't flushed to disk, you will lose your data. (As I recently did)
The process id of the daemon server is stored in your application directory tmp/pids/. You can use your standard kill process_id with the information you find there.
In your terminal to find out the process id (PID):
$ lsof -wni tcp:3000
Then, use the number in the PID column to kill the process:
$ kill -9 <PID>
pguardiario beat me to it, though his implementation is a bit dangerous since it uses SIGKILL instead of the (recommended) SIGINT. Here's a rake task I tend to import into my development projects:
lib/tasks/stopserver.rake
desc 'stop server'
task :stopserver do
pid_file = 'tmp/pids/server.pid'
if File.file?(pid_file)
print "Shutting down WEBrick\n"
pid = File.read(pid_file).to_i
Process.kill "INT", pid
end
File.file?(pid_file) && File.delete(pid_file)
end
This issues an interrupt to the server if and only if the pidfile exists. It doesn't throw unsightly errors if the server isn't running, and it notifies you if it's actually shutting the server down.
If you notice that the server doesn't want to shut down using this task, add the following line after the Process.kill "INT" line, and try to upgrade to a kernel that has this bug fixed.
Process.kill "CONT", pid
(Hat tip: jackr)
A Ruby ticket, http://bugs.ruby-lang.org/issues/4777, suggests it's a kernel (Linux) bug. They give a work around (essentially equivalent to the Ctrl-C/Ctrl-Z one), for use if you've demonized the server:
kill -INT cat tmp/pids/server.pid
kill -CONT cat tmp/pids/server.pid
This seems to cause the original INT signal to be processed, possibly allowing data flush and so on.
Run this command:
locate tmp/pids/server.pid
output:
Complete path of this file. Check your project directory name to find your concerned file if multiple files are shown in list.
Then run this command:
rm -rf [complete path of tmp/pids/server.pid file]
Here I leave a bash function which, if pasted in you .bashrc or .zshrc will alloy you do things like:
rails start # To start the server in development environment
rails start production # To start the server in production environment
rails stop # To stop the server
rails stop -9 # To stop the server sending -9 kill signal
rails restart # To restart the server in development environment
rails restart production # To restart the server in production environment
rails whatever # Will send the call to original rails command
Here it is the function:
function rails() {
if [ "$1" = "start" ]; then
if [ "$2" = "" ]; then
RENV="development"
else
RENV="$2"
fi
rails server -d -e "$RENV"
return 0
elif [ "$1" = "stop" ]; then
if [ -f tmp/pids/server.pid ]; then
kill $2 $(cat tmp/pids/server.pid)
return 0
else
echo "It seems there is no server running or you are not in a rails project root directory"
return 1
fi
elif [ "$1" = "restart" ]; then
rails stop && rails start $2
else
command rails $#
fi;
}
More information in the blog post I wrote about it.
i don't think it does if you use -d. I'd just kill the process.
In the future, just open up another terminal window instead and use the command without -d, it provides some really useful debugging output.
If this is production, use something like passenger or thin, so that they're easy to stop the processes or restart the servers
one-liner: kill -INT `ps -e | grep ruby | awk '{print $1}'`
ps -e lists every process on the system
grep ruby searches that output for the ruby process
awk passes the first argument of that output
(the pid) to kill -INT.
Try it with echo instead of kill if you just want to see the PID.
if kill process not works, then
delete file server.pid from MyRailsApp/tmp/pids/
I came here because I were trying to (unsuccesfully) stop with a normal kill, and thought I'd being doing something wrong.
A kill -9 is the only sure way to stop a ruby on rails server?
What!? Do you know the implications of this? Can be a disaster...
You can start your server in the background by adding -d to your command. For instance:
puma -d
To stop it, just kill whatever process is running on port 3000:
kill $(cat tmp/pids/server.pid)