About start_command

daemonize false

---

example:

working_dir "/project1/"
pid_file "thin.pid"
start_command "bundle exec thin start -R thin.ru -p 33233 -d -l thin.log -P thin.pid"

Here thin daemonized by itself and store pid to thin.pid (by option -P thin.pid). As start_command executed in the working dir, so thin self-daemonization store pid in /project1/thin.pid. Then to the eye saw it, we specify pid_file "thin.pid", which expanded_with the working_dir, so eye expect file /project1/thin.pid, which should contain target process pid.

in daemonize false, start_command can contains any shell sequence, example: start_command "/bin/sh -c '/bin/sh some.sh && thin start -P thin.pid'"

for daemonize true

---

example:

working_dir "/project1/"
pid_file "em.pid"
start_command "ruby em.rb"
stdall "em.log"
daemonize true

Here eye daemonizing command ruby em.rb and store it pid to /project1/em.pid, and redirect all stdout, stderr to the /project1/em.log. Very simple.

start_command should be atomic

Not allowing shell sequences or something.

Bad examples:

pid_file "em.pid"
start_command "/usr/bin/env BLA=1 ruby em.rb"
daemonize true

or

start_command "sh -c 'cat somefile | ruby em.rb'"

or you have shell script some.sh

sh something.sh
export BLA=1
ruby em.rb

and

pid_file "em.pid"
start_command "sh some.sh"
daemonize true

All this examples is wrong, because when using sequence of commands or 'sh -c' it produces tree of processes: two processes: some.sh -> ruby em.rb, and eye would monitor only some.sh, and check it memory, and kill only it. and ruby em.rb remains alive after that.

use_leaf_child true

There is experimental option use_leaf_child true for that case. When you daemonizing tree of processes it would find last process pid.

pid_file "em.pid"
start_command "sh some.sh"
daemonize true
use_leaf_child true

proceduce sh some.sh -> ruby em.rb, with use_leaf_child true, eye would monitor ruby em.rb, check it memory, and send kill to it. (after kill ruby em.rb, sh some.sh die by itself)