Replies: 2 comments
|
Love the idea, I think it makes a lot of sense. Some potential other things to think about. This would be able to work in conjunction with the other timeout options? Basically an action total timeout + the last update timeout. That's what I'm getting from the proposal of it being a different item. Maybe just something that's more common in windows applications due to gui vs. terminal executable differences, but should there also be an option to watch a file for updates? ie. a log file, or theoretically even an output artifact/image? The idea being that the process is still performing work, even if we have less visibility into it outside of stdout. That would be more of a |
|
I am rendering with redshiftCmdLine on Linux, my only insight is the log. I have experienced some rare cases where the renderer prints a specific message - "Preparing ray tracing hierarchy for meshes" - and then hangs forever and never proceeds with texture conversion and raytracing. I would love to have a way to define a condition "If you see this particular message in the log and and no new lines are printed to the log after N seconds, requeue the task". A typical good log looks like this I have seen a renderer hanging at the former line for 20+ minutes and never printing the latter, and I had to requeue the Task manually. Automating that case and any similar cases where the log progress dynamics are known would be great. |
Uh oh!
There was an error while loading. Please reload this page.
Many programs produce steady streams of update messages, while having highly variable total completion time. Timeouts for the whole command don't work well in this case, but a timeout for receiving any message at all from the program would reliably detect if it has stalled.
This idea is to add another timeout option to the
<Action>template schema that plays this role. It would be something like:Then a template could do this:
All reactions