Блог

У меня есть 64-разрядные системы Debian Squeeze, которые запускают более старую 32-разрядную версию SGE execd. Когда я запускаю uname -m в командной строке, я получаю то, что и ожидал: x86_64 . Но когда я запускаю uname -m внутри скрипта SGE на том же хосте, результат i686 . Это нарушает все, что зависит от правильного чтения из uname -m .

Я могу обойти проблему, поэтому мой вопрос скорее академический, чем практический. Я скачал исходный код uname, но не смог найти, откуда он извлекает данные об архитектуре машины. Я предполагаю, что эта проблема возникает из-за того, что uname -m запускается 32-разрядным родительским процессом вместо 64-разрядного родительского процесса. Итак, мой вопрос — верно ли это предположение, и если да, то почему uname зависит от архитектуры процесса, который его выполняет?

uname -m используется для сообщения о personality(2) «виртуальной машине», выполняющей код. Поскольку ядро может запускать код с разными характеристиками (скажем, 32-разрядный код на 64-разрядной машине, в комплекте с «всего» 32-разрядным адресным пространством или короткими индексами, разными номерами сигналов или аналогичными ограничениями), программы могут использовать выходные данные uname -m , чтобы определить, как они должны выполняться, т. Е. Какие интерфейсы ядра они получат во время выполнения.

Поэтому важно, чтобы они uname -m отражали индивидуальность, а не весь объем аппаратного обеспечения.

Возможно, вы сможете вставить вызов setarch(8) или personality(2) в свое программное обеспечение перед fork(2) exec() вашей uname -m командной и последующих вспомогательных программ.