I ran bundle exec rake assets:precompile in order to solve the Webpack error referenced here.
Then when I load localhost:3000, it takes forever to load. How can I undo this, or make it faster to load?
ps This is my first question on SO so let me know if I should add something.
I figured this issue out. For some reason I had a server port running in the background that was slowing this down. I used
lsof -nP +c 15 | grep 3035
to find what was running there, and then found the PID.
Then I used
kill -9 <PID>
to kill it. After that, I restarted my server and it ran smoothly!
Related
In my Dev box on Nitrous, I am able to run God -c scripts.god -D to restart the two .rb files if they die.
I just run that and the processes for the most part stay alive.
But I cannot do the same in heroku. It seems when I run the god command the .god file does not open and generates an error in heroku.
Question:
How can I run God to restart failed processes in heroku as I do on my development Nitrous environment?
Or is there a recommended alternative way to watch heroku processes and restart them automatically when they fail?
On Heroku you shouldn't need to use a process supervisor like god. If all you need is to ensure your process is restarted if it crashes, Heroku can manage that fine.
It should be as simple as adding two entries in your procfile as workers. https://devcenter.heroku.com/articles/background-jobs-queueing
worker: bundle exec sidekiq
clock: bundle exec clockwork lib/clock.rb
slack_listener: bundle exec ruby lib/slack_bot.rb
You could possibly have issues, if your processing are crashing quite often. Dyno Crash Restart Policy
Your processes should start automatically when you access your website.
However, Heroku does provide commands to manage your processes, check out https://devcenter.heroku.com/articles/dynos for the complete list. E.g., to restart all processes, use the toolbelt command:
heroku ps:restart --app yourappname
When there are problems while running a recipe and the client run is hanging half way, the installed Chef client will be unusable.
You can then exit the machine, reboot, clean up chef pid files and so forth but each time the Chef client is started the following message is shown:
Chef client is running, will wait for it to finish and then run.
Chef should be able to recover from this when a reboot is performed but this is not the case.
What is the best way to recover from a client run that hangs half way? Currently I delete the VM and create a new one but that is not a real solution.
Is it possible to recover when it hangs half way?
Stop the service if any running : sudo service chef-client stop
if the issue persists
find out if nay chef client process/service is running: ps aux | grep chef
kill the process
if the issue persists
look up your chef client settings under /etc/chef/client.rb and/or your etc/init.d/chef-client
then locate the pid_file and lockfile path
delete the files
if the issues persists, you might run like me a old version of chef-client
you need to look in your chef cache folder
I had to delete /var/chef/cache/chef-client-running.pid
If it timeout takes place - converging should work fine over and over again. Well, if you need to remove client - you can run sudo rm -rf /etc/chef on client machine. All the options are described here in details.
I ran into the same issue where the kitchen converge process would get hung, typically due to an improper msi installation in my case. I would then have to reboot the kitchen machine.
I noticed that an elevated scheduled task was running which when stopping, it would kill the process, but the issue returned when I ran it again ("chef client 2092 is running, will wait for it to finish and then run").
It then occurred to me that the last attempt to reboot, which normally resolves the issue, didn't succeed because of an open file preventing the reboot. Rebooting the machine did resolve the issue in my case. It's not a perfect solution but it does work as a work-around in my case.
I have experience with Ruby on Rails but I'm trying to run Stringer the self-hosted RSS reader which is only Ruby. They suggest using Foreman to run the project which is fine, I can get the project up and running. However, for the life of me I cannot figure out how to keep the project running when I close the terminal.
I believe the Procfile is important in this process?? So here is mine.
web: bundle exec unicorn -p $PORT -c ./config/unicorn.rb
console: bundle exec racksh
Please forgive my ignorance. I'm mostly an iOS developer.
Sounds like you just want to daemonize the process, in which case just run:
foreman start &
I am very new at Mongo. I am running mongod as described here in Mac OS X. I am running two mongod processes from the command line. If I need to stop the mongod processes I just execute kill <pid of mongod>. Is it the recommended way to stop mongod?
It finally succeeded (Ubuntu 15.04) with
//1.find process by name:
$ pgrep mongo
1350
//2.kill mongod-process
$ kill 1350
This is quite late, but I had same problem now, and I found one easy way :
Esan-iMac:~$mongo admin --eval "db.shutdownServer()"
MongoDB shell version: 2.6.4
connecting to: admin
2015-02-19T10:54:22.574+0200 DBClientCursor::init call() failed
server should be down...
It's giving some odd messages, but it works.
And I made alias-command for running it easy.
alias stop-mongo='/opt/mongo/release/bin/mongo admin --eval "db.shutdownServer()"'
This works at least if you start your mongo manually (e.g. with --fork option).
The accepted answer by Esa is correct. Also, regarding whether using kill is recommended - yes, but with flag -2 or no flag, never use -9. As mentioned in docs.
kill -2 `pgrep mongo`
Alias
alias stopmongo='kill -2 `pgrep mongo`'
Windows
use admin
db.shutdownServer()
For systems with auth enabled, users may only issue db.shutdownServer() when authenticated to the admin database or via the localhost interface on systems without authentication enabled.
Linux
mongod --shutdown
you can also use
kill <mongod process ID>
see http://docs.mongodb.org/manual/tutorial/manage-mongodb-processes/
For year of 2020:
Mongo should be installed through Brew, rather than the old school style on linux: i.e. tar.gz package download/uncompress/configure/run.
In the brew way, if Mongo is installed by brew tap mongodb/brew and brew install mongodb-community, you could do as follows to stop (and disable) it alike Systemd on Linux.
~ brew services list
Name Status User Plist
mongodb-community started zhengxin /Users/zhengxin/Library/LaunchAgents/homebrew.mxcl.mongodb-community.plist
~ brew services stop mongodb-community
==> Successfully stopped `mongodb-community` (label: homebrew.mxcl.mongodb-community)
terminal$ kill $(pgrep mongod)
this command can help killing the mongod process. sudo pkill -f mongod
Just encountered an issue with "just killing the mongod" in mac...
The mongod is kept running as a service by "launchctl" in mac systems. "just killing" it will kill that service.
Now to use mongo shell we do mongod again, however for other development purpose like connecting from node we need to make sure to run mongod time and again.
Other alternative is shut down the system and start again.
Better Way :
Start using launchctl to manage such services. Here is an example for that :
What is the correct way to start a mongod service on linux / OS X?
The easiest way is Ctrl + C, which worked for me on a blocking bash shell under El Capitan.
If you have configured autostart, killing the process won't help, new one will start immediately. In order to disable autostart, you have to locate the autostart file first. You can try to find the file using e.g.
find / -name "mongodb.plist" or locate "mongodb.plist"
After the file is found, remove the autostart config using (you can try without sudo first, it's not needed if you have done the installation using Homebrew):
sudo launchctl unload -w <file>
If you want to kill the process anyway and it's not using autostart, remember not to use kill -9 <PID>, it can damage the db. kill -1 <PID> or kill -15 <PID> should be safe options.
https://docs.mongodb.com/manual/tutorial/manage-mongodb-processes/
official guide
remember not to use kill -9
otherwise maybe you need to remove lock file in dbpath
Ok, I'm making my first ruby app. Who know moving everything over to 'production' is so fugging complicated. So far I've struggled my way through configuring passenger, getting it to run on startup, then getting redis to run on startup.
My last task is on startup to add 1 worker. Right now, I have to ssh in and run my rake command rake workers:start. Obviously this is no good when I want to close ssh.. so I just dont really know how or what the next step is.
I tried copying resque default config to config.ru and it just blows up Passenger with errors. I also looked into resque-pool which some people mentioned but that is over my head.
all i have to do is add 1 worker on bootup. This isnt that serious of an app so simpler would be best at this point.
I don't use the god gem because (1) I've seen a project that was very thrashed by the complexity of setup it introduced, and (2) I'm personally really comfortable with the standard Linux (Ubuntu) tools that handle this kind of thing.
To start the Resque workers on bootup
I have this code in my /etc/rc.local file. I have a deploy user on the system:
# Start Resque
su -l deploy -c "/home/deploy/start-resque-workers"
su -l deploy -c "/home/deploy/start-resque-webui"
Then, in those scripts I set up the ruby environment and run the rake task:
# Load RVM into a shell session *as a function*
if [[ -s "$HOME/.rvm/scripts/rvm" ]] ; then
# First try to load from a user install
source "$HOME/.rvm/scripts/rvm"
elif [[ -s "/usr/local/rvm/scripts/rvm" ]] ; then
# Then try to load from a root install
source "/usr/local/rvm/scripts/rvm"
else
printf "ERROR: An RVM installation was not found.\n"
fi
# Use rvm to switch to the default ruby.
rvm use default
# Now launch the app
cd /home/deploy/app-name-here/current
nohup rake QUEUE=* RAILS_ENV=production environment resque:work &
I've been using this kind of set up for years, and it's solid. The servers don't crash. I don't yet need the overhead of installing another system (like the god gem) to watch over these other servers.
Additionally, I use a capistrano gem to handle restarting the workers on deploy.
In production you should be using god to watch your processes. Even if this project is a small one, I strongly recommend investing your time and setting it up.
Another big a must is Capistrano.
So, if you were using god, here's a config file that would help you.
You could also try scheduling rake resque:work at system startup, using a proper script in /etc/init.d/ or /etc/init/ or another (depends on what system you use). I tried this some time ago and I gave up (don't remember why).
I understand that this my answer isn't exactly what you're looking for right now. But imagine this: if everything is set up, then deploying next version is as easy as running rake deploy on your development machine. And it will take care of pulling your code from repository, running migrations, restarting workers and webservers and what not.