We're deploying with cap and using a script that send USR2 to the unicorn process to reload and it usually works but every once in a while it will fail. When that happens looking in the unicorn log reveals that it's looking for a Gemfile in an old release directory that no longer exists.
Exception :
/usr/local/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/definition.rb:14:in `build': /var/www/railsapps/inventory/releases/20111128233407/Gemfile not found (Bundler::GemfileNotFound)
To clarify that's not the current release but an older one that's since been removed.
When it works it does seem to work correctly - ie it does pickup the new code - so I don't think it's somehow stuck referring to the old release.
Any ideas?
In your unicorn.rb add the before_exec block
current_path = "/var/www/html/my project/current"
before_exec do |server|
ENV['BUNDLE_GEMFILE'] = "#{current_path}/Gemfile"
end
Read more about it here http://blog.willj.net/2011/08/02/fixing-the-gemfile-not-found-bundlergemfilenotfound-error/
You should set the BUNDLE_GEMFILE environment variable before you start the server, point it at current/Gemfile.
Related
I'm in some trouble with GitLab CI.
I followed offical guide on:
https://github.com/gitlabhq/gitlab-ci/blob/master/doc/installation.md
Everything was ok, no errors nowhere. I followed Runner-Setup, too.
Anything alright.
But...
When I add a runner to a project and then try to build nothing happens.
It could be that I have not fully understood something or some of my configs are wrong.
I'm absolutely new to GitLab CI, but I like it and I want to learn new stuff.
I would be very very glad if someone could help me in some way.
Thanks!
BIG UPDATE:
Just figured out that:
~/gitlab-runners/gitlab-ci-runner$ bin/runner
Starting a runner process manually solves the problem but if I look at the gitlab-ci-runner in /etc/init.d -> it is running !?!
~/gitlab-runners/gitlab-ci-runner$ sudo /etc/init.d/gitlab-ci-runner start
Number of registered runners in PID file=1
Number of running runners=0
Error! GitLab CI runner(s) (gitlab-ci-runner) appear to be running already! Try stopping them first. Exiting.
~/gitlab-runners/gitlab-ci-runner$ sudo /etc/init.d/gitlab-ci-runner stop
Number of registered runners in PID file=1
Number of running runners=0
WARNING: Numbers of registered runners don't match number of running runners. Will try to stop them all
Registered runners=1
Running runners=0
Trying to stop registered runners...kill: No such process
OK
Trying to kill ghost runners...OK
What's wrong here? I'm out of my power or not seeing the problem?!
Problem solved!
You need to edit some values in /etc/init.d/gitlab-ci-runner script!
APP_ROOT="**PATH_TO**/gitlab-runners/gitlab-ci-runner"
APP_USER="**USER_WITH_DIRRIGHTS!**"
PID_PATH="$APP_ROOT/tmp/pids"
PROCESS_NAME="ruby ./bin/runner"
RUNNERS_PID="$PID_PATH/runners.pid"
RUNNERS_NUM=1 # number of runners to spawn
START_RUNNER="nohup bundle exec ./bin/runner"
Now it works!
In my case tags in the runner were different from tags in the .gitlab-ci.yml. Once I changed them so runner tags include all of the config file tests, tasks began to run.
I am new to webistrano so apologies if this is a trivial matter...
I am using webistrano to deploy php code to several production servers, this is all working great. My problem is that I need to clear HTML cache on my cache servers (varnish cache) after the code update. I can't figure out how to build a recipe that will be executed on the webistrano machine (and will run the relevant shell script that will clear the cache) and not on each of the deployment target machines.
Thanks for the help,
Yariv
Simpliest method is to execute varnishadm tool with proper parameters inside deploy:restart
set :varnish_ban_pattern, "req.url ~ ^/"
set :varnish_terminal_address_port, "127.0.0.1:6082"
set :varnish_varnishadm, "/usr/bin/varnishadm"
task :restart, :roles => :web do
run "#{varnish_varnishadm} -T #{varnish_terminal_address_port} ban \"#{varnish_ban_pattern}\""
end
Thanks for the answer. I actually need to do some more stuf than to only clear the the cache so I will execute a bash script locally as described in below:
How do I execute a Capistrano task locally?
I followed the advice in another post about how to clean up old capistrano releases, however, i've realised that the way I've implemented this has messed up the paths in my application (just on a staging site thankfully!). I am using the code below in my config/deploy/staging.rb script, but it can't be running at the correct point, as after deployment I end up with application failing as it's trying to load classes from earlier releases. If I remove the keep_releases line and the one below, and redeploy, everything works again. Has anyone come across this issue?
set :use_sudo, false
set :keep_releases, 1
after "deploy:update", "deploy:cleanup"
namespace :deploy do
task :symlink_shared do
// run some commands i need
end
end
before "deploy:restart", "deploy:symlink_shared"
So it seems the order wasn't right - I changed keep_releases to 2, removed the line underneath and then changed the last line to the following:
"deploy:update", "deploy:symlink_shared"
after "deploy:restart", "deploy:cleanup"
I'm trying to configure Capistrano so that it works for our server setup. We are deploying symfony projects so i'm also using capifony. I'm still experiencing some problems with permissions.
On our server every project runs as a project user, so every project has it's own user. So i configured use_sudo and set it to true and i configured the admin_runner to be the user of the project. But it still didn't work so i modified the capifony to start using try_sudo in stead of the regular run. Which made it work a little bit better. But i'm a bit confused about what to use in which case. You have try_sudo, sudo and run. But which is needed for which use-case?
When you use run i think it'll always be your local user
try_sudo i think will check if the use_sudo flag is true if so it will use the sudo command if not it will use the local user. If you have admin_runner configured it will sudo to the user configured as admin_runner
sudo will always try to sudo
Now my problem is the deploy:symlink method this is also just a regular run command so it executes as the local user, which gives permission problems when i try to view the website.
So can anyone tell me if my description of the 3 commands is correct? and also does anyone know how the admin_runner and use_sudo is suposed to be used, so that the symlink is also being done correctly (and also all other commands done by capistrano)?
kind regards,
Daan
Apologies for such a tardy answer Daan. Your understanding of Capistrano is correct. Note also that the :use_sudo flag defaults to true.
In Capistrano 2.11.2, you'll find lib/capistrano/configuration/variables.rb:
_cset(:run_method) { fetch(:use_sudo, true) ? :sudo : :run }
and lib/capistrano/recipes/deploy.rb:
def try_sudo(*args)
options = args.last.is_a?(Hash) ? args.pop : {}
command = args.shift
raise ArgumentError, "too many arguments" if args.any?
as = options.fetch(:as, fetch(:admin_runner, nil))
via = fetch(:run_method, :sudo)
if command
invoke_command(command, :via => via, :as => as)
elsif via == :sudo
sudo(:as => as)
else
""
end
end
Perhaps your permissions problem involves your server, running as a normal user, not being able to read the contents of the release directory that your current symlink is pointing to?
I've set up multiple vhosts under apache2 / mod_perl. I used the ErrorLog directive to get a separate error log for each vhost. This only worked as expected when I used Apache2::Log. 'warn' would only log to the regular error log.
So that's all working. Finally. But there's one issue remaining: When I log via $r->log_error, I find that newlines are replaced with \n
Any idea why this happens, and how it can be fixed?
Thanks.
This is not a mod_perl problem, but an Apache one. Apparently there are some security concerns with printing unescaped output to the error logs (I'm not entirely sure why) so you have to explicitly enable this in Apache when building/configuring it using this:
CFLAGS=-DAP_UNSAFE_ERROR_LOG_UNESCAPED ./configure
If you're using an already installed apache, there's not much you can do to change this.
If you have a pre-built install, you can use this line of code to fix the issue but it must be included in every page execution within your vhost, say in a header.php or config.php file.
ini_set('error_log','/var/log/apache2/error.log');
i know this is very old thread, but still coming on top on google results, so just to help all, the following changes in mod_perl.pl did helped me:
comment out below:
BEGIN { *CORE::GLOBAL::warn = \&Apache2::ServerRec::warn; }
the above is for:
Make warnings go to the virtual host's log and not the main server log.
i hope this helps anyone out there like me :)