С дистрибутивом QNX поставляется очень полезная утилита on. Эта утилита разработана специально для QNX, и аналогов, во всяком случае, полных, в других системах не существует. В справочнике команд QNX об утилите on говорится как о своеобразной надстройке над интерпретатором shell. Я бы даже сказал, что это сетевое расширение интерпретатора. В процессе «эволюции» различных ветвей UNIX появилось очень много способов удаленного запуска процессов и обмена данными между ними. Это rsh, rlogin, процедуры RPC, просто telnet/ssh и многое, многое другое. В QNX развитие этой возможности вылилось в разработку и создание своей собственной, отличной от IP, сети. Сеть QNX настолько прозрачна, что наличие механизмов, подобных имеющимся в других UNIX-системах, в ней просто не нужно (хотя все они присутствуют для сохранения совместимости с другими системами): процессы «общаются» друг с другом посредством сообщений микроядра, причем находятся ли эти процессы на одном компьютере или на разных — совершенно не важно.
Какие возможности дает пользователю утилита on?
Вот список самых важных, с моей точки зрения, вещей, которые позволяет делать утилита on:
запускать процессы на удаленном узле QNX сети;
запускать процессы с удаленного узла QNX сети;
запускать процессы с установленным фиксированным уровнем приоритета (от 1 до 63);
запускать процессы на другом терминале (перенаправление ввода/вывода и установка управляющего терминала);
запускать процессы от имени другого пользователя (только при наличии привилегий администратора);
останавливать процесс сразу после запуска для отладочных целей (аналогично команде run в gdb). Это позволяет присоединиться к отлаживаемому процессу отладчиком, и продолжить его выполнение вручную;
Первые два пункта взаимно исключают друг друга, остальные же возможности могут использоваться одновременно. Вот как, например, можно запустить утилиту id на удаленном узле test от имени пользователя dmi с приоритетом 63 на терминале /dev/con4:
# on -f test -p 63 -t /dev/con4 -u dmi id
И действительно, на четвертом терминале узла test мы получим вывод программы id:
id=100(dmi), gid=100(users)
К сожалению, у меня не получилось запустить процесс с помощью on на открытом псевдотерминале (сессии pterm), так как on в ответ всегда сообщал, что устройство занято.
В чем же различие между первым методом запуска (на узле) и вторым (с узла)? Вот что говорит нам use on:
-n node spawn on remote node
-f node spawn from remote node
В обоих случаях выполнение происходит на удаленном узле, но есть два отличия:
при использовании ключа «-n» корневым каталогом остается текущий корневой каталог, в том время как при использовании ключа «-f» корневым каталогом становится корневой каталог удаленного узла. Разумеется, это относиться только к запускаемому процессу и его потомкам;
При задании ключа «-n» программа загружается с локального узла на удаленный и после этого запускается; в случае «-f» программа запускается напрямую с удаленного узла;
Запущенный таким образом процесс использует ресурсы (память и процессор) удаленного узла, но весь ввод/вывод направляется на ту консоль, откуда он был запущен, если не указан параметр «-t», то есть рабочий терминал. Также не стоит забывать, что в случае использования ключа «-n» не изменяется корневой каталог, и все файлы загружаются с файловой системы локального узла, если к файлу не указан полный сетевой путь.
Запуск на удаленном узле применяется обычно для разгрузки процессора или памяти на локальном узле, например, на маломощных машинах с небольшим количеством памяти и слабым процессором. Таким же образом, один компьютер может распределять свои задачи на целой группе машин, образуя своеобразный кластер. Команда on может быть полезна еще и для административных целей: запуска менеджеров ресурсов, демонов, утилит диагностики. Вот пример скрипта, запускающего программу проверки диска на всех видимых узлах QNX сети:
#!/usr/bin/perl
opendir(DIR, «/net») || die «No qnet running\n»;
while(defined($node=readdir(DIR))) {
system( «on -f $node chkfsys /» );
}
Этот скрипт проверит корневые разделы жестких дисков на всех доступных узлах, причем вывод (и ввод) chkfsys будет производиться на консоль, с которой скрипт был запущен.
У on есть еще одна полезная опция — «-d»:
-d detach (nozombie)
При ее использовании on не ждет завершения работы вызываемой программы, а сразу завершает свою работу. Эта опция обычно применяется для запуска менеджеров ресурсов.
Как видно из примеров, утилита on в ряде случаев действительно полезна. Часть ее функций просто незаменима в крупных, распределенных по сети проектах, однако применять ее в «чистом» виде, т.е. вызывая с помощью system() весьма неудобно и непрактично. Давайте рассмотрим программные реализации некоторых полезных свойств этой утилиты.