Qube5.5 RedHat WS 4 workers: Aliases not working?

[njushchyshyn]

After upgrading to Qube 5.5, it seems that the /etc/profile script on our RH WS 4 machines is not being run. On these machines, we use this profile to define aliases used for our submit scripts ... which are now not working.

As a test, I submitted a cmdline job with only the "alias" command and no results are returned. When I log into the worker via ssh using the qubeproxy account, the alias command returns the normal list of aliases.

1) Can anyone else confirm that cmdline jobs submitted to bash shell on linux is bypassing /etc/profile?

2) Is there any way of getting this working again?

Thanks.

[njushchyshyn]

I seem to be close to something of a work around in that I can change my alias definitions to be shell functions, then run the function definition script as a prefix to the job execution command .... this works for cmdline jobs.

BUT

Nuke(cmdline) jobs are not running in bash, they're in /bin/sh, and there seems to be no UI option to select the shell like in the cmdline submit. How can I specify that Nuke(cmdline) jobs run in bash ??

[Scot Brew]

It is an oversight that the simplecmd interface as used by "Nuke (cmdline)" does not have the shell exposed as the standard cmdline and cmdrange jobtype interfaces do.

A bug will be written up for it and then fixed in a point release (likely 5.5.1).

[Scot Brew]

Workaround (shell parameter):
To add the "shell" option to the "Nuke (cmdline)", add the following line into the simplecmds/nuke_cmdline.py interface script on the client machines.  The SimpleCmds directory can be opened from the QubeGUI under File->Open SimpleCmds directory.

Code: [Select]

    cmdline.add_option( 'shell', 'string',
                       'Explicitly specify Linux/OSX shell to use when executing the command. (default=/bin/sh)',
                       label='Shell (Linux/OSX)', choices=['', '/bin/sh', '/bin/bash', '/bin/csh', '/bin/tcsh'])

In addition, we are looking at exposing that parameter to the QubeGUI in a point release.

[njushchyshyn]

OK ... with a few tweaks (matching the indenting pattern and changing "cmdline" to "cmdjob") the script adjustment does allow us to specify bash. That helps in that we can add an explicit call to our profile.sh bash script that configures the environment for rendering.

Still, it's pretty cumbersome compared to what was working for us prior to 5.5
Before, when the worker initiated a job, it automatically invoked the /etc/profile script on the machine it was running on, automatically configuring the session's environment for rendering. If I log into a system with ssh on the qubeproxy account, this works fine manually ... but the profile script is NOT being invoked by worker sessions anymore, requiring....

1) Explicitly add a source command at the start of any Nuke command line (or any other command line job) definitions in order to invoke our environment setup scripts

2) Convert all our alias definitions into bash function definitions since aliases do not seem to take effect until after the command has completed.
(tried running a command line job with "alias thisdir="pwd"; alias; thisdir;" and the result is that "thisdir" is properly listed in the alias list, but it is not recognized as a command. Same is true during an ssh session, but if the very next command in the ssh session is "thisdir", it works fine)

[shinya]

Hi njushchyshyn,

We've identified the issue, and fixed it in the worker code.
The next point-release (5.5-1) of the worker will definitely include this change.

We can also send you a patched version now.  Can you email us at support <at>
pipelinefx.com, referring this forum thread, so that we may send you the patch
in reply to your email? 

Thanks!

-shinya.

[njushchyshyn]

Thanks! .. email sent
- Nick