feature request: never ending wait_for_condition

[tetherit]

The code I'm using now is:

  trigger :transition, to: :starting, do: -> {
    month = 60 * 60 * 24 * 28
    process.wait_for_condition(month, 15) do
      info "Waiting for camera #{url} to be up"
      timeout = 5 * 1_000_000 # 5 seconds in microseconds
      system("ffmpeg -loglevel warning -y -stimeout #{timeout} " \
        "-i #{url} -c:v copy -an -vframes 1 -f rawvideo /dev/null")
    end
  }

But even after a month, I want to be able to wait_for_condition endlessly. If the camera is offline, there is no reason to ever start the proxy server process, the condition just needs to be retried every 15 seconds until the camera shows up on the network (if ever).

How would I make wait_for_condition never time out? - What is the rational for the wait_for_condition to time out? - in other words, under what circumstances is it useful to time out and ignore a condition? (why have a condition in the first place if it will be ignored after a while?)

[kostya]

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

[tetherit]

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?

[kostya]

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;

[tetherit]

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?

[tetherit]

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?

[kostya]

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.

[kostya]

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

[tetherit]

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.