4.1. Системная информация
Системная информация может отображаться как в текстовом, так и в графическом режиме. Для текстового режима существуют утилиты sin (System INformation – информация о собственно процессах и ресурсах) и sac (System ACtivity – информация о системной активности на каждом уровне приоритета) [2], а также позаимствованная из среды Unix утилита ps (Process Status), по сути являющаяся подмножеством sin. В графической оболочке Photon роль sin и sac выполняют их «более визуальные» аналоги vsin (Visual sin) и phsac (Photon sac) [5]. Информация по каждому процессу, предоставляемая утилитой sin, включает в себя:
- аргументы, переданные процессу в командной строке при запуске, и его флаги;
- приоритет, дисциплина диспетчеризации и состояние (если процесс блокирован, то тип и причины блокировки);
- корень файловой системы и текущий каталог;
- окружение;
- иерархия, «родственные» отношения («отец» – «сын», и т.п.);
- открытые файлы и используемые описатели файлов;
- идентификаторы процесса (process ID – PID) и сеансы;
- версия и время создания исполняемого модуля, размер областей кода и данных;
- селектор и смещение «магических чисел»;
- таймеры и ассоциируемые с ними действия, время старта и время активности;
- реальный и эффективный идентификатор пользователя и группы;
- текущее значение регистров процессора;
- сведения по обработке сигналов.
Информация (по умолчанию это идентификаторы сессии и процесса, имя процесса, приоритет и дисциплина диспетчеризации, состояние, источник блокировки и размеры областей кода и данных) отображается в несколько колонок с соответствующими заголовками.
Дополнительно утилитой sin предоставляется следующая общая информация по каждому узлу сети:
- аппаратная конфигурация (тип процессора и системной шины, индекс производительности, тип дисплея, объем оперативной памяти);
- разрешение системных таймеров и лимиты системных ресурсов (системные области «кучи» менеджера процессов, максимально допустимое количество процессов, таймеров, сеансов, символьных имен процессов, и т.п.);
- количество лицензированных узлов сети;
- дата, время и источник начальной загрузки;
- распределение серверов символьных имен (name locator) по узлам сети;
- текущий перечень виртуальных каналов.
Благодаря сетевой прозрачности QNX4, всю эту информацию можно получить не только с локальной машины, но и с любого узла сети.
Утилита sac отображает в динамике гистограмму активности системы на заданном узле сети по каждому уровню приоритета. Кроме приоритета, в качестве параметров ей можно задавать период опроса системной активности и постоянную интегрирования для управления сглаживанием.
4.2. Файловая подсистема.
Утилита chkfsys рекурсивно обходит дерево каталогов указанной файловой системы, для каждого файла проверяя его элементы и составляющие его экстенты, и строит в памяти битовую карту использованных блоков. Карта впоследствии сравнивается с существующей (файл /.bitmap), что позволяет обнаружить блоки, помеченные как «занятые», но реально не принадлежащие никаким файлам. Такие блоки можно восстановить, перезаписав битовую карту заново. Если карты на диске и в памяти не идентичны, chkfsys запросит разрешения сделать это. В конце работы chkfsys отображает статистику по проверенным элементам файловой системы.
Утилита df, предусмотренна стандартом POSIX, показывает объем свободного дискового пространства в блоках по 512 байт или килобайтах. При этом утилита df показывает степень использования всего раздела в целом.
4.3. Сетевая подсистема.
К средствам диагностики сетевой подсистемы QNX4 следует причислить утилиты alive, netmap, и netinfo.
Сетевой протокол QNX4 подразумевает жесткую привязку логических идентификаторов машин в сети к физическим (MAC) адресам сетевого оборудования. Отображение физических адресов в логические идентификаторы машин называется картой сети; манипуляции с картой сети, включая ее загрузку и редактирование, производит утилита netmap. В плане диагностики эта утилита может помочь для проверки корректности элементов карты, а также в том случае, если имеются несколько физических сетей, и хотя бы один узел сети коммутирует пакеты между ними (такая возможность для сети QNX4 является встроенной, если машина подключена к нескольким физическим сетям с одинаковым форматом кадра канального уровня – она автоматически становится коммутатором). Утилита netmap может показывать построенную менеджером сети по карте сети таблицу коммутации, в которой значится, через какой коммутатор можно получить доступ в нужную сеть. Это бывает полезно при отладке сетей сложной топологии.
Наряду с отображением карты сети и таблицы коммутации, в утилите netmap предусмотрена возможность просмотра информации о числе передач пакетов на заданный узел и времени последнего сбоя передачи. Эта информация указывается непосредственно в карте сети для каждого перечисленного в ней узла.
Просмотреть текущий список доступных узлов можно утилитой alive.
Самое информативное средство диагностики сетевой подсистемы QNX4 – это утилита netinfo. С помощью утилиты netinfo можно также просматривать сетевую статистику канального уровня, поддерживаемую каждым сетевым драйвером (для различных драйверов и, соответственно, для разных типов сетевых адаптеров, перечень приводимых статистических оценок отличается)
Перечисленные утилиты диагностики в основном относятся к штатному сетевому протоколу QNX4 (FLEET). Для сетей, использующих стек протоколов TCP/IP, основными средствами диагностики в QNX4 являются: ping (эхо-запрос узла IP-сети пакетами ECHO_REQUEST протокола ICMP); if_up (проверка доступности IP-интерфейса); arp (отображение и настройка параметров протокола разрешения адресов ARP); nslookup (опрос службы доменных имен DNS); rpcinfo (отображение информации RPC); showmount (отображение точек монтирования сервера NFS); traceroute (трассировка таблиц маршрутизации IP); netstat (отображение состояния и статистики IP-сети); семейство утилит snmp* (функции протокола управления сетью SNMP).
4.4. Универсальные средства диагностики
Настройка аппаратуры обычно сводится к обнаружению и устранению аппаратных конфликтов и подбору корректных драйверов. В данном аспекте большой интерес представляют утилиты-«ловушки», имена которых заканчиваются на «trap» (nettrap, disktrap) и которые выполняют автоопределение оборудования и рекомендуют соответствующие драйверы. Они занимаются тем, что записывают тестовые последовательности в адресное пространство ввода-вывода, где предположительно могут размещаться регистры внешних устройств, и «слушают» ответную реакцию. Процесс автоопределения базируется на том, что для каждого типа и модели оборудования известно, где расположены его регистры, и как оно должно «отзываться».
«Ловушки» могут сами запускать драйверы, которые сочтут нужными (для этого задается параметр start). Однако злоупотреблять этим не стоит, поскольку, во-первых, «ловушкам» свойственно ошибаться, а во-вторых, запись в адресное пространство ввода-вывода может нарушить работу других устройств. Наиболее корректным решением в данном ключе было бы однократное выполнение автоопределения с последующим явным заданием имен и параметров драйверов в файлах инициализации.
4.5. Выполнение команд на другом узле или устройстве
В QNX Вы можете выполнять команды на другой машине (кроме Вашей собственной), если обе машины находятся в одной сети. Это называется удаленным выполнением. Каждая машина в сети называется узлом. Когда команда вызвана на другом узле, стандартный ввод, стандартный вывод и вывод стандартной ошибки команды отображаются на экране Вашей консоли (или терминале), если Вы явно не переназначите их на другое устройство. Для того, чтобы вызвать команду на другом узле, используйте команду onnode; чтобы переадресовать (или «подключить») стандартные ввод и вывод команды на другое устройство, используйте команду ontty.
Использование onnode
Выполнить команду sin на узле (вывод команды sin отображается на экране вызова, то есть на Вашем собственном экране):
onnode 4 sin
Следующая команда эквивалентна вышеуказанной команде onnode, но использует обозначение //node command:
//4 sin
Загрузить команду sin из /bin узла 2 и выполнить ее на узле 4 (вывод команды sin все еще отображается на экране вызова):
onnode 4 //2/bin/sin
Выполнить команду sin на узле 4 и переадресовать ее выход на коноль 1 узла 2 (потоки входных данных команды sin и выходные ошибки все еще подключаются к экрану вызова):
onnode 4 sin >//2/dev/con1
Использование ontty
Выполнить команду ls, подключив ее вход и выход к консоли_3:
ontty /dev/con3 ls
Комбинирование onnode и ontty
Если Вы объедините onnode с ontty, Вы можете запустить команду на другом узле, а также подключить вход и выход команды к устройству этого узла. Никакие виртуальные каналы не будут подключены к узлу, с которого вызвана команда. Например, следующая команда запускает сервер nameloc на узле 4 и подключает его вход/выход на /dev/con1 узла 4:
onnode 4 ontty //4/dev/con1 nameloc &
Имейте в виду, что даже, если программа выполняется на узле 4 и вход/выход подключен к устройству узла 4, она все еще зависит от вызвавшего ее командного интерпретатора. Например, если эта команда запускалась командным интерпретатором и он впоследствии завершает свою работу, команде устанавливается сигнал SIGHUP (то есть и она будет завершаться). Для того, чтобы полностью отделить команду от запускающего ее командного интерпретатора, Вы должны использовать команду nohup. Например:
onnode 4 ontty //4/dev/con1 nohup nameloc &
ВНИМАНИЕ. Для получения дополнительной информации о вышеуказанных командах смотрите nohup и sh в «Utilities Reference».
Альтернативу использования ontty и onnode смотрите в описании утилиты on также в «Utilities Reference».
4.6. Отображение cистемных сообщений
Каждая утилита QNX формирует системные сообщения. По команде use Вы можете отобразить используемые утилитой сообщения. Например, чтобы отобразить сообщения more, Вы можете ввести:
use more
Если Вы задаете use для команды и команда не может быть выполнена в текущем каталоге или она не содержит записей сообщений, то Вам выдается сообщение об ошибке. Дополнительную информацию о команде use смотрите в «Utilities Reference».