Newbie here. I created a rails project in rubymine to run the default index.html from public folder I pressed 'shift' + F10 key. This is same as rails server from the terminal. This is what I get:
/home/bubble/.rvm/rubies/ruby-1.9.2-p180/bin/ruby -e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) /home/bubble/Desktop/Hard Boiled Bubble/bubbles/script/rails server -b 0.0.0.0 -p 3334 -e development
=> Booting Mongrel
=> Rails 3.1.0.rc1 application starting in development on http://0.0.0.0:3334
=> Call with -d to detach
=> Ctrl-C to shutdown server
Nice clean. But now I cannot shutdown the server. It simply doesn't work. Neither from terminal nor rubymine. I have to kill the process from the system monitor everytime.
Any clues, of what can be wrong in my set up? Is is because of rails 3.1.0.rc --pre ??
Got similar issue with Rubymine 3.1 (it do not seems to be a Rubymine issue) and rails 3.0.9 (it also do not seems to be a Rails issue). Om my computer I have the same problem by running the erver from the console.
Try running rails s in the console from your application directory, and stop the process (server) by pressing Ctrl+C.
On my Ubuntu 11.4 + Rails 1.9.2 (via RVM) it doesn't work as well, proving the issue do not come from Rubymine.
Looking around the web, it is quite common that ruby server "stale", but it is the very first time I see it, and didn't get the solution for now (sorry for that).
Last but not least ! Process stale with all ruby server I tried : Webrick, Mongrel & Thin. Making me think, it is a ruby issue, it seems that the stop signal does not arrive to the server...
I'll also be glad, if somebody has some more clues to fix this.
This is actually quite a common that myself and other developers see. It's nothing to do with the rails version. It happens in all versions. It's just that the server becomes a detached process and can be hard to find.
However I've learned to cope with it pretty well thanks to things I learned:-
Always use the red square to stop the server, not the red X.
If the server hangs, rather than rebooting you can just use the menu option for run... and change the port number, say from 3334 to 3335 (and so on). It sounds bad but it really doesn't hurt and only take 3 seconds...
If necessary you can also keep a terminal window open and run the server from that and just use rubyMine for editing, but then you are missing out on a lot of rubyMine features and also you have to keep both environments working ok.
It may be specific to Ubuntu as that is where I have seen it too.
Related
I'm just getting back into trying some front end projects for the first time in a few years. Many npm-based javascript projects I try out end up taking a long time to start up in development mode even for Hello World-ish examples. In particular I'm trying out Nuxt.js.
Dev server startup takes about 100 seconds, and nothing seems to get cached so restarts (not hot reloads) take the same amount of time. My research into the project and known npm issues did not turn up any definitive root cause or ways to improve this yet.
I'm using emacs 26.1 in terminal mode on a 2018 13" MacBook Pro with a core i5, 8 GB of ram, and an SSD.
When I run npm run dev to startup the nuxt dev server I get repeated error in process filter: Args out of range: "\342", -1 errors related to some unusual characters they are using to try to make the output pretty. If I try the same thing in a vanilla Mac OS terminal the server startup goes 10x faster. Why do those errors occur, and why is it so much slower in an emacs terminal?
It turns out the repeated error in process filter issue may be caused by a bug in term mode that was recently fixed but might still be an issue in my version of emacs.
As a workaround, the following can get the nuxt dev server running in ~10s instead of ~100s in an emacs terminal on my mac by filtering out the repeated lines about the modules being built:
$ npm run dev | grep -v modules
Note that I tried using npm's options to adjust the log level but none seem to filter this output. If anyone knows a more "official" way of filtering this, or even better, if you know how to make it such that it doesn't try to rebuild the modules on every dev server start up, I'd be interested to know.
Edit: it might make sense to adjust the dev script command in the package.json file to include the grep filter, that way you can still just type npm run dev and get the workaround.
I use this solution to have a VNC desktop session with a remote Ubuntu PC https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-on-ubuntu-16-04
I want to setup monodevelop on this machine. I followed the instructions and am able to run monodevelop and write code, however when I attempt to run it I get "Could not connect to the debugger". I tried various solutions suggesting changing environment variables to force monodevelop to use xterm and it did not work, however I'm not positive I did it correctly as the solution was meant for gnome and the modifications to the command for XFCE were not clear to me. At this point I'd be willing to get paid support, but I'm not even sure where I could find any for my use case. Does anyone have experience getting monodevelop to work on XFCE? If not what is the best environment for getting it going (ideally a way where I could remote in too). I'm very accustomed to the RDP workflow where I can actually troubleshoot on a development server and be very close to the real world environment to get things running, then check-in and deploy. I think there are a lot of platform differences with monodevelop so I really really really want to develop on Ubuntu (remotely).
I've tried to start the rails server with this line:
$ rails s
create
create app/controllers
create app/helpers
create app/models
create app/views/layouts
create config/environments
...
create log/test.log
But if I write down this:
$ script/rails s
/usr/lib/ruby/gems/1.8/gems/bundler-1.0.10/lib/bundler/runtime.rb:138: warning: Insecure world writable dir /usr/lib/ruby/gems/1.8 in PATH, mode 040777
=> Booting WEBrick
=> Rails 3.0.1 application starting in development on http://0.0.0.0:3000
...
Anyone can see the problem? I think is a problem with environment variables, but I don't know how to fix it.
Thanks
I just came across this problem. I was switching from a Windows environment to Linux. My Linux version of rails is 2.3.14 while my Windows version was 3.0.1. On Windows "rails s" or "rails server" worked as expected to start a server, but on Linux it just created new projects with the names "s" and "Server" respectively. What finally explained it is the answer to the question below. Apparently the command behavior was changed between rails versions.
rails script/server doesn't start the server
The best solution is probably to update to the latest rails.
I was able to do that on my linux box by following the instructions below and using "sudo gem install rails"
http://installfest.railsbridge.org/installfest/ubuntu
http://root2linux.com/2011/01/install-rails-3-on-linux-mint-10/
this issue come from the different version in rvm, I faced this issue when my app was created using rvm 1.9.2 and I tried to run the server while rvm 1.9.3 was the running rvm version, simply switch to rvm1.9.2 and all will work properly (rvm use 1.9.2) in the terminal in ubunutu
Are you in a rails application directory? When you're running rails s make sure you've cd'd into the correct Rails directory. Common problem :)
I have an application that uses rufus-scheduler to run a variety of background tasks. After recently upgrading to Ruby 1.9.2, we continue to have intermittent segmentation errors and/or bus errors. The error will occur in different libraries.
The one thing that I've identified is that the same functions that will cause a segmentation fault when running under rufus-scheduler will NOT fail when run from a console.
This occurs on two platforms (OSX for development, ubuntu for production) in the same way.
Does anyone have any ideas on what differs in the runtime between the rufus-scheduler environment and running something straight from "rails c" console?
Thanks in advance...
Russell
You seem to imply it worked with Ruby 1.8.x. What Ruby 1.9.2 patchlevel anyway ?
Rufus-scheduler is a very dumb library, you could replace it altogether with things like
Thread.new do
loop do
sleep 60 * 60
trigger_my_hourly_task
end
end
Thread.new do
loop do
sleep 24 * 60 * 60
trigger_my_daily_task
end
end
and see if the problem still occurs.
There is no rufus-scheduler environment, rufus-scheduler is pure-ruby, it lives in the environment of your server and your rails application. Running things in the "rails c" console is running stuff in a brand new process, with no accumulated memory usage, it's "blue sky".
If you really think it's a rufus-scheduler issue, you should be able to come up with a detailed way of reproducing the issue.
I've just upgraded to rails 3. Beside some problems on the page I experience as well a strange latency after running the test environment for a while... The speed is normal but after a few clicks on the page, it suddenly "freezes" and needs about a minute to load the page. Unfortunately it doesn't matter where I click though. Just after the test environment was running for a while it shows up to suddenly have this problem. Even when I want to stop the server it needs a minute to do so. Restarting the server let it working for a while
Thanks for any help
Markus
If you are on Mac or Linux, try installing RVM and installing Ruby Enterprise Edition .