2

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?

chrishiestand
  • 2,800
  • 1
  • 25
  • 25

1 Answers1

3

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.

sarnold
  • 102,305
  • 22
  • 181
  • 238
  • Thank you. I didn't know that Linux supported "multi-arch" in this way. So SGE must be calling one of these methods for consistency. At least on my system, `linux64` is a convenient shortcut to `setarch(8)` – chrishiestand May 22 '11 at 01:51