OpenCue icon indicating copy to clipboard operation
OpenCue copied to clipboard

lluTime gets set to zero due to permissions mismatch on frame logfile

Open donalm opened this issue 3 years ago • 0 comments

If so configured, RQD will run a frame with the permissions of the submitting user. https://github.com/AcademySoftwareFoundation/OpenCue/blob/master/rqd/rqd/rqcore.py#L472

With these elevated permissions, it creates the frame's log file: https://github.com/AcademySoftwareFoundation/OpenCue/blob/master/rqd/rqd/rqcore.py#L523

Later, to determine the lluTime for the frame, RQD checks the mtime of the log file, but it does not elevate its permissions to those of the user before doing so: https://github.com/AcademySoftwareFoundation/OpenCue/blob/master/rqd/rqd/rqmachine.py#L376

If the RQD daemon does not have read permissions on the enclosing folder, the call to os.path.exists will return False, the operation will silently fail, and the frame.lluTime value will remain at its default of zero.

This value is eventually converted to a date/time value and populates the ts_llu field in my database's frame table as 1970-01-01 01:00:00+01

In theory, this should not result in frames being killed by the llu timeout feature, because the Java code (correctly, I think) checks for nonzero timeout_llu values:

            } else if (layer.timeout_llu != 0 && report.getFrame().getLluTime() != 0
                        && lastUpdate > (layer.timeout_llu -1)) {
                newState = FrameState.DEAD;

But I'm not sure that's working correctly. I encountered all this while I was investigating a problem with render tasks being killed by cuebot for no obvious reason.

Thanks all.

donalm avatar Aug 17 '22 17:08 donalm