Where is documentation

[fade2black]

I think the project should be documented. A lot of examples but there is no a single line of explanation, or documentation. What does this gem solve? What is logic behind the design? A lot of examples, but not clear what they do and why. For example: what is stop_on_delete what delete? Why stop? What is stdall? What does it do? and so on...

[grimm26]

https://github.com/kostya/eye/wiki

[fade2black]

@grimm26 can you show me in Wiki where stdall is explained or what stop_on_delete does NOT HOW TO USE! Or can you show me the place in Wiki where the difference between daemonize and daemonize! and what is purpose of daemonize? What does it daemonize? What does start_command do? What does process do? Does it have arguments? What arguments?...

Sorry, I am too picky to make assumptions from function names.

[kostya]

yes there is almost no documentation, this is quite bad. For now this project for experienced user, most of options and actions just similar to god, bluepill, monit, ... (or just intuitive to understand when you know why you need eye).

stdall just alias for stdout, and stderr together.

about top_on_delete: https://github.com/kostya/eye/wiki/About-stop_on_delete-=-true

daemonize described here: https://github.com/kostya/eye/wiki/About-start_command

[fade2black]

@kostya Well, as for "experienced user", I don't think guessing from source code is what "experienced users" would like to do.

Anyway, I have never used Monit, or God, though I have faced problems such as monitoring processes. They are not so complex, and I usually get away with simple scripts which watch and log. Also, I don't tools like Monit, or God since usually they are buggy and not reliable, especially in production mode., that is, I install Monit and then I should worry about and watch Monit itself ))).

My problem is to watch Resque workers working in background. For some (yet unknown) reasons they disappear after about a day or two. I have also noticed that if I stop redis server by init.d stop then all workers disappear. Then checked redis-server log file. It really restarted several times, but resque workers did not restart automatically. This is just a hypothesis yet.

In any case I need a robust and reliable tool that would automatically watch and restart workers itself. A simple way to check resque workers by hand is ps -e -o pid,command | grep [r]esque and we start them bundle exec rake resque:workers QUEUE='*' COUNT='3' for example. This is why I want to use eye or similar tool.

[kostya]

bundle exec rake resque:workers QUEUE='*' COUNT='3' is command which run multiple background processes, not even stored somewhere pid or something, this is bad command to execute with eye, surely you would lost processes with it.

Eye monitor processes, each separately. Also there is some exceptions when you can monitor superviser process, which fork child processes and kill them by itself (unicorn for example https://github.com/kostya/eye/blob/master/examples/unicorn.eye), but this is quite hard case.

So to simple usage we can do this: If you look how implemented rake resque:workers, it basically call rake rescue:work 3 times. This process not auto-daemonized (locked), so we need daemonize = true for it. Then you can write config like this (this is just fast writed example, maybe need some tune, i not tried to run it, but sure it should work, and you would not lost processes):

def resque_worker(proxy, id, count, queue)
  name = "resque-#{id}-#{count}"
  proxy.process(name) do
    env "QUEUE" => queue
    daemonize true
    pid_file "tmp/#{name}.pid"
    start_command 'rake rescue:work'
    stdall "log/#{name}.log"
  end
end

Eye.app :resque do
  working_dir "/my/app/"
  3.times do |i|
     resque_worker(self, i, 3, "*")
  end
end

i think this config describes itself, no need to describe each line

[fade2black]

@kostya Thanks for the script

command which run multiple background processes, not even stored somewhere pid or something

As I mention in previous post, I run them in background. This is the two lines which I have to enter every time workers die: cd /path/to/my/rails-app (RAILS_ENV=production PIDFILE=./resque.pid BACKGROUND=yes bundle exec rake resque:workers QUEUE='*' COUNT='9') 2>&1 | tee -a log/resque.log

As a result it creates 9 processes which we can check by entering ps -e -o pid,command | grep [r]esque

18842 resque-1.27.4: Waiting for my_queue1,my_queue2
18844 resque-1.27.4: Waiting for my_queue1,my_queue2
18857 resque-1.27.4: Waiting for my_queue1,my_queue2
18860 resque-1.27.4: Waiting for my_queue1,my_queue2
18875 resque-1.27.4: Waiting for my_queue1,my_queue2
18885 resque-1.27.4: Waiting for my_queue1,my_queue2
18897 resque-1.27.4: Waiting for my_queue1,my_queue2
18908 resque-1.27.4: Waiting for my_queue1,my_queue2
18913 resque-1.27.4: Waiting for my_queue1,my_queue2

I am not quite sure if it is possible to use eye in this situation, and how.

[kostya]

if you want monitor processes which eye not started, you should store pid_file for each process, and set to eye processes pid_file, but i doubt why you need this, why you not want to use what i write?

may be you misunderstood what eye is? it is not just monitor tool, is also superviser, so preferable it should start every process which it monitor.

[fade2black]

@kostya Thank you for your feedback. I will certainly install the gem and try out. One more question concerning start_command. I will have to put my eye related scripts outside of my rails application, say, in /path/to/monitor and start_command 'bundle exec rake resque:workers QUEUE='*'. So, I need to run it in context of my Rails application Gemfile, that is, I need to run workers from /path/to/rails-app, and so I need to cd /path/to/rails-app. But in your Wiki page you say that for start_command true you are not "allowing shell sequences or something". Any way out?

[kostya]

start_command executed in working_dir "/my/app/", also pid_file, stdall also expanded by working_dir.