Клейменов С.А. Администрирование в информационных системах

Подождите немного. Документ загружается.

Таблица 3.3

Сигналы ОС Unix

Имя сигнала

Номер

сигнала

Действие по

умолчанию

Описание

SIGHUP

Выход

Сигнал об отбое

SIGINT

Выход

Сигнал прерывания

(окончания)

SIGQUIT

Выгрузка

Сигнал выхода

SIGILLSIG

Выгрузка

Недействительная инструкция

TRAP

Выгрузка

Перехват трассировки или

точки останова

SIGABRT

Выгрузка

Аварийное прекращение

процесса

SIGFPE

Выгрузка

Исключительная ситуация с

плавающей точкой

SIGKILL

Выход

Уничтожение процесса

(нельзя прерывать или

проигнорировать)

SIGBUS

Выгрузка

Ошибка системной шины

SIGSEGV

Выгрузка

Нарушение сегментации

SIGSYS

Выгрузка

Неправильный аргумент

системного вызова

SIGPIPE

Выход

Разрушенный канал

SIGALRM

Выход

Сигнал тревоги

SIGTERM

Выход

Завершение программы

SIGUSR1

Выход

Пользовательский сигнал 1

SIGUSR2

Выход

Пользовательский сигнал 2

SIGCHLD

Игнорируется

Изменение статуса дочернего

процесса

SIGPWR

Игнорируется

Сбой питания, перезапуск

SIGWINCH

Игнорируется

Изменение размера окна

SIGURG

Игнорируется

Экстренная ситуация сокета

SIGPOLL

Выход

Появление запроса

SIGSTOP

Остановка

Остановка (сигнал нельзя

прерывать или проигно-

рировать)

SIGTSTP

Остановка

Остановка пользователя,

запрошенная с терминала

SIGCONT

Игнорируется

Возобновление

остановленного процесса

121

• SIGKILL. Сигнал kill нельзя перехватить и он требует от про-

цесса немедленного выхода. Используемые процессом функции

завершения в этом случае не вызываются. Используйте этот сигнал

как последнее средство для уничтожения процесса, не отве-

чающего на сигналы об отбое или прекращении работы. Если ко-

манда kill -9 pid не может завершить процесс, то поможет только

перезагрузка системы;

• SIGSEGV. Сигнал о нарушении сегментации (сигнал 11) по-

является, когда процесс пытается получить доступ к памяти, на-

ходящейся в несуществующей или недоступной для процесса об-

ласти адресного пространства. При получении этого сигнала про-

цесс записывает свой образ из памяти на диск (dumps core —

разгрузка оперативной памяти) и выходит. Этот тип поведения

указывает на ошибку программирования, наиболее вероятно по-

явившуюся вследствие неправильного использования указателей;

• SIGBUS. Реакция выполняющегося процесса на сигнал об

ошибке шины (bus error) очень похожа на реакцию на сигнал о

нарушении сегментации (т. е. запись на диск образа памяти, раз-

грузка оперативной памяти, аварийный отказ). Хотя SIGBUS иног-

да вызван аппаратным отказом, чаще его причиной является раз-

рушение программного стека из-за неправильного доступа к па-

мяти;

• SIGPIPE.Запись данных в конвейер (pipe) не имеет никакого

смысла, если никто не может их прочесть. Процесс записи данных

в канал также подразумевает существование считывающего

процесса. Этот сигнал посылается ядром процессу, проводящему

вывод в конвейер, если тот пытается записать данные в конвейер

после того, как считывающий процесс по каким-то причинам

завершился.

Интерфейс системных вызовов Unix является средством досту-

па выполняемых процессов к функциям ядра. Эти функции вы-

полняют такие действия как ввод-вывод, управление процессами и

взаимодействие между процессами. Программисты осуществляют

системные вызовы так же, как и вызов любой функции из

библиотеки.

Когда процесс выполняет системный вызов, он находится в

режиме ядра и по существу никто не контролирует, когда систем-

ный вызов возвращается и возвратится ли он вообще. Пример это-

го — процесс, требующий ввода пользователем данных и поэтому

выполняющий вызов read() на терминал. Процесс не может вер-

нуться из состояния чтения, пока не существует данных для счи-

тывания. На рис. 3.11 показано, как процесс использует системные

вызовы для считывания данных с периферийного устройства.

IPC (Interprocess Communications — взаимодействие между про-

цессами) — это связующее звено, позволяющее слабосвязанным

процессам в системе синхронизировать их ресурсы и распределять

122

Рис. 3.11. Схемы считывания данных с периферийных устройств

данные, требуемые для выполнения заданий, для которых они

запущены. Процессы могут выполняться независимо, но связаны

каким-то образом (возможно, как часть подсистемы) и часто об-

ращаются к общим данным и обмениваются сообщениями.

Unix обеспечивает богатый выбор инструментария, благодаря

которому можно создавать большие системы и приложения, объе-

диняющие неравноправные процессы, и при этом поддерживать в

системе высокий уровень интеграции. Можно осуществлять вза-

имодействие между процессами различными методами, и систем-

ный администратор Unix должен ознакомиться с этими методами,

чтобы знать, как они применяются в практических ситуациях.

Файлы, вероятно, проще и шире всего используются для связи

между различными процессами в среде Unix. Создание файла

блокировки, который сообщает другим процессам, что устройство

в данный момент используется, — это пример относительно

простого задания для Unix-программы, требующей монопольного

доступа к устройству или ресурсу.

Также обычным делом для процесса является создание вре-

менных файлов, которые содержат данные, которые можно счи-

тывать и подвергать воздействию со стороны других процессов.

Подсистема UUCP (Unix-to-Unix Copy Program) является основ-

ным примером такого типа использования. Процесс uucico создает

файл блокировки для монопольного доступа к устройству

доз-вона, например к модему, когда система соединена с

удаленным узлом во время передачи файла. Программа uucp также

создает

123

временные файлы, хранящие данные и команды, которые будут

читаться и выполняться на удаленной системе после того, как они

скопированы на удаленный узел.

Этот метод работает адекватно для ситуаций, в которых можно

контролировать, как и когда процессы выполняются, или когда

один процесс должен выбрать направление последующего выпол-

нения в зависимости от результатов работы его предшественников.

Но применение этого метода все больше и больше затрудняется

при управлении событиями, происходящими асинхронно, когда

многочисленные процессы должны передавать информацию в

разных направлениях интерактивно. Пересылка данных от одного

процесса к другому посредством обычных файлов не очень эф-

фективна, поскольку считывающий процесс должен регулярно

проверять наличие данных и необходимо также удостовериться в

том, что данные считаны правильно и процесс записи завершен.

Ситуация усложняется, когда обмен данными идет в обоих

направлениях; синхронизация — когда какой процесс должен иметь

доступ к файлу — становится очень сложной. Трудность задачи

растет экспоненциально в зависимости от числа процессов. Еще

один источник проблем возникает, когда процесс, имеющий эк-

склюзивные права на некоторые ресурсы, внезапно прерывается и

оставляет файл блокировки, который запрещает доступ других

процессов к данному ресурсу.

Программы ОС Unix в основном осуществляют вывод данных

таким образом, что эти данные передаются другим программам,

которые сразу начнут с ними работу; при этом не приходится

беспокоиться о запоминании промежуточных результатов во вре-

менных файлах. Конвейер — это тот механизм, который делает

возможным такую передачу данных. Конвейер — это соединитель-

ное звено, используемое для перенаправления данных от одного

процесса к другому по принципу FIFO («первым вошел, первым

вышел»).

Например, можно направить выход одной команды в другую,

использовав символ конвейера «|»:

В этой команде длинный вывод команды Is (каталог /usr/bin

содержит много файлов) посылается к команде more, которая

отображает этот длинный вывод по страницам, помещающимся на

экране. Оболочка ОС Unix распознает символ «|» как конвейер.

Поскольку оболочки Unix являются просто программами, они

используют основополагающие системные вызовы Unix для вы-

полнения удобной команды «|».

Unix поддерживает два типа каналов. Первый, наиболее часто

используемый, создается системным вызовом pipe().3T0T вызов

создает двунаправленный конвейер и возвращает файловые деск-

124

рипторы чтения и записи, к которым затем можно получать доступ,

используя ту же семантику, что и для обычного файла. Не

существует имени файла, который следует открывать, только фай-

ловые дескрипторы, созданные системным вызовом pipe(); это

означает, что только связанные процессы способны сообщаться

через этот тип конвейера.

Именованный конвейер можно использовать подобно конвей-

еру, созданному системным вызовом pipe(), за исключением того,

что он создается системным вызовом mknodQ и доступен через

файловую систему Unix так же, как и обычный файл. Как и в

случае с обычным конвейером, данные считываются и обрабаты-

ваются в порядке поступления, что согласуется с режимом работы

конвейера. После того как данные считаны из именованного

конвейера, они больше не доступны в файле. Кроме того, из со-

ображений производительности, данные, записанные в имено-

ванный конвейер, хранятся только в прямых i-узлах, что устанав-

ливает предельный размер этих файлов. (Обратитесь к разделу «Фай-

ловая система Unix» для более подробной информации об i-узлах.)

Именованный конвейер реализован как кольцевой буфер. Как

показано на рис. 3.12, ядро системы Unix хранит два указателя,

указывающих на текущие позиции считывания и записи. Эти ука-

125

Рис. 3.12. Виды указаний считывания и записи в конвейерах

затели хранятся в файле вместе с данными. Многочисленные не-

связанные процессы могут использовать этот механизм для обмена

данными между собой.

Для взаимодействия процессов ОС Unix, синхронизации, об-

мена данными, совместного использования памяти применяют

System V IPC.

В данное время пакет программ System V IPC широко реализу-

ется различными производителями ОС Unix, и обычно он доступен

даже в BSD-вариантах системы Unix. Система System V IPC

предоставляет процессам методы обмена данными, совместного

использования памяти и синхронизации выполняемых процессов.

Доступ к этим функциям очень похож на управление доступом к

обычным файлам, т. е. права доступа для владельца, группы и всех

остальных пользователей поддерживаются и могут управляться

владельцем процесса.

Механизм сообщений в ОС Unix позволяет многочисленным

процессам посылать и получать форматированные данные с по-

мощью очереди сообщений. Эта очередь хранится в ядре системы

и создается или становится доступной через системный вызов

msgget(). Получив соответствующие права доступа, этот вызов воз-

вращает дескриптор очереди сообщений, вычисленный и назна-

ченный на основании выбранного ключа. Любой процесс, полу-

чающий доступ к данной очереди сообщений, должен иметь со-

ответствующий ключ, который служит идентификатором очереди.

Очередь сообщений поддерживает многочисленные типы со-

общений. Взаимодействующие процессы могут настраивать общую

очередь сообщений, обеспечивая отдельные каналы, основанные

на типах сообщений, посылаемых и получаемых системными вы-

зовами msgsnd() и msgrcvO соответственно. При использовании

этого механизма взаимодействующие процессы достигают высо-

кого уровня интеграции. Например, приложение, включающее в

себя множество различных двоичных выполняемых файлов, может

содержать программы мониторинга и формирования отчетов о

состоянии различных подпроцессов и состоянии приложения в

целом, основываясь на сообщениях, посылаемых соответствую-

щими процессами.

Подход, управляемый событиями, более эффективный и менее

ресурсоемкий, чем подход, в котором управляющая программа

опрашивает различные программные модули для выяснения их

состояния. Мгновенные сообщения, посылаемые через регулярные

промежутки времени программе управления, могут использоваться

для упругого реагирования на сбои. Другими словами,

управляющее приложение может использовать эти сообщения для

перезапуска поврежденного или прерванного процесса. Ресурсы

очереди сообщений являются внешними для использую-

126

щего их процесса и не принадлежат виртуальному адресному про-

странству процесса, т.е. ими можно манипулировать извне при

наличии соответствующих прав доступа.

Вызов msgget() выполняет функции, подобные системному

вызову ореп(), используемому для операций ввода-вывода с фай-

лом. В то же время, в отличие от операций ввода-вывода, где ко-

манду ореп() нужно было вызывать до того, как работать с дан-

ными, команду msgget() можно и не вызывать для того, чтобы

воздействовать на данные очереди, если, конечно, приложение

способно вычислить идентификатор очереди для существующей

очереди сообщений. Вызов msgctl() используется для получения

информации о состоянии процесса и изменения прав доступа в

очереди, а также для удаления очереди из списка очередей ядра.

Как показано далее, команда ipcs используется для получения

информации, относящейся к различным очередям сообщений,

поддерживаемым в данное время системой.

Изучение очереди сообщений:

Приложение может угадать правильный ключ и присоединиться

к совместно используемому ресурсу, такому как очередь сооб-

щений или область памяти; это есть ограничение пакета System V

IPC. To, что программа может анонимно получить доступ к этим

ресурсам, вносит потенциальный риск повреждения или перехвата

данных. Конечно, данная ситуация подразумевает, что процесс

имеет соответствующие права на выполнение этих действий.

Механизм совместного использования памяти обеспечивает

процессу средство для присоединения в назначенный сегмент

памяти, находящийся вне адресного пространства процесса. Этот

внешний сегмент становится частью виртуального адресного про-

странства процесса и после настройки доступен таким же образом,

каким процесс получал доступ к памяти в собственном сегменте

данных. Из памяти можно считывать данные, в память можно

записывать данные, и она имеет структуру, определяемую преоб-

разованием типов.

Ядро кроме сообщений и семафоров поддерживает также таб-

лицу, записи которой указывают на области памяти, выделенные

для совместного использования. До того как процесс присоеди-

нится к области совместно используемой памяти с помощью ко-

манды shmat(), он должен получить дескриптор, возвращаемый

системным вызовом shmget().

Вызов shmdt() выполняет отсоединение процесса от опреде-

ленной области памяти. Как уже объяснялось ранее, после присо-

127

единения процесса к области совместно используемой памяти не

требуется никаких специальных действий для получения к ней

доступа. В то же время, в отличие от обычной памяти, занимающей

часть адресного пространства процесса, область совместно

используемой памяти не освобождается при выходе процесса. Для

удаления этих сегментов необходимо специально вызывать команду

shmctl().

Многие системы управления базами данных и многопользова-

тельские приложения прибегают к совместному использованию

памяти для повышения производительности системы. Это действи-

тельно полезно, когда много процессов должны получать доступ к

часто используемым данным, поскольку это уменьшает количество

доступов к диску и число файловых конфликтов между взаи-

модействующими процессами. Как показано далее, команда ipcs

позволяет получить информацию, относящуюся к любому сегменту

совместно используемой памяти в системе.

Изучение сегментов совместно используемой памяти:

Механизм семафоров широко используется взаимодействую-

щими процессами для синхронизации выполнения процессов и

доступа к совместно используемым ресурсам. В многозадачной сре-

де, такой как Unix, поддерживающей совместный доступ к сис-

темным ресурсам, такая синхронизация очень важна.

Различные события, находящиеся вне сферы воздействия и

контроля выполняемых процессов, негативно влияют на рабочую

среду процесса в критической ситуации. Это может вызвать вне-

шние случайные ошибки, которые впоследствии невозможно от-

следить. Рассмотрим, например, случай присоединения двух про-

цессов к одному совместному сегменту памяти, причем их пове-

дение зависит от значений определенных переменных, хранящихся

в этой области. Рассмотрим следующий фрагмент программы:

Если величина переменной i из предыдущего примера хранится

в совместно используемой памяти, другой параллельный процесс

имеет потенциальную возможность получить к ней доступ и

изменить ее значение. Если это произойдет после проверки *i <

МАХ, но до выполнения основного блока, то результаты могут

оказаться непредсказуемыми. То, что величину переменной i мог

изменить другой процесс, является условием, которое не

128

будет учитываться первым процессом, который продолжит вы-

полнение программы с того места, на котором остановился. Ис-

пользование семафоров для блокировки ресурсов, таких как со-

вместная память, предотвращает появление подобной ситуации,

сигнализируя другим процессам, что ресурс заблокирован и может

находиться в нестабильном состоянии.

Семафоры выполняются в виде массивов, содержащих набор

флагов, которые процесс может анализировать и изменять. Это

позволяет процессу сообщать и получать сообщения о ситуациях,

которые могут повлиять на работу одновременно выполняемых

процессов. Действия семафоров либо выполняются все вместе, либо

не выполняется ни одно путем программного увеличения или

уменьшения величин, которыми оперируют семафоры.

Не стоит опасаться того, что массивы семафоров останутся в

бессодержательном состоянии в результате прерывания процесса.

Конечно, возможна борьба за ресурсы семафора. Рассмотрим слу-

чай, когда процесс А заблокировал семафор 1 и ждет разблоки-

ровки семафора 2. Тем временем процесс В заблокировал семафор

2 и ждет разблокировки семафора 1. Системный вызов semop()

аннулирует подобные состязания, позволяя осуществлять операции

над набором семафоров. Вместе с двумя описанными ранее

механизмами пакета System V IPC доступны системные вызовы

semget() и senmctlQ. Все они получают дескрипторы семафоров и

обеспечивают операции управления над семафорами; в этом они

подобны вызовам сообщений и совместно используемой памяти.

3.3.4. Технологии администрирования в Unix

Администратор Unix должен обеспечивать среду для функцио-

нирования рабочих станций, число которых может увеличиваться.

Способ создания такой среды основывается на выбранной страте-

гии. В данном подразделе описаны стратегии, позволяющие пре-

дотвратить, обнаружить и решить возможные проблемы при со-

здании и обслуживании такой среды.

Путь к решению всех задач администрирования — это плани-

рование.

Прежде чем приступать к инсталляции новой системы, необ-

ходимо детально продумать, как нужно устанавливать, поддер-

живать эту систему и решать возникающие проблемы. Не заплани-

ровав все заранее, можно встать перед необходимостью решать

возникающие вопросы в процессе работы.

Существует выражение: «Все, что может сломаться, обязатель-

но сломается». Оно распространяется и на ОС Unix, и на сеть, и на

приложения. Например, может закончиться лицензия на ПО и

пользователи останутся без права доступа к нужным им данным.

129

Необходимо составить список потенциальных проблем и искать

пути их разрешения, или, по крайней мере, предусмотреть такую

возможность заранее. Необходимо заранее предусмотреть, что

делать в случае аварии, а если она возникнет, то как можно быстро

устранить последствия.

Изменения — одна из самых больших проблем при управлении.

Один из способов контроля за изменениями — записывать все

действия и постоянно обновлять эти записи. При этом необходимо

записывать все изменения, которые проводятся, все специальные

команды, которые при этом используются, и т.д. Все это поможет

проследить, что происходит. Если возникнут проблемы

юридического характера, то системный журнал также поможет в

этом.

Можно использовать записи и для изменения плана. Предпо-

ложим, что план предусматривает те или иные действия в случае

выхода системы из строя. Если запланированные действия по ка-

кой-то причине не увенчались успехом, то придется для решения

проблемы предпринять другие действия. Если описывается проис-

ходящее в системном журнале, то в следующий раз уже можно

знать, что нужно делать, и быстро устранить неисправность.

Обнаружив неисправность, обязательно следует подробно за-

писать причины неисправности, возможные способы ее устране-

ния и способы, позволяющие не допустить возникновения этой

проблемы.

Для того чтобы быть уверенным, что система работает нор-

мально, нужно постоянно наблюдать за ней: следить за использо-

ванием ресурсов, наличием свободного места на диске, контро-

лировать взаимодействие с сетью и проверять содержимое файлов

журналов.

Отслеживая производительность системы, необходимо следить,

чтобы нагрузка на систему не превышала допустимых пределов.

Заметив, что сеть, диски, оперативная память или другие ресурсы

используются очень интенсивно, можно заблаговременно принять

меры и предотвратить нарушение работы системы. Может быть,

будет найден способ распределить нагрузку между другими

системами; если же это невозможно, то следует запланировать

покупку нового оборудования.

Пользователи создают или разрушают систему. На первый взгляд

кажется, что с компьютером взаимодействует система Unix, на

самом деле с компьютером взаимодействует пользователь. По тому,

как администратор работает с пользователями, другими систем-

ными администраторами и руководством, можно определить, как

работают сами системы, или, по крайней мере, как воспринимается

их работа.

Поскольку администратор обеспечивает поддержку системы, на

время, пока все работает нормально, он становится невиди-

130