feature request: never ending wait_for_condition about eye HOT 8 CLOSED

i think big timeout is bad, and timeout > 100s is anomal. if your process cant start, just crash it. and flapping function retry it after some time. Also, big timeout produce issues like #59

from eye.

It's not about a process can't start - a process shouldn't start, the dependency is not met yet. In this instance a camera is offline. Maybe it was sent off to be repaired and will be back in a week or 2. Once the engineer plugs it back in, I want this wait_for_condition to pick it up and start the process.

I tried to make the timeout shorter, but that did not resolve #59 and then Eye just starts the process despite the condition not being met. Why start a process if a condition is not met? seems counter intuitive?

from eye.

even wait_for_condition is a bad practice.
just write some ruby script:

raise "cant start" unless system("ffmpeg -loglevel warning -y -stimeout #{timeout} " \
        "-i #{url} -c:v copy -an -vframes 1 -f rawvideo /dev/null")
exec "ruby ..."

and run this script with eye.
and set trigger flapping, which would retry it every 1.minute;

from eye.

Flapping means the process crashed, there is no crash or anything unexpected here, it also means needless forks and process clean ups as well as loading another ruby instance. Can a pre_condition be added to eye to handle this?

Like depend_on just patiently waits for the process, which may start a week from now when the camera is plugged in - can something like that be added for adding a custom depend_on that will execute arbitrary code?

from eye.

Also, it gets more severe if there is say network maintenance and 100 cameras go offline for a few hours - forking 100 ruby processes every minute and cleaning up all those dying processes would cause massive load spikes and it just seems silly.

It is quite typical for one or more cameras to be offline for a while and I guess my feature request is a way for Eye to wait patiently for a condition to be met before starting the process in the first place. Does that make sense?

EDIT: I can think of other applications for this, for example, don't start the web app until the database is responding - maybe it is currently rebuilding some indexes or running repairs? -- the database process is running just fine, but there is no response from the database. Or maybe the database process is on another server altogether and you want to ensure that server pings and the database responds before starting your app.

Maybe it could be a pre_condition(30) { arbitrary code here } and that could check the pre condition every 30 seconds before even attempting to start the process. Does that sound reasonable?

from eye.

big timeout is bad, because process cant receive another commands until trigger done. so with infinite timeout you cant send stop to your process. we cant interrupt process in starting state, because we dont know what process doing right now, maybe it up some commands, and we interrupt it in the middle of that.

from eye.

may be your should try monit, which seems works with depends better.

from eye.

What about adding another state before the "starting" state, maybe a "pending" state or a "precondition" state which can be interrupted because this way we do know that the process haven't even attempted to start yet and we know nothing is being interrupted in the middle?

I looked at monit, but I need to dynamically create and destroy hundreds of similar processes when cameras are added and removed and monit seems more suited for a few static processes.

from eye.