I have 64-bit Debian Squeeze systems that run an older 32-bit version of SGE execd. When I run uname -m at the command line, I get what I'd expect: x86_64. But when I run uname -m inside an SGE script on the same host, the output is i686. This breaks anything which depends on a correct reading from uname -m.
I can workaround the problem, so my question is more academic than practical. I downloaded the uname source code but I couldn't find where it was pulling machine architecture data from. I assume this problem comes about because uname -m is run by a 32-bit parent process instead of a 64-bit parent process. So my question is - is that assumption correct, and if so, why is uname influenced by the architecture of the process which executes it?
uname -m is used to report the personality(2) of the 'virtual machine' running the code. Because the kernel can run code with different personalities (say, 32-bit code on a 64-bit machine, complete with 'only' a 32-bit address space, or short inodes, different signal numbers, or similar constraints), programs might use the output of uname -m to determine how they should run -- i.e., which kernel interfaces they will get at runtime.
So it is important that uname -m reflect the personality, not the full extent of the hardware.
Perhaps you can insert a call to setarch(8) or personality(2) into your software before the fork(2) exec() of your uname -m command and subsequent helper programs.