-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Environment Variable not seen by brenda, but there when I ssh into the instance #32
Comments
The AMI is based on Ubuntu 16.04.2, Blender is version 2.79. |
I think I may have run into this. I have to look at the script again. But I
believe it starts the instance and then runs the script. There may be a
sudo command inside the script that changes the system somehow. Can you
insert a couple pipe out commands at the beginning and end of the blender
script to see the if the variables change?
…On Oct 8, 2017 1:46 PM, "aliasguru" ***@***.***> wrote:
The AMI is based on Ubuntu 16.04.2, Blender is version 2.79.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABIPf9PPmK2erlSjkTYgV5Vsb0bPDdfYks5sqRhrgaJpZM4PxzkS>
.
|
I've modified the brenda source code to inject a few echos and system commands. The script sent to the server now looks like this:
As you can see, I've commented out my own export commands, which allowed me to finally set those vars as I really need them. When I now retrieve the system log from that instance using the AWS console, I see that the commands are executed:
So, at all times, the user which runs the brenda commands is root, and the current location is / (which is odd, I'd have expected it to be /root). There is a symlink error, but that one is caused by myself, I had already created that one on the AMI. The error is harmless. The environment vars however are clearly the minimalistic ones, not the ones ssh gives me. One hope I can see: While digging around, I noticed that the startup script actually looks for a key called STARTUP_PRERUN. I interpret this as someone (presumably James Yonan) giving us a possibility to inject own commands to the script, by placing them into .brenda.conf. That's what I'll try next. If it works, users are not obliged to change source code for defining own AMI vars. |
Tested it right now, works perfectly! Open your .brenda.conf, and add a section like this at the end:
Separate all vars and commands with a semicolon as indicated above. I guess things like this would work as well (but have not tested it):
This would for example re-enable the ability to simply execute |
This is driving me nuts. I've created a custom AMI on AWS to incorporate my own tools / add-ons used with Blender. While configuring the image on AWS, everything works as expected, both as user ubuntu as well as user root. I need to set an environment variable to locate the tools, and I do it like this:
in /etc/environment:
BLENDER_USER_CONFIG=/mypath/dingdong/
BLENDER_USER_SCRIPTS=/mypath/dongding/
I then created the AMI and configured Brenda to use it, which works just fine. With one exception: When Brenda fires off the job, it does not see my custom vars. I ssh into the running instance again, and as before, no matter if I am user ubuntu or root, or even use sudo printenv, all the vars are listed and correct. I can run Blender from the command line in all circumstances, the tools will be loaded. It is only when submitting the job using brenda that the custom dirs are never found.
What can I do? Which key concept do I miss here?
The text was updated successfully, but these errors were encountered: