Re: Nimby and LockAllCores

Cam Wright

Hi Brian.

I've created this issue in Github now.

I'll take a look at the Python API as a workaround, as that might just
do what I want.



Cam Wright

On Fri, Aug 23, 2019 at 7:49 AM Cam Wright via Lists.Aswf.Io
<> wrote:

Thanks Brian.
Yep - can do.

I hadn't considered the python API, so I'll have a look into that too.



On Fri., 23 Aug. 2019, 06:53 Brian Cipriano via Lists.Aswf.Io, <> wrote:

Yeah, sounds like there may be a few different bugs you're hitting there -- could you file an issue for that?

We've taken a look into the cuerqd, which hasn't received much attention recently, and come to the conclusion that it needs a little bit of cleanup -- there's some functionality there that isn't quite working right.

In the meantime you might want to look into using the python API (i.e. the `opencue` module) to make these calls.

- brian

On Wed, Aug 21, 2019 at 10:05 PM Cam Wright <cam.wright@...> wrote:

Thanks Brian.


$ cuerqd $HOSTNAME --lh

..successfully locked the cores, in that rqd let the current
dispatched frames finish and no more were dispatched, but then running
the '--ulh' flag didn't undo that, and I needed to restart the rqd
service before more frames would get dispatched again.

So that's somewhat workable, but not perfect.

I guess what I'm really trying to achieve is a process where an artist
can arrive in the morning, run a command to kill all dispatched frames
on their workstation immediately (regardless of their progress) and
then run another script when they leave (or we can automate it based
on X-session idle time) that will reopen those cores for business to
give us extra grunt overnight.

I suppose in the meantime I could hack together a 'systemctl stop rqd'
to kill all running frames, and then a 'systemctl start rqd' to bring
it back online.. but then Cuebot assumes the system is offline, which
isn't perfect but might be feasible... I was hoping there'd be a nicer
solution though.


Cam Wright

On Thu, Aug 22, 2019 at 5:29 AM Brian Cipriano via Lists.Aswf.Io
<> wrote:

Thanks Cam. Sounds like you've found a bug here, and your diagnosis sounds accurate -- RQD using "localhost" as a default is likely causing problems due to mismatch with the name reported to Cuebot.

Let us know if that fixes it for you!

- brian

On Tue, Aug 20, 2019 at 5:52 PM Cam Wright <cam.wright@...> wrote:

So.. it seems in my haste last night I didn't RTFM and completely missed the hostname arg to cuerqd... so that might have just solved my problem.

Join to automatically receive all group messages.