How I can run Yard server on production server? - ruby-on-rails

How I can run Yard server on production server?
Maybe use some task?
Load from capistrano, using passenger and nginx, Jenkins(Hudson).

I found the simplest option to be just symlinking the generated docs folder from /public in my rails app. You just need to be sure that the js/css resources are accessible via the same path.
For example:
$ cd <railsapp>
$ ls
Gemfile
app/
..
public/
doc/ <- Folder that contains the html files generated by yard
$ cd public/
$ ln -s ../doc/ docs
This would serve your docs at /docs/index.html
The javascript based search for classes/methods/files still works as it is javascript based. However the search that appears on the top won't appear in this method. However I found the javascript based search sufficient.

I use nginx and passenger, serving this tiny web app:
# ~/Documentation/config.ru
require 'rubygems'
require 'yard'
libraries = {}
gems = Gem.source_index.find_name('').each do |spec|
libraries[spec.name] ||= []
libraries[spec.name] << YARD::Server::LibraryVersion.new(spec.name, spec.version.to_s, nil, :gem)
end
run YARD::Server::RackAdapter.new libraries
Nginx virtual host:
# /opt/nginx/config/sites-enabled/gems.doc
server {
listen 80;
server_name gems.doc;
root /Users/your-user/Documentation/yard/public;
rails_env development;
passenger_enabled on;
}
More in this post: http://makarius.me/offline-rails-ruby-jquery-and-gems-docs-with

I'm use this shell script:
#!/bin/sh
#or you process here
PROCESS='ruby */yard server'
PID=`pidof $PROCESS`
start() {
yard server &
}
stop() {
if [ "$PID" ];then
kill -KILL $PID
echo 'yard is stopped'
fi
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo Usage: $0 [start|stop|restart]
;;
esac
And in Hudson: yard doc && ./yard.sh restart.

Related

Crontab in Amazon Elastic Beanstalk

I am doing a cron tab in AWS - Elastic Beanstalk with Ruby on Rails 3, but I don't know what is wrong.
I have this code in my .ebextensions/default.config
container_commands:
01remove_old_cron_jobs:
command: "crontab -r || exit 0"
02send_test_email:
command: crontab */2 * * * * rake send_email:test
leader_only: true
I receive this error:
Failed on instance with return code: 1 Output: Error occurred during build: Command 02send_test_email failed .
UPDATE 1
I tried next:
crontab.txt
*/2 * * * * rake send_email:test > /dev/null 2>&1
default.config
02_crontab:
command: "cat .ebextensions/crontab.txt | crontab"
leader_only: true
RESULT: No errors, but it does not work.
UPDATE 2
crontab.sh
crontab -l > /tmp/cronjob
#CRONJOB RULES
echo "*/2 * * * * /usr/bin/wget http://localhost/crontabs/send_test_email > /dev/null 2>&1" >> /tmp/cronjob
#echo "*/2 * * * * rake send_email:test > /dev/null 2>&1" >> /tmp/cronjob
crontab /tmp/cronjob
rm /tmp/cronjob
echo 'Script successful executed, crontab updated.'
default.config
02_crontab:
command: "/bin/bash .ebextensions/crontab.sh"
leader_only: true
RESULT: Works with url, but not with rake task.
Updated for 2018
In order to get this to work on the latest version of Elastic Beanstalk, I added the following to my .ebextensions:
.ebextensions/0005_cron.config
files:
"/etc/cron.d/mycron":
mode: "000644"
owner: root
group: root
content: |
56 11 * * * root . /opt/elasticbeanstalk/support/envvars && cd /var/app/current && /opt/rubies/ruby-2.3.4/bin/bundle exec /opt/rubies/ruby-2.3.4/bin/rake send_email:test >> /var/app/current/log/cron.log 2>&1
commands:
remove_old_cron:
command: "rm -f /etc/cron.d/*.bak"
How I got there:
There are four main issues to confront when trying to cron a rake task in AWS EB:
The first hurdle is making sure all of your EB and Rails environment variables are loaded. I beat my head against the wall a while on this one, but then I discovered this AWS forum post (login may be required). Running . /opt/elasticbeanstalk/support/envvars loads all of your environment variables.
Then we need to make sure we cd into the current app directory using cd /var/app/current.
Next we need to know where to find the bundle and rake executables. They are not installed in the normal bin directories, but are located in a directory specific to your ruby version. To find out where your executables are located, ssh into your EB server (eb ssh) and then type the following:
$ cd /var/app/current
$ which bundle
/opt/rubies/ruby-2.3.4/bin/bundle
$ which rake
/opt/rubies/ruby-2.3.4/bin/rake
You could probably guess the directory based on your ruby version, but the above commands will let you know for sure. Based on the above, your can build your rake command as:
/opt/rubies/ruby-2.3.4/bin/bundle exec /opt/rubies/ruby-2.3.4/bin/rake send_email:test
NOTE: If you update your ruby version, you will likely need to update your cron config as well. This is a little brittle. I'd recommend making a note in your README on this. Trust me, six months from now, you will forget.
The fourth thing to consider is logging. I'd recommend logging to the same location as your other rails logs. We do this by tacking on >> /var/app/current/log/cron.log 2>&1 to the end of our command string.
Putting all of this together leads to a cron command string of:
. /opt/elasticbeanstalk/support/envvars && cd /var/app/current && /opt/rubies/ruby-2.3.4/bin/bundle exec /opt/rubies/ruby-2.3.4/bin/rake send_email:test >> /var/app/current/log/cron.log 2>&1
Finally, I referenced the latest AWS documentation to build an .ebextensions config file for my cron command. The result was the .ebextensions/0005_cron.config file displayed at the top of this answer.
I am having the same issue. Though I figured out that the reason that rake task doesn't run correctly on eb is because of RACK_ENV, RAILS_ENV and BUNDLE_WITHOUT
Defaults of eb:
RACK_ENV: production
RAILS_ENV: production
BUNDLE_WITHOUT: test:development
When the cron runs rake task, it runs in development mode, and gives gem not found error, as gems grouped in development are not installed.
you can see this by changing your cron a bitfrom:
*/2 * * * * rake send_email:test > /dev/null 2>&1
to:
*/2 * * * * cd /var/app/current/ && /usr/bin/bundle exec /usr/bin/rake send_email:test > /tmp/cron_log 2>&1
and then checking the /tmp/cron_log file
To know the location of bundle and rake, run
which bundle
which rake
I tried setting RAILS_ENV in command in cron, but that didn't work aswell
One quick fix is to set
BUNDLE_WITHOUT to null
EDIT:
Finally I got it to work,
.ebextensions/.config
files:
"/tmp/cron_jobs" :
mode: "000777"
content: |
1 10 * * * cd /var/app/current/ && RACK_ENV=production rake some:task >> /var/app/current/log/cron_log 2>&1
encoding: plain
container_commands:
01_delete_cron_jobs:
command: "crontab -r -u webapp || exit 0"
02_add_cron_jobs:
command: "crontab /tmp/cron_jobs -u webapp"
leader_only: true
option_settings:
- option_name: RAILS_ENV
value: production
- option_name: RACK_ENV
value: production
Notice the '-u webapp' when removing and adding cron, this will run this cron under user webapp. The above will also run in production mode. And the output will be dumped in log/cron_log file.
If the above wont work then adding 'Bundle exec' before 'rake some:task' might work.
I've seen these used with separate files in .ebextensions, such as:
02send_test_email:
command: "cat .ebextensions/crontab | crontab"
leader_only: true
I haven't gotten around to it yet, but I took note of this along the way. Let us know if this works.
This stackoverflow post has much more information
After Update 1/2:
Cron doesn't know where rake is. Your application runs from /var/app/current, and you need to be running bundle exec rake from that directory.
Elastic beanstalk is horrible with logging errors, to get this right, ssh to the machine and experiment until you have the commands right, then put this back into your cron script. You can even try and re-run some of the eb scripts as found in the logs, then reverse that into your ebextensions files.

Installing more than one version of Erlang/OTP on a machine

Is this possible to have different versions of Erlang/OTP installed simultaneously on the same platform?
I use Kerl to install Erlang on my machines. Quite easy to use, and allows to have several Erlang systems installed on same machine. You can then easily choose the one you want to use.
It is no only possible, but also very frequent. On my machine I have one version that I installed for development (R13B03) it is the default version when I launch erl.
A second copy of the same version associated with nitrogen. this copy is used when I start my nitrogen website. The version will not change when I will use the R16B.. for development
A partial older version which came with the installation of Wings3D.
Yes, I usually install different versions in my home directory. I build them from source:
./configure --prefix=$HOME/r15b01
make && make install
Then I can choose a version to use with PATH=$HOME/r15b01/bin:$PATH, and compile and run things as usual.
These days I use asdf for this. Install asdf and add the relevant line to your .bashrc, and then run:
asdf plugin add erlang
asdf install erlang 22.3.3
asdf install erlang 23.0.2
Then you can set one of the Erlang versions you just built as the default version:
asdf global erlang 23.0.2
Or you can set it to be used in the current directory and its subdirectories - this will create a .tool-versions file in the current directory:
asdf local erlang 22.3.3
On a Mac, Macport helps switching, even between versions it covers and newer ones.
E.g. with Erlang 17 installed directly from Erlang Solutions, you could switch back to RB1603 (open a new terminal window afterwards):
sudo port activate erlang #R16B03-1_0+hipe+ssl
Switch back to Erlang 17 by _de_activating the Macports install (and open a new terminal window afterwards):
sudo port deactivate erlang #R16B03-1_0+hipe+ssl
List all versions you have installed with:
port installed erlang
Using the Nix package manager there is no need to globally install interpreters (especially because sometimes multiple versions are needed), and nix-shell will open up a sub-shell with the Erlang executable available in the path.
1. Getting only the Erlang (no shell.nix)
For the current version in the active channel:
nix-shell -p erlang
For other versions not in the current channel, a specific channel can be given:
nix-shell -I nixpkgs=channel:nixos-unstable -p erlangR22
Or add path to the Nix expression in your NixOS/nixpkgs clone:
$ nix-shell -I nixpkgs=~/clones/nixpkgs -p erlangR23
2. More elaborate project setup configurations: use a shell.nix file
A complex development environment can be spun up, and calling nix-shell shell.nix will take care of all - even automatically when entering a directory if set up with direnv(archived).
2.1 Examples
Erlang
This will drop you in a shell with erl and rebar3 available, along with the other programs specified in buildInputs.
{ pkgs ? import ~/clones/nixpkgs {} }:
pkgs.mkShell {
buildInputs = with pkgs; [
beam.packages.erlangR22.erlang
beam.packages.erlangR22.rebar3
curl
ffmpeg
git
google-cloud-sdk
jq
];
# Where would be the best place for this?
shellHook = ''
export ERL_AFLAGS="-kernel shell_history enabled"
'';
Elixir/Phoenix web project
This (archived) will set up an environment for an Elixir/Phoenix web app complete with a spun up PostgreSQL dev instance:
####################################################################
# Importing a cloned Nixpkgs repo (from my home directory), because
# the latest channels don't have Elixir 1.9.
# See https://nixos.org/nix/manual/#idm140737317975776 for the meaning
# of `<nixpkgs>` and `~` in Nix expressions (towards the end of that
# section).
####################################################################
{ pkgs ? import ~/clones/nixpkgs {} }:
pkgs.mkShell {
buildInputs = with pkgs; [
beam.packages.erlangR22.elixir_1_9
postgresql_11
nodejs-12_x
git
inotify-tools
];
shellHook = ''
####################################################################
# Create a diretory for the generated artifacts
####################################################################
mkdir .nix-shell
export NIX_SHELL_DIR=$PWD/.nix-shell
####################################################################
# Put the PostgreSQL databases in the project diretory.
####################################################################
export PGDATA=$NIX_SHELL_DIR/db
####################################################################
# Put any Mix-related data in the project directory
####################################################################
export MIX_HOME="$NIX_SHELL_DIR/.mix"
export MIX_ARCHIVES="$MIX_HOME/archives"
####################################################################
# Clean up after exiting the Nix shell using `trap`.
# ------------------------------------------------------------------
# Idea taken from
# https://unix.stackexchange.com/questions/464106/killing-background-processes-started-in-nix-shell
# and the answer provides a way more sophisticated solution.
#
# The main syntax is `trap ARG SIGNAL` where ARG are the commands to
# be executed when SIGNAL crops up. See `trap --help` for more.
####################################################################
trap \
"
######################################################
# Stop PostgreSQL
######################################################
pg_ctl -D $PGDATA stop
######################################################
# Delete `.nix-shell` directory
# ----------------------------------
# The first step is going back to the project root,
# otherwise `.nix-shell` won't get deleted. At least
# it didn't for me when exiting in a subdirectory.
######################################################
cd $PWD
rm -rf $NIX_SHELL_DIR
" \
EXIT
####################################################################
# If database is not initialized (i.e., $PGDATA directory does not
# exist), then set it up. Seems superfulous given the cleanup step
# above, but handy when one gets to force reboot the iron.
####################################################################
if ! test -d $PGDATA
then
######################################################
# Init PostgreSQL
######################################################
pg_ctl initdb -D $PGDATA
######################################################
# PORT ALREADY IN USE
######################################################
# If another `nix-shell` is running with a PostgreSQL
# instance, the logs will show complaints that the
# default port 5432 is already in use. Edit the line
# below with a different port number, uncomment it,
# and try again.
######################################################
# sed -i "s|^#port.*$|port = 5433|" $PGDATA/postgresql.conf
fi
####################################################################
# Start PostgreSQL
# ==================================================================
# Setting all necessary configuration options via `pg_ctl` (which
# is basically a wrapper around `postgres`) instead of editing
# `postgresql.conf` directly with `sed`. See docs:
#
# + https://www.postgresql.org/docs/current/app-pg-ctl.html
# + https://www.postgresql.org/docs/current/app-postgres.html
#
# See more on the caveats at
# https://discourse.nixos.org/t/how-to-configure-postgresql-declaratively-nixos-and-non-nixos/4063/1
# but recapping out of paranoia:
#
# > use `SHOW` commands to check the options because `postgres -C`
# > "_returns values from postgresql.conf_" (which is not changed by
# > supplying the configuration options on the command line) and
# > "_it does not reflect parameters supplied when the cluster was
# > started._"
#
# OPTION SUMMARY
# --------------------------------------------------------------------
#
# + `unix_socket_directories`
#
# > PostgreSQL will attempt to create a pidfile in
# > `/run/postgresql` by default, but it will fail as it
# > doesn't exist. By changing the configuration option
# > below, it will get created in $PGDATA.
#
# + `listen_addresses`
#
# > In tandem with edits in `pg_hba.conf` (see
# > `HOST_COMMON` below), it configures PostgreSQL to
# > allow remote connections (otherwise only `localhost`
# > will get authenticated and the rest of the traffic
# > discarded).
# >
# > NOTE: the edit to `pga_hba.conf` needs to come
# > **before** `pg_ctl start` (or the service
# > needs to be restarted otherwise), because then
# > the changes are not being reloaded.
# >
# > More info on setting up and troubleshooting remote
# > PosgreSQL connections (these are all mirrors of the
# > same text; again, paranoia):
# >
# > + https://stackoverflow.com/questions/24504680/connect-to-postgres-server-on-google-compute-engine
# > + https://stackoverflow.com/questions/47794979/connecting-to-postgres-server-on-google-compute-engine
# > + https://medium.com/scientific-breakthrough-of-the-afternoon/configure-postgresql-to-allow-remote-connections-af5a1a392a38
# > + https://gist.github.com/toraritte/f8c7fe001365c50294adfe8509080201#file-configure-postgres-to-allow-remote-connection-md
HOST_COMMON="host\s\+all\s\+all"
sed -i "s|^$HOST_COMMON.*127.*$|host all all 0.0.0.0/0 trust|" $PGDATA/pg_hba.conf
sed -i "s|^$HOST_COMMON.*::1.*$|host all all ::/0 trust|" $PGDATA/pg_hba.conf
# + `log*`
#
# > Setting up basic logging, to see remote connections
# > for example.
# >
# > See the docs for more:
# > https://www.postgresql.org/docs/current/runtime-config-logging.html
pg_ctl \
-D $PGDATA \
-l $PGDATA/postgres.log \
-o "-c unix_socket_directories='$PGDATA'" \
-o "-c listen_addresses='*'" \
-o "-c log_destination='stderr'" \
-o "-c logging_collector=on" \
-o "-c log_directory='log'" \
-o "-c log_filename='postgresql-%Y-%m-%d_%H%M%S.log'" \
-o "-c log_min_messages=info" \
-o "-c log_min_error_statement=info" \
-o "-c log_connections=on" \
start
####################################################################
# Install Node.js dependencies if not done yet.
####################################################################
if test -d "$PWD/assets/" && ! test -d "$PWD/assets/node_modules/"
then
(cd assets && npm install)
fi
####################################################################
# If $MIX_HOME doesn't exist, set it up.
####################################################################
if ! test -d $MIX_HOME
then
######################################################
# ... but first, test whether there is a `_backup`
# directory. Had issues with installing Hex on NixOS,
# and Hex and Phoenix can be copied from there, just
# in case.
######################################################
if test -d "$PWD/_backup"
then
cp -r _backup/.mix .nix-shell/
else
######################################################
# Install Hex and Phoenix via the network
######################################################
yes | mix local.hex
yes | mix archive.install hex phx_new
fi
fi
if test -f "mix.exs"
then
# These are not in the `if` section above, because of
# the `hex` install glitch, it could be that there is
# already a `$MIX_HOME` folder. See 2019-08-05_0553
mix deps.get
######################################################
# `ecto.setup` is defined in `mix.exs` by default when
# Phoenix project is generated via `mix phx.new`.
# It does `ecto.create`, `ecto.migrate`, and run
# `priv/seeds`.
######################################################
mix ecto.setup
fi
'';
####################################################################
# Without this, almost everything fails with locale issues when
# using `nix-shell --pure` (at least on NixOS).
# See
# + https://github.com/NixOS/nix/issues/318#issuecomment-52986702
# + http://lists.linuxfromscratch.org/pipermail/lfs-support/2004-June/023900.html
####################################################################
LOCALE_ARCHIVE = if pkgs.stdenv.isLinux then "${pkgs.glibcLocales}/lib/locale/locale-archive" else "";
}
How to find packages with attributes path on the console
$ nix-env -qaP 'erlang*'
# ...
nixos.erlangR20 erlang-20.3.8.9
nixos.erlangR21 erlang-21.3.8.3
nixos.erlang erlang-22.1.7
# ...
$ nix-env -f ~/clones/nixpkgs/ -qaP 'erlang*'
# ...
nixos.erlangR20 erlang-20.3.8.9
nixos.erlangR21 erlang-21.3.8.3
nixos.erlang erlang-22.1.7
# ...
=== >>> erlangR23 erlang-23.0.2 <<<====
Consider using kerl. It allows you to work with several Erlang installations https://github.com/kerl/kerl

whenever gem: I set :output but the logfile doesn't show up where I'd expect it to

In my schedule.rb file I have the following lines:
set :output, '/log/cron_log.log'
every 5.minutes do
command 'echo "hello"'
end
I ran whenever -w as suggested in this question Rails, using whenever gem in development, and I assume the cronfile is written and running. (I tried restarting the Rails server as well.)
And when I run $ crontab -l I see the following:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /bin/bash
-l -c 'echo "hello" >> /log/cron_log.log 2>&1'
But I can't find the log file. I checked in rails_project/log, ~/log and /log to no avail. On OSX btw.
How can I get the log file to be written to the rails project log folder?
Where is your log?
You're putting the output file at the highest directory level:
$ cd /log
To see if the file exists and if it has data in it:
$ ls -la cron_log.log
To create the log file if needed:
$ touch cron_log.log
To open up permissions for your own local debugging (do NOT do this in production!)
$ chmod +rw cron_log.log
Is your command running?
To run the command manually to find out if it works as you expect:
$ /bin/bash -l -c 'echo "hello" >> /log/cron_log.log 2>&1'
To improve your security and protect your path, use full paths:
wrong: command 'echo "hello"'
right: command '/bin/echo "hello"'
To find the command full path:
$ which echo
To verify the cron is running as you expect:
$ sudo grep CRON /var/log/syslog
The grep result should have lines that something like this:
Jan 1 12:00:00 example.com CRON[123]: (root) CMD (... your command here ...)
Are you on a Mac?
If you're not seeing output in the syslog, and you're on a Mac, you may want to read about the Mac OSX switching from cron to launchd.
See the cron plist (/System/Library/LaunchDaemons/com.vix.cron.plist) and use a stdout/stderr path to debug cron itself. I don't recall if launchctl unloading and launchctl loading the plist is sufficient, or since it's a system daemon if you'd have to restart entirely. (see where is the cron log file in lion)
How to log relative to Rails?
To put the log relative to a Rails app, omit the leading slash (and typically call it cron.log)
set :output, "log/cron.log"
To put the log in a specific fully-qualified directory:
set :output, '/abc/def/ghi/log/cron.log'
The Whenever wiki has some good examples about redirecting output:
https://github.com/javan/whenever/wiki/Output-redirection-aka-logging-your-cron-jobs
Examples:
every 3.hours do
runner "MyModel.some_process", :output => 'cron.log'
rake "my:rake:task", :output => {:error => 'error.log', :standard => 'cron.log'}
command "/usr/bin/cmd"
end

Keep getting 504 Gateway Time-out after deploying on ec2 using rubber

I used the rubber gem to deploy my application on ec2.
I followed the instructions here: http://ramenlab.wordpress.com/2011/06/24/deploying-your-rails-app-to-aws-ec2-using-rubber/.
The process seems to finish successfully but when I try to use the app I keep getting 504 gateway time-out.
Why is this happening and how do I fix it?
Answer from Matthew Conway (reposted below): https://groups.google.com/forum/?fromgroups#!searchin/rubber-ec2/504/rubber-ec2/AtEoOf-T9M0/zgda0Fo1qeIJ
Note: Even with this code you need to do something like:
> cap deploy:update
> FILTER=app01,app02 cap deploy:restart
> FILTER=app03,app04 cap deploy:restart
I assume this is a rails application? The rails stack is notoriously slow to load up, so this delay in load time is probably what you are seeing. Passenger was supposed to make this better with the zero downtime feature v3, but they seemed to have reneged on that and are only going to be offering it as part of some undefined paid version at some undefined point n the future.
What I do is have multiple app server instances and restart them serially so that I can continue to serve traffic on one, while the others are restarting. Doesn't work with a single instance, but most production setups need multiple instances for redundancy/reliability anyway. This isn't currently part of rubber, but I have it deploy scripts setup for my app and will merge it in at some point - my config looks something like the below.
Matt
rubber-passenger.yml:
roles:
passenger:
rolling_restart_port: "#{passenger_listen_port}"
web_tools:
rolling_restart_port: "#{web_tools_port}"
deploy-apache.rb:
on :load do
rubber.serial_task self, :serial_restart, :roles => [:app, :apache] do
rsudo "service apache2 restart"
end
rubber.serial_task self, :serial_reload, :roles => [:app, :apache] do
# remove file checked by haproxy to take server out of pool, wait some
# secs for haproxy to realize it
maybe_sleep = " && sleep 5" if RUBBER_ENV == 'production'
rsudo "rm -f #{previous_release}/public/httpchk.txt #{current_release}/public/httpchk.txt#{maybe_sleep}"
rsudo "if ! ps ax | grep -v grep | grep -c apache2 &> /dev/null; then service apache2 start; else service apache2 reload; fi"
# Wait for passenger to startup before adding host back into haproxy pool
logger.info "Waiting for passenger to startup"
opts = get_host_options('rolling_restart_port') {|port| port.to_s}
rsudo "while ! curl -s -f http://localhost:$CAPISTRANO:VAR$/ &> /dev/null; do echo .; done", opts
# Touch the file so that haproxy adds this server back into the pool.
rsudo "touch #{current_path}/public/httpchk.txt#{maybe_sleep}"
end
end
after "deploy:restart", "rubber:apache:reload"
desc "Starts the apache web server"
task :start, :roles => :apache do
rsudo "service apache2 start"
opts = get_host_options('rolling_restart_port') {|port| port.to_s}
rsudo "while ! curl -s -f http://localhost:$CAPISTRANO:VAR$/ &> /dev/null; do echo .; done", opts
rsudo "touch #{current_path}/public/httpchk.txt"
end
I got the same error and solved the problem.
It was "haproxy" timeout. It is a load balancer installed by Rubber.
It is set to 30000ms, you should change it in rubber configuration file.
Good luck!

How to start thin for only one application?

In /etc/thin/ I've got several yml files. When I run service thin stop -C /etc/thin/app.yml thin stops all applications, instead of only the one I specified.
How do I get thin to stop/start only the specified application?
UPDATE: Hmm, in /etc/init.d/thin there's this: $DAEMON restart --all $CONFIG_PATH. That explains a lot. Are there smarter init.d scripts? This is my script:
https://gist.github.com/1003131
See also:
Running Rails apps with thin as a service
you have to edit /etc/init.d/thin adding a new action or modifying the "restart" action.
as you can see, --all $CONFIG_PATH sends the command to all thin instances.
paste the init script somewhere, we can find a decent solution ;)
UPDATE:
try to add the following lines, below this:
restart)
$DAEMON restart --all $CONFIG_PATH
;;
restart-single)
$DAEMON restart -C $2
;;
stop-single)
$DAEMON stop -C $2
;;
I didn't tried it, but it should work well. this is a really simple solution (no error checking), we've added 2 new actions that must be called as:
service thin restart-single /etc/thin/your_app.yml
or
service thin stop-single /etc/thin/your_app.yml
let me know if it works ;)
cheers,
A.
I propose another solution (which i think is more thin-convenient):
set the content of your /etc/init.d/thin file to use my fixes:
#!/bin/sh
### BEGIN INIT INFO
# Provides: thin
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: S 0 1 6
# Short-Description: thin initscript
# Description: thin
### END INIT INFO
# Original author: Forrest Robertson
# Do NOT "set -e"
DAEMON=/usr/local/bin/thin
SCRIPT_NAME=/etc/init.d/thin
CONFIG_PATH=/etc/thin
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
if [ "X$2" = X ] || [ "X$3" = X ]; then
INSTANCES="--all $CONFIG_PATH"
else
INSTANCES="-C $3"
fi
case "$1" in
start)
$DAEMON start $INSTANCES
;;
stop)
$DAEMON stop $INSTANCES
;;
restart)
$DAEMON restart $INSTANCES
;;
*)
echo "Usage: $SCRIPT_NAME {start|stop|restart} (-C config_file.yml)" >&2
exit 3
;;
esac
:
Use thin restart -C /etc/thin/my_website.yml. It is possible to use such syntax with start, restart and stop commands. Yet, thin restart (or start or stop, of course) would inflict all the instances registered.
This is weird, I added a patch to the script from the gem itself for the init script for the next build to allow a single restart on future installations
restart-file)
$DAEMON restart -C $2
;;
but the gem owner refused the merge and said you can use thin start - C /path/ which is weird, because I've tried it a lot and the script itself says --all and no single config is allowed,
I've also tried doing what he said and obviously it restarted all since the script uses all, can anyone shed more light to this https://github.com/macournoyer/thin/pull/176

Resources