AWS Thinkbox Discussion Forums

Cannot get Nuke to write logs on Deadline

Hi, we are having problems with Nuke writing its logs when running under Deadline.
In order for Nuke to write logs, you have to set up a couple environment variables as described here. You need FOUNDRY_LOG_FILE and FOUNDRY_LOG_LEVEL.

This works fine for a regular user. When setting the env vars manually, Nuke writes its log as we instructed it.

For the slave user to work, we tried two ways of setting the environment variables - setting them manually as system variables, and setting them from the ~JobPreLoad.py~ script using ~deadlinePlugin.SetProcessEnvironmentVariable~ (I guess this is the recommended method).

Neither method could make Nuke write to the log file, however. Have you seen this working before?

Hello!

JobPreLoad.py should work. Did you add some printing lines to make sure it is working correctly? These should be printed to the job report or slave log.

Another test would be to right click the job and add the env var under Environment.

Regards,

Charles

Thank you for the response.
Hm, that’s weird, even setting variables under the Environment tab (didn’t know it existed) did not work…

I requeued the job, is this supposed to take the new env vars into account?

The requeue should use the new variables.

Are you wrapping nuke in a script or using the ‘run as user’ feature?

If you’re setting the variables at a system-level, that should always work assuming they can be accessed when the user logs onto to the machine (on Linux this can be a little tricky, especially when running as a service). Considering it’s clearing it in all cases, I’m hoping it’s just the ‘run as user’ caveats at play here.

Nope, not using ‘run as user’. The slaves supposedly run as svc_deadline.

I have only printed from the JobPreLoad script so far, now going to print the environment from inside the plugin and verify.

Verified inside Nuke that the environment variables are set.

Now wondering how it could work with a normal user, and not with svc_deadline via the service… couldn’t be a permissions issue, since it is svc_deadline’s %LOCALAPPDATA%… right?
Also I’m a bit confused on Windows whether to use Windows paths or UNIX.

Now I realize that it worked when I started the slave as my own user - the logs were generated. But not from the service. Any ideas?

I usually troubleshoot these sort of environment issues by enabling the “Command Line” plugin and throwing “cmd.exe” in as the executable and “/C set” in as the arguments (for Windows nodes). That’ll dump the entire environment (or you could do it in Nuke).

Are there any errors from Nuke at all? It still feels like environment somehow… but does this user have their home directory mounted remotely? I’d stick with the Windows paths here. What are you setting FOUNDRY_LOG_FILE to?

Well from within Nuke (inside a custom init.py that I am using) I print out the two environment variables, and they are correctly set.
FOUNDRY_LOG_FILE=c:\Users\svc_deadline\AppData\Local\Temp\nuke\nuke.log
As I said, it worked for a regular user, and also when the slave is started by a regular user, you can set the log location to %LOCALAPPDATA%\Temp\nuke\nuke.log which is a bit nicer.

Something in the logging tied to UI operations? Since services don’t have that and regular users or slaves started on normal desktop mode do.

Don’t think so… it’s mostly environment stuff, and shotgun-related info. But it all prints fine in the Slave log, just not to the specified file.
Maybe I should try removing the Shotgun info logging.

Hmm… what you said there just got me thinking bout it.

Yeah, this isn’t making much sense to me. Usually running as a service isn’t going to make much of a difference with local file paths in my experience. Especially if the service and the desktop were running as the same account.

I’m pretty stumped on this one… Logon scripts wouldn’t affect environment or file permissions, and I’m assuming there’s no errors in the log.

Not sure what you mean, but I run the desktop as my personal user, and I start the service from it. But still the service would be using svc_deadline, right? With its own permissions? (Windows noob here)

On Windows, the service user will always be used regardless of who started it.

When testing outside of the service (as a regular user as you mentioned in your original post) that is going to be a different situation.

This is getting a little complicated. Would you be willing to have a remote session? We can work out the details in a private conversation.

Privacy | Site terms | Cookie preferences