Running arch, when developing rails the console's tab completion for everything is incredibly slow. Even if the list it returns is inherently small.
User.n for instance shouldn't return a horrid number of options, but it will basically halt for upwards of 20 seconds before doing anything. Behavior repeats on every attempt. Any idea on how to fix?
I fixed this by removing the following lines from the file /etc/profile:
PATH="$PATH:$(ruby -e 'print Gem.user_dir')/bin"
export GEM_HOME=$HOME/.gem
export PATH
And adding the following to ~/.profile
# make rails gems work
PATH="$PATH:$(ruby -e 'print Gem.user_dir')/bin"
export GEM_HOME=$HOME/.gem
Related
I clean hacked Wordpress installations for clients on a regular basis, and I have a set of scripts that I have written to help me track down where the sites are hacked. One code snippet that I use on a regular basis worked fine on Ubuntu, but since switching to Fedora on Friday has quite behaving as expected. The command is this:
grep -Iri --exclude "*.js" "eval\s*(" * | grep -rivf ~/safeevals.txt >../foundevals.txt;
What it is supposed to happen (and did happen when I was using Ubuntu): grep through all non-binary files, excluding Javascript includes, for all occurances of the eval() function, then perform a negative match on a line by line basis against all known occurances of the eval() function in a vanilla installation of Wordpress (the patterns of which are in ~/safeevals.txt).
What is actually happening: The first part is working fine, as I ran it separately and it did find all instances of eval() in the installation. However, instead of greping through those results, after the pipe is it re-grepping through all of the files, returning a negative match of ~/safeevals.txt (ie. pretty much every line of every file in the installation).
Any idea why the second grep isn't acting on the piped data, or what I need to do to fix it? Thanks.
-Michael
Just tested on my Debian box: apparently, grep -r likes to assume a default argument of .. I am really wondering if that behaviour is valid. Anyway, I guess dropping the -r option from the second grep command will fix it.
Edit: rgrep defaulting to $PWD seems to be a recent change in grep, see this discussion on unix.stackexchange and the link there to the commit in the upstream grep code repository.
Basically, "passenger start" works fine from the terminal, but a simple script like "passenger start" doesn't work because it fails with:
*** Exception PhusionPassenger::UnknownError in PhusionPassenger::Rack::ApplicationSpawner (Could not find abstract-1.0.0 in any of the sources (Bundler::GemNotFound)) (process 19278, thread #<Thread:0x7f16dbfaf368>):
Looks to me like it can't find the gems anymore. This seems to be a very common problem on Google, but I cannot find any simple answer. I do not want to monkey patch my rails application with something like this: http://blog.ninjahideout.com/posts/the-path-to-better-rvm-and-passenger-integration (which I couldn't actually get to work, anyway)
It seems unbelievable that there's not a simple way to handle this. Why is running passenger from a shell script any different from typing it by hand?
UPDATE: basically, I fixed it by not using passenger. Instead of using "passenger start" I now use "rails server" and it works fine. Now, obviously, this doesn't "solve" the issue I was having, but it's good enough for my development needs.
I'd also like to elaborate a bit on my setup, because I think I was a bit vague.
Basically, I had this script called start_rails.sh
#!/bin/bash
cd /rails/app
passenger start
It didn't work, and I tried everything under the sun, including sourcing all of my bash files, and nothing worked. I changed it to:
#!/bin/bash
source "$HOME/.rvm/scripts/rvm"
cd /rails/app
rails s
And now it works. I can run it from an upstart script:
start on started mysql
exec sudo -u ubuntu -i /home/ubuntu/bin/start_rails.sh
However, "passenger start" still doesn't work, never has, and I guess never will =P I still don't know why there's no way to run a shell script and tell it to "run it exactly as if I was typing it in manually" because simply typing "passenger start" does work. From a shell script, it doesn't. Oh well. Life goes on.
If you can run passenger by hand without problems you are in a good position right now :).
I guess there is some problem with environment variables that are set when you log in but not when the script is run. Try to add these two lines at the beginning of your script:
source ~/.bash_profile
source ~/.bashrc
I'm having a weird issue with a start-up script which runs a Sinatra script using the shell's "daemon" function. The problem is that when I run the command at the command line, I get output to STDOUT. If I run the command at the command line exactly as it is in the script -- less the daemon part -- the output is correctly redirected to the output file. However, when the startup script runs it (see below), I get stuff to the STDERR log but not to the STDOUT log.
The relevant lines of the script:
#!/bin/sh
# (which is and has been a symlink to /bin/bash
# Source function library.
. /etc/init.d/functions
# Set Some Variables
RUNAS="joeuser"
PID=/var/run/myapp.pid
LOG="/var/log/myapp/app-out.log"
ERR_LOG="/var/log/myapp/app-err.log"
APPLICATION_COMMAND="RAILS_ENV=production ruby /opt/myapp/lib/daemons/my-sinatra-app.rb -p 8002 2>>${ERR_LOG} >>${LOG} &"
# Snip a bunch. This is the applicable line from the "start" case:
daemon --user $RUNAS --pidfile $PID $APPLICATION_COMMAND &> /dev/null
Now, the funky parts:
The error log is written to correctly via the redirect of STDERR.
If I reverse the order of the >> and the 2>> (I'm grasping at straws, here!), the behavior does not change: I still get STDERR logged correctly and STDOUT is empty.
If the output log doesn't exist, the STDOUT redirect creates the file. But, the file remains 0-length.
This used to work. The log directory is maintained by log-rotate. All of the more-recent 'out' logs are 0-length. The older ones are not. It seems like it stopped working some time in April. The ruby code didn't change at any time near then; neither did the startup script.
We're running three different services in this way. Two of them are ruby daemons (one uses sinatra, one does not) and the other is a background java process. This is occurring for BOTH of the ruby processes but is not happening on the java process. Maybe something changed in Ruby?
FTR, we've got ruby 1.8.5 and RHEL 5.4.
I've done some more probing. The daemon function does a bunch of stuff, but the meat of the matter is that it runs the program using runuser. The command essentially looks like this:
runuser -s /bin/bash - joeuser -c "ulimit -S -c 0 >/dev/null 2>&1 ; RAILS_ENV=production ruby /opt/myapp/lib/daemons/my-sinatra-app.rb -p 8002 '</dev/null' '>>/var/log/myapp/app-out.log' '2>>/var/log/myapp/app-err.log' '&'"
When I run exactly that at the command line (both with and without the single-ticks that got added somewhere along the line), I get the exact same screwy behavior w.r.t. the output log. So, it seems to me that this is an issue of how ruby (?) interacts with runuser?
Too long to put in a comment :-)
change the shebang to add #!/bin/sh -x and verify that everything is expanded according to your expectations. Also, when executing from terminal, your .bashrc file is sourced, when executing from script, it is not; might be something in you're environment that differ. One way to find out is to do env from terminal and from script and diff the output
env > env_terminal
env > env_script
diff env_terminal env_script
Happy hunting...
Specifically calls to gpg.
I'm having a hard time tracking down the problem as the logs don't give any output for these failing calls and they work perfectly from the production console.
I've tried specifying the path to gpg:
system "path/to/gpg --all -my --encryption -options
and have made sure that Passenger is running under the same user that I am entering the console as. I've also tried backticking and %x()ing the commands in search of a more verbose response.
No luck. Prayer, dance and violence have proved equally useless.
To help debug issues like this, you could try calling a bash script which handles logging of issues, instead of the command directly:
#!/bin/bash
# my_gpg_script.sh
set -e
set -u
set -x
set -v
path/to/gpg --all -my --encryption -options > /var/log/whats_happening.log
Then call system "my_gpg_script.sh" from ruby.
Lebreeze got me on the right path, but I could never get the STDOUT to redirect to my log and ended up having to debug by tracing the whole method as suggested over here https://serverfault.com/questions/98994/suppress-gpg-reading-passphrase-from-file-descriptor-0-message
strace path/to/gpg --all -my --encryption -options 2>>/var/log/whats_happening.log
It turned out to be a path issue. I had naively thought that $PATH would be the same in the console and application as long as the environment and user were the same. Not the case. Adding some extra paths in my httpd.conf file fixed me up though.
SetEnv PATH /this/bin:/that/other/bin:/and/dont/foget/bin
In my app, a user can run a script, and if it is run in the terminal, it shows a nice progress bar, how would I replicate this in rails? I mean I could do like something between the two to communicate, but I would prefer if it would just show a "live" shell output.
Thanks :)
If your script is invoked with 2>&1 at the end, backticks invocation will return STDOUT & STDERR.
result = ‘ls 2>&1‘