Автор: admin

НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ УКРАИНЫ

«КИЕВСКИЙ ПОЛИТЕХНИЧЕСКИЙ ИНСТИТУТ»

РЕФЕРАТ

на тему:

«ПРОБЛЕМА СОЗДАНИЯ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА»

КИЕВ – 2009

План

Вступление

Базовые положения

Методики и подходы построения систем ИИ

Проблемы создания ИИ

Реализация систем ИИ

Заключение

Список использованных источников

Вступление

В качестве самостоятельного научного направления искусственный интеллект (ИИ) существует уже более четверти века. Мнение общества, относительно специалистов данной области, постепенно менялось от скепсиса до уважения, и понимания перспектив данной области в будущем. В передовых странах, таких как США и Япония, работы в области интеллектуальных систем поддерживаются на всех уровнях – от рядовых граждан, до правительственных органов. Существует вполне обоснованное мнение, что именно исследования в области ИИ будут определять характер нынешнего информационного общества, которое уже фактически пришло на смену индустриальной эпохи, достигшей своей высшей точки расцвета в прошлом веке.

Начиная с 80-х годов прошлого века, произошло становление ИИ как особой научной дисциплины, сформировались её концептуальные модели, накопились специфические методы и приёмы, частично устоялись фундаментальные парадигмы. У специалистов старшего поколения, стоявших у истоков новой области исследований, складывается убеждение, что период бурного, хаотического развития кончился, и теперь наступает эра академических и целенаправленных исследований, рассчитанных на длительный период. [1]

Базовые положения

Слово интеллект (intelligence) происходит от латинского intellectus – ум, рассудок, разум. Соответственно искусственный интеллект (artificial intelligence) – ИИ обычно используется как свойство автоматических систем брать на себя отдельные функции интеллектуального труда человека, например, выбирать и принимать оптимальные решения на основе ранее полученного опыта и рационального анализа внешних воздействий или событий.

Интеллектом обычно называют способность мозга решать поставленные (интеллектуальные) задачи путём приобретения, запоминания и целенаправленного преобразования знаний в процессе обучения и адаптации их (знаний) к разнообразным обстоятельствам. В этом определении под термином «знания» подразумевается не только информация, которая поступает в мозг человека через органы чувств. Информация подобного рода конечно важна, но недостаточна для полноценной интеллектуальной деятельности. Всё дело в том, что окружающие нас объекты обладают свойством не только воздействовать на органы чувств, но и находиться во взаимодействии друг с другом. Для того чтобы осуществлять в окружающей среде интеллектуальную деятельность, или как минимум просто существовать, человеку необходимо иметь систему знаний, модель этого мира. В этой информационной модели окружающей среды реальные объекты, их свойства и взаимоотношения между ними не только отображаются и запоминаются, но и могут мозгом человека (мысленно) «целенаправленно преобразовываться». При этом важен тот момент, что формирование модели внешней среды происходит в процессе обучения, на опыте и адаптации к разнообразным обстоятельствам.

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

Термин «алгоритм» происходит от имени узбекского математика Аль Хо Резми, который еще в 9 веке предложил к использованию простейшие арифметические алгоритмы. В математике и кибернетике класс задач определенного типа считается решенным, если для её решения найден соответствующий алгоритм. На самом деле, нахождение алгоритмов является естественной целью человека при решении разнообразных классов задач. Поиск алгоритма для задач некоторого типа связано со сложными рассуждениями, требующими немалой изобретательности и высокой квалификации. Считается, что подобного рода деятельность требует участия интеллекта человека. Задачи, связанные с поиском алгоритма решения класса задач определенного типа, обычно называют интеллектуальными задачами.

Что же относительно задач, алгоритмы, решения которых уже установлены, то, как отмечает известный учёный в области ИИ М. Минский, – «излишне приписывать им (ИИ) такое мистическое свойство, как интеллектуальность». После того, как алгоритм решения задачи найден, процесс решения задачи становится таким, что его могут в равной степени выполнить как человек, так и вычислительная машина (должным образом запрограммированная), не имеющая ни малейшего представления о сущности самой задачи. Требуется только, чтобы «лицо» (человек или ИИ), решающее поставленную задачу, было способно выполнять те элементарные операции, из которых складывается процесс решения, и, кроме того, чтобы оно («лицо») педантично и аккуратно руководствовалось предложенным алгоритмом. Человек, так же как и ИИ, действует в таких случаях, как говориться, чисто машинально и может успешно решать любую задачу рассматриваемого класса.

Представляется совершенно естественным исключить из класса интеллектуальных такие задачи, для которых существуют стандартные методы решения. Например, такими задачами могут быть чисто вычислительные задачи: решение системы линейных алгебраических уравнений, численное интегрирование дифференциальных уравнений и т. п. Для решения подобного рода задач имеются стандартные алгоритмы, представляющие собой определенную последовательность элементарных операций, которая может быть легко реализована в виде программы для вычислительной машины. В противоположность этому для широкого класса интеллектуальных задач, таких, как распознавание образов, игра в шахматы, доказательство теорем и т. п., – формальное разбиение процесса поиска решения на отдельные элементарные шаги часто оказывается весьма затруднительным, даже если само их решение теоретически несложно.

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

Стоит отметить, что профессия программиста, исходя из приведенного выше, по-сути является одной из самых интеллектуальных, поскольку продуктом деятельности программиста являются программы – алгоритмы в чистом виде. Поэтому, создание даже определенных элементов ИИ по-идее должно значительно повысить производительность его труда.

Деятельность мозга, направленную на решение интеллектуальных задач, называют мышлением, или интеллектуальной деятельностью. Интеллект и мышление связаны с решением таких задач, как доказательство теорем, логический анализ, распознавание ситуаций, планирование поведения, игры, также управление в условиях неопределенности. Характерными чертами интеллекта, проявляющимися в процессе решения задач, являются способность к обучению, обобщению, накоплению опыта (знаний и навыков) и адаптации к изменяющимся условиям в процессе решения задач. Благодаря этим качествам мозг может решать разнообразные задачи, а также легко перестраиваться с решения одной задачи на другую. Таким образом, мозг, наделенный интеллектом, является универсальным средством решения широкого спектра задач (в том числе и неформализованных) для которых нет стандартных, заранее известных методов решения.

Надо учитывать, что существуют и другие, чисто поведенческие (функциональные) определения. Так, согласно А. Н. Колмогорову, любая материальная система, с которой можно достаточно долго обсуждать проблемы науки, литературы или искусства, обладает интеллектом.

Другим примером поведенческой трактовки интеллекта может служить известное определение А. Тьюринга. Например, в разных комнатах находится люди и машина. Они не могут видеть друг друга, но имеют возможность общения (обмениваться сообщениями). Если в процессе диалога между участниками людям не удается установить, что один из участников – машина, то такую машину можно считать обладающей интеллектом. Интересен план имитации мышления, предложенный А. Тьюрингом. «Пытаясь имитировать интеллект взрослого человека – пишет Тьюринг – мы вынуждены много размышлять о том процессе, в результате которого человеческий мозг достиг своего настоящего состояния… Почему бы нам вместо того, чтобы пытаться создать программу, имитирующую интеллект взрослого человека, не попытаться создать программу, которая имитировала бы интеллект ребенка? Ведь если интеллект ребенка получает соответствующее воспитание, он становится интеллектом взрослого человека… Наш расчет состоит в том, что устройство, ему подобное, может быть легко запрограммировано… Таким образом, мы расчленим нашу проблему на две части: на задачу построения «программы-ребенка» и задачу «воспитания» этой программы». Следует отметить, что именно этот путь используют практически все современные системы ИИ. Ведь понятно, что практически невозможно вложить все знания в систему ИИ. Более того, только на этом пути проявятся перечисленные выше признаки интеллектуальной деятельности (накопление опыта, адаптация и т. п.). [5]

2. Методики и подходы построения систем ИИ

Существуют различные подходы к построению систем ИИ – логический подход, структурный, эволюционный, имитационный. Это разделение не является историческим, когда одно мнение постепенно сменялось другим, и различные подходы и методики существуют параллельно и сегодня. Поскольку по-настоящему полноценных систем искусственного интеллекта в настоящее время нет, то нельзя и утверждать, что какой-то подход является правильным, а какой-то – нет.

Для начала рассмотрим логический подход. Человек занимается отнюдь не только логическими измышлениями. Это высказывание конечно верно, но именно способность к логическому мышлению очень сильно отличает человека от животных. Основой для данного логического подхода служит Булевая алгебра. Каждый программист знаком с нею и с её использованием, хотя бы на примере логического оператора IF (если). Свое дальнейшее развитие Булевая алгебра получила в виде исчисления предикатов – в котором она расширена за счёт введения предметных символов, отношений между ними, кванторов существования и всеобщности.

Практически каждая система ИИ, построенная на логическом принципе, представляет собой машину доказательства теорем. При этом исходные данные хранятся в базе данных в виде аксиом (правила логического вывода как отношения между ними). Каждая такая машина имеет блок генерации цели, и система вывода пытается доказать данную цель как теорему. Если цель доказана, то трассировка примененных правил позволяет получить цепочку действий, необходимых для реализации поставленной цели. Мощность такой системы определяется возможностями генератора целей и машины доказательства теорем. Можно утверждать, что выражений алгебры не хватит для полноценной реализации ИИ, но стоит вспомнить, что основой всех существующих ЭВМ является бит – единица информации (или значение ячейки памяти), которая может принимать значения только логического 0 и 1. Было бы логично предположить, что всё, что возможно реализовать на ЭВМ, можно было бы реализовать и в виде логики предикатов. Хотя здесь ничего не упоминается о том, сколько на это уйдёт времени. Добиться большей выразительности логическому подходу позволяет такое сравнительно новое направление, как нечёткая логика. Её особенностью является то, что правдивость высказывания может принимать кроме значений да/нет (1/0) ещё и промежуточные значения – «не знаю» (0.5), «скорее да, чем нет» (0.75) и «скорее нет, чем да» (0.25). Такой подход больше похож на мышление человека, поскольку человек не часто отвечает только «да» или «нет».

Для большинства логических методов характерна большая трудоёмкость, поскольку во время поиска доказательства возможен полный перебор вариантов. Данный подход требует эффективной реализации вычислительного процесса, и удовлетворительные результаты работы обычно гарантируются только при сравнительно небольшом размере базы данных.

Под структурным подходом подразумеваются попытки построения ИИ путём моделирования структуры человеческого мозга. Одной из первых таких попыток был перцептрон Ф. Розенблатта. Основной моделируемой структурной единицей в перцептронах (как и в большинстве других вариантов моделирования мозга) является нейрон. Позднее возникли и другие модели, известные под общим названием «нейронные сети» (НС). Модели эти различаются по строению отдельных нейронов, по топологии связей между ними и по алгоритмам обучения. Среди наиболее известных вариаций НС можно назвать НС с обратным распространением ошибки, сети Хопфилда и стохастические нейронные сети.

Нейронные сети наиболее успешно применяются в задачах распознавания образов, в том числе сильно зачумленных (нечётких). Также имеются примеры успешного применения НС для построения собственно систем ИИ.

Для моделей, построенных на основе строения человеческого мозга характерна не слишком большая выразительность, оприделённое распараллеливание алгоритмов и, благодаря последнему, высокая производительность параллельно реализованных НС. Для таких сетей характерно одно свойство, которое делает из очень схожими с человеческим мозгом – нейронные сети работают даже при условии недостаточной информации об окружающей среде, т.е. как и человек, они поставленный вопрос могут отвечать не только «да» и «нет» но и «не знаю точно, но скорее нет», «не знаю точно, но скорее да».

Довольно большое распространение получил эволюционный подход. При построении систем ИИ по такому подходу, основное внимание уделяется построению начальной модели и правилам, по которым она (модель) может изменяться (эволюционировать). Модель может быть составлена по самым различным методам, это могут быть и НС и набор логических правил и любая другая модель. После этого мы запускаем ИИ, и он, на основании проверки моделей, отбирает самые лучшие из них, на основании которых по самым различным правилам генерируются новые модели, из которых опять выбираются самые лучшие и т. д.

Эволюционных моделей, как таковых, не существует, есть только эволюционные алгоритмы обучения, но модели, полученные при эволюционном подходе, имеют некоторые характерные особенности, что позволяет выделить их в отдельный класс. Такими особенностями являются перенесение основного внимания разработчика с построения модели на алгоритм её модификации и то, что полученные модели практически не сопутствуют извлечению новых знаний о среде, окружающей систему ИИ, то есть она (система) становится «вещью в себе».

Широко используется для построения систем ИИ также имитационный подход. Данный подход является классическим для кибернетики с одним из её базовых понятий – «чёрным ящиком» (ЧЯ). Чёрный ящик – это устройство, программный модуль или набор данных, информация о внутренней структуре и содержании которого отсутствуют, но известны спецификации входных и выходных данных. Объект, поведение которого имитируется, как раз и представляет собой такой «черный ящик». Не важно, что у него внутри и как он функционирует, главное, чтобы наша модель в аналогичных ситуациях вела себя точно так же. Таким образом моделируется другое свойство человека – способность копировать то, что делают другие, не вдаваясь в подробности, зачем это нужно. Зачастую эта способность экономит человеку массу времени, особенно в начале его жизни. К недостаткам имитационного подхода можно отнести низкую информационную способность большинства моделей, построенных с его помощью.

Отдельно стоит отметить, что на практике четкой границы между разными подходами нет. Часто встречаются смешанные системы ИИ, где часть работы выполняется по одной методике, а часть – по другой. [5]

3. Проблемы создания ИИ

Анализ проблемы искусственного интеллекта открывает роль таких философских познавательных орудий, как категории, специфическая семиотическая система, логические структуры, ранее накопленное знание. Всё это обнаруживаются не посредством исследования физиологических или психологических механизмов познавательного процесса, но выявляется в знании, в его языковом выражении. Орудия познания, формирующиеся, в конечном счёте на основе практической деятельности, необходимы для любой системы, выполняющей функции абстрактного мышления, независимо от её конкретного материального субстрата и структуры. Поэтому, чтобы создать систему, выполняющую функции абстрактного мышления (т. е. в конечном счёте, формирующую адекватные схемы внешних действий в существенно меняющихся средах) необходимо наделить такую систему этими орудиями. Развитие систем ИИ за последние время как раз идёт по этому пути. Степень продвижения в данном направлении в отношении каждого из указанных познавательных орудий разная, но в целом пока, увы, незначительна.

В наибольшей мере системы ИИ используют формально-логические структуры, что обусловлено их неспецифичностью для мышления и, в сущности, алгоритмическим характером. Это дает возможность относительно легкой их технической реализации. Но даже здесь кибернетике предстоит пройти большой путь. В системах искусственного интеллекта ещё слабо используются модальная, императивная, вопросная и иные логики, которые функционируют в человеческом интеллекте, и не менее необходимы для успешных познавательных процессов, чем давно освоенные логикой, а затем и кибернетикой формы выводов. Повышение «интеллектуального» уровня технических систем, безусловно, связано не только с расширением применяемых логических средств, но и с более интенсивным их использованием – проверка информации на непротиворечивость, конструирования планов вычислений и т. п.

Сложнее обстоит дело с семиотическими системами, без которых интеллект невозможен в принципе. Языки, используемые в ЭВМ, ещё далеки от семиотических структур, которыми оперирует мышление. Прежде всего, для решения ряда задач, необходимо последовательное приближение семиотических систем, которыми наделяется ЭВМ, к естественному языку, точнее, к использованию его ограниченных фрагментов. В этом плане предпринимаются попытки наделить входные языки ЭВМ универсалиями языка, например, полисемией (которая элиминируется при обработке в лингвистическом процессоре). Уже разработаны проблемно-ориентированные фрагменты естественных языков, достаточные для решения системой ряда практических задач. Наиболее важным итогом такой работы является создание семантических языков (и их формализация), в которых слова-символы имеют определенную интерпретацию.

Многие универсалии естественных языков, необходимые для выполнения ими познавательных функций, в языках ИИ пока реализованы слабо (например, открытость) или используются ограниченно (например, полисемия). Все чаще воплощение в семиотических системах универсалий естественного языка, обусловленных его познавательной функцией, выступает одной из важнейших линий совершенствования систем ИИ, особенно тех, в которых проблемная область заранее чётко не определена.

Сегодня системы искусственного интеллекта способны осуществлять перевод с одномерных языков на многомерные. В частности, они могут строить диаграммы, схемы, чертежи, графы, чертить на экране кривые и т. п. ЭВМ производят и обратный перевод (описывают графики и тому подобное с помощью символов). Такого рода перевод является существенным элементом интеллектуальной деятельности. Правда современные системы ИИ пока не способны к непосредственному (без перевода на символический язык) использованию изображений или воспринимаемых сцен для «интеллектуальных» действий. Поиск путей глобального, а не локального, оперирования информацией составляет одну из важнейших и задач теории искусственного интеллекта.

Воплощение в информационные массивы и программы систем ИИ аналогов категорий находится пока в начальной стадии. Например, в категории входят понятия «целое», «часть», «общее», «единичное». Они используются в ряде систем представления знаний, в частности в качестве «базовых отношений», в той мере, в какой это необходимо для тех или иных конкретных предметных или проблемных областей, с которыми взаимодействуют системы. В формализованном понятийном аппарате некоторых систем представления знаний предприняты отдельные попытки выражения некоторых моментов содержания и других категорий (например, «причина» и «следствие»). Однако ряд категорий (например, «сущность» и «явление») в языках систем представления знаний отсутствует. В целом, данная проблема разработчиками систем ИИ в полной мере ещё не осмыслена, и предстоит ещё большая работа философов, логиков и кибернетиков по внедрению аналогов категорий в системы представления знаний, и другие компоненты интеллектуальных систем.

Современные системы ИИ почти не имитируют сложную иерархическую структуру образа, что не позволяет им перестраивать проблемные ситуации, комбинировать локальные части сетей знаний в блоки, перестраивать эти блоки и т. п. Не является совершенным и взаимодействие вновь поступающей информации с совокупным знанием, фиксированным в системах. В семантических сетях и фреймах, использующихся при представлении знаний, пока недостаточно используются методы, благодаря которым интеллект человека легко пополняется новой информацией, находит нужные данные, перестраивает свою систему знаний и т. п.

Ещё в меньшей мере современные системы ИИ способны активно воздействовать на внешнюю среду, без чего не может; осуществляться самообучение и вообще совершенствование «интеллектуальной» деятельности.

Таким образом, хотя определенные шаги к воплощению гносеологических характеристик мышления в современных системах искусственного интеллекта сделаны, но в целом эти системы ещё далеко не владеют комплексом гносеологических орудий, которыми располагает человек и которые необходимы для выполнения совокупности функций абстрактного мышления. Чем больше характеристики систем искусственного интеллекта будут приближены к гносеологическим характеристикам мышления человека, тем ближе будет их «интеллект» к интеллекту человека, точнее, тем выше будет их способность к комбинированию знаковых конструкций, воспринимаемых и интерпретируемых человеком в качестве решения задач и вообще воплощения мыслей.

Поэтому возникает сложный вопрос. При анализе познавательного процесса гносеология абстрагируется от психофизиологических механизмов, посредством которых реализуется сам процесс. Но из этого не следует, что для построения систем искусственного интеллекта эти механизмы не имеют значения. Не исключено, что механизмы, необходимые для воплощения неотъемлемых характеристик интеллектуальной системы, не могут быть реализованы в цифровых машинах или даже в любой технической системе, включающей в себя только компоненты неорганической природы. Также не исключено, что хотя мы и можем познать все гносеологические закономерности, обеспечивающие выполнение человеком его познавательной функции, но их совокупность реализуема лишь в системе, субстратно тождественной человеку.

Подобный взгляд обосновывается X. Дрейфусом. «Телесная организация человека – пишет он – позволяет ему выполнять… функции, для которых нет машинных программ – таковые не только ещё не созданы, но даже не существуют в проекте… Эти функции включаются в общую способность человека к приобретению телесных умений и навыков. Благодаря этой фундаментальной способности наделенный телом субъект может существовать в окружающем его мире, не пытаясь решить невыполнимую задачу формализации всего и вся».

Подчеркивание значения «телесной организации» для понимания особенностей психических процессов, в частности возможности восприятия, заслуживает отдельного внимания. Качественные различия в способности конкретных систем отражать мир тесно связаны с их структурой, которая хотя и обладает относительной самостоятельностью, но не может преодолеть некоторых рамок, заданных субстратом. В процессе биологической эволюции совершенствование свойства отражения происходило на основе усложнения нервной системы, т. е. субстрата отражения. Не исключено, что различие субстратов ЭВМ и человека может обусловить фундаментальные различия в их способности к отражению, что ряд функций человеческого интеллекта в принципе недоступен машинам.

В философской литературе утверждается, что допущение возможности выполнения технической системой интеллектуальных функций человека означает сведение высшего (биологического и социального) к низшему (к системам из неорганических компонентов) и, следовательно, противоречит материалистической диалектике. Но в этом рассуждении не учитывается, что пути усложнения материи однозначно не однозначны, и не исключено, что общество имеет возможность создать из неорганических компонентов (абстрактно говоря, минуя химическую форму движения) системы не менее сложные и не менее способные к отражению, чем биологические. Созданные таким образом системы являлись бы компонентами общества, социальной формой движения. Вопрос о возможности передачи интеллектуальных функций техническим системам, и в частности о возможности наделения их рассмотренными в работе гносеологическими орудиями, не может быть решен только исходя из философских соображений. Он должен быть подвергнут анализу на базе конкретных научных исследований. X. Дрейфус подчеркивает, что ЭВМ оперирует информацией, которая не имеет значения, смысла. Для ЭВМ необходим перебор огромного числа вариантов. Телесная организация человека, его организма позволяет отличать значимое от незначимого для жизнедеятельности и вести поиск только в сфере первого. Для «не телесной» ЭВМ, утверждает Дрейфус, это недоступно. Конечно, конкретный тип организации тела позволяет человеку ограничивать пространство возможного поиска. Это происходит уже на уровне анализаторной системы. Совсем иначе обстоит дело с ЭВМ. Когда в кибернетике ставится общая задача, например распознания образов, то эта задача переводится с чувственно-наглядного уровня на абстрактный. Тем самым снимаются ограничения, не осознаваемые человеком, но содержащиеся в его «теле», в структуре органов чувств и организма в целом. Они игнорируются ЭВМ. Поэтому пространство поиска резко увеличивается. Это значит, что к «интеллекту» ЭВМ предъявляются более высокие требования (поиска в более обширном пространстве), чем к интеллекту человека, к которому приток информации ограничен физиологической структурой его тела.

Обладающие психикой системы отличаются от ЭВМ прежде всего тем, что им присущи биологические потребности, обусловленные их материальным, биохимическим субстратом. Отражение внешнего мира происходит сквозь призму этих потребностей, в чём и выражается активность психической системы. ЭВМ не имеет потребностей, органически связанных с ее субстратом, для нее как таковая информация незначима, безразлична. Значимость, генетически заданная человеку, имеет два типа последствий. Первый – круг поиска сокращается, и, тем самым, облегчается решение задачи. Второй – нестираемые из памяти фундаментальные потребности организма обусловливают односторонность психической системы. Дрейфус пишет в связи с этим: «Если бы у нас на Земле очутился марсианин, ему, наверное, пришлось бы действовать в абсолютно незнакомой обстановке; задача сортировки релевантного и нерелевантного, существенного и несущественного, которая бы перед ним возникла, оказалась бы для него столь же неразрешимой, как и для цифровой машины, если, конечно, он не сумеет принять в расчет никаких человеческих устремлений». С этим можно не согласится. Если предложенный «марсианин» имеет иную биологию, чем человек, то он имеет и иной фундаментальный слой неотъемлемых потребностей, и принять ему «человеческие устремления» значительно труднее, чем ЭВМ, которая может быть запрограммирована на любую цель.

Живое существо в принципе не может быть по отношению к этому фундаментальному слою перепрограммировано, хотя для некоторых целей оно может быть запрограммировано вновь, посредством дрессировки. В этом смысле потенциальные интеллектуальные возможности машины шире подобных возможностей животных. У человека же над фундаментальным слоем биологических потребностей надстраиваются социальные потребности, и информация для него не только биологически, но и социально значима. Человек универсален и с точки зрения потребностей, и с точки зрения возможностей их удовлетворения. Однако эта универсальность особо присуща ему как социальному существу, производящему средства целесообразной деятельности, в том числе и системы искусственного интеллекта. Следовательно, телесная организация не только даёт дополнительные возможности, но и создает дополнительные трудности. Поэтому интеллекту человека важно иметь на вооружении системы, свободные от его собственных телесных или иных потребностей. Конечно, от таких систем неразумно требовать, чтобы они самостоятельно распознавали образы, классифицировали их по признакам, по которым это делает человек. Цели для них необходимо задавать в явной форме.

Следует отметить, что технические системы могут иметь аналог телесной организации. Развитая кибернетическая система обладает рецепторными и эффекторными придатками. Начало развитию таких систем положили интегральные промышленные роботы, в которых ЭВМ в основном выполняет функцию памяти. В роботах «третьего поколения» ЭВМ выполняет и «интеллектуальные» функции. Их взаимодействие с миром призвано совершенствовать их «интеллект». Такого рода роботы имеют «телесную организацию», конструкция их рецепторов и эффекторов содержит определенные ограничения, сокращающие пространство, в котором, образно говоря, могла бы совершать поиск цифровая машина. Тем не менее, совершенствование систем искусственного интеллекта на базе цифровых машин может иметь границы, из-за которых переход к решению интеллектуальных задач более высокого порядка, требующих учёта глобального характера переработки информации и ряда других гносеологических характеристик мышления, невозможен на дискретных машинах при сколь угодно совершенной программе. Техническая, а не только биологическая, эволюция отражающих систем оказывается связанной с изменением материального субстрата и конструкции этих систем. Такая эволюция, т. е. аппаратное усовершенствование систем искусственного интеллекта, например, через более интенсивное использование аналоговых компонентов, гибридных систем, голографии и ряда других идей, будет иметь место. При этом не исключается использование физических процессов, протекающих в мозгу, и таких, которые психика в качестве своих механизмов не использует. Наряду с этим ещё далеко не исчерпаны возможности совершенствования систем ИИ путём использования в функционировании цифровых машин гносеологических характеристик мышления, о которых речь шла выше.

В последнее время при анализе проблем, связанных с ИИ, часто применяют математический аппарат нечётких множеств, идея и реализация которого принадлежит американскому математику Л.Заде. Суть подхода состоит в отказе от принципа детерминизма. Пожалуй, наиболее поразительным свойством человеческого интеллекта является способность принимать правильные решения в обстановке неполной и нечёткой информации. Построение моделей, приближенных е рассуждениям человека, и использование их в компьютерных системах будущих поколений представляет сегодня одну из важнейших проблем науки. Смещение центра исследований нечётких систем в сторону практических приложений привело к выявлению целого ряда проблем, таких, как новые архитектуры компьютеров для нечётких вычислений, элементная база нечётких компьютеров и контроллеров, инструментальные средства разработки, инженерные методы расчёта и разработки нечётких систем управления и многое другое. Математическая теория нечётких множеств, предложенная Л.Заде около тридцати лет назад, позволяет описывать нечёткие понятия и знания, оперировать этими знаниями и делать нечёткие выводы. Основанные на этой теории методы построения компьютерных нечетких систем существенно расширяют области применения компьютеров. Нечёткое управление является одной из самых активных и результативных областей исследований применения теории нечётких множеств. Нечёткое управление оказывается особенно полезным, когда технологические процессы являются слишком сложными для анализа с помощью общепринятых количественных методов, или когда доступные источники информации интерпретируются неточно или неопределенно. Экспериментально показано, что нечёткое управление дает лучшие результаты, по сравнению с получаемыми, при общепринятых алгоритмах управления. Нечеткая логика, на которой основано нечеткое управление, ближе к человеческому мышлению и естественным языкам, чем традиционные логические системы. [2,3,4,7,8]

4. Реализация систем ИИ

Ещё в далёком 1954 году американский исследователь А.Ньюэлл решил написать программу для игры в шахматы. Идеей он поделился с аналитиками корпорации RAND Corporation, и которые предложили Ньюэллу свою помощь. В качестве теоретической основы программы было решено использовать метод, предложенный К. Шенноном, основателем теории информации. Точная формализация метода была выполнена А. Тьюрингом. Он же и смоделировал его вручную. К работе была привлечена группа голландских психологов под руководством А. Де Гроота, изучавших стили игры выдающихся шахматистов. Через два года совместной работы этим коллективом был создан язык программирования ИПЛ1 –первый символьный язык обработки списков. Вскоре была написана первая программа, которую можно отнести к достижениям в области искусственного интеллекта. Это была программа «Логик-Теоретик» (1956 г.), предназначенная для автоматического доказательства теорем в исчислении высказываний. Собственно программа для игры в шахматы, NSS, была завершена в 1957 г. В основе её лежали так называемые эвристики – правила, которые позволяют сделать выбор при отсутствии точных теоретических оснований – и описания целей. Управляющий алгоритм пытался уменьшить различия между оценками текущей ситуации и оценками цели или одной из подцелей. [1]

В 1956 году в США собрались основатели кибернетики с целью обсудить возможности реализации проекта «Искусственный интеллект», как они его тогда назвали. В числе участников конференции были Д. Маккарти, М. Минский, К. Шеннон, А. Тьюринг и др. К ИИ первоначально просто отнесли свойства машин брать на себя отдельные функции человека, например, такие как перевод с одного языка на другой, распознавание объектов, принятие оптимальных решений и пр. В СССР направление «Искусственный интеллект» (ИИ) возникло с опозданием на целых 10 лет и пришло на смену кибернетическому и бионическому буму первой половины 60-х годов. Поначалу оптимистам казалось, что произойдет революция и машина начнет думать как человек. Ничего подобного не произошло. Стало ясно, что никакого мышления, аналогичного человеческому, сходу построить не получится. Поэтому акценты сместились в сторону создания искусственного интеллекта – т.е. машинным решением «трудных» задач, которые человек решает, а машина пока нет. Таким образом, первоначально ИИ не претендовал на прямое моделирование мышления, а был просто решением с помощью машины трудноформализуемых «человеческих» задач.

С самого начала предполагалось, что эти решения позволят сформулировать обобщения и выработать специфические методы ИИ, ведущие, в конечном счете, к машинному мышлению. Представители возникшего направления справедливо полагали, что к конструктивному определению и моделированию мышления полезно идти от специфики задач к методам их решения, вводя «интеллект» как механизм, необходимый для решения.

В конечном итоге оказалось, что к традиционным задачам ИИ стали относить довольно много задач. Например, это понимание машиной естественного языка, т.е. вопрос-ответные системы и доступ к базам данных на естественном языке, перевод с одного языка на другой, анализ изображений объёмных (3-d) сцен, доказательство теорем, игры, базы данных, базы знаний и др. [6]

Теперь вкратце рассмотрим наиболее активно развиваемые подходы и области применения ИИ – в порядке убывания их популярности. Надо отметить, что меньшая популярность нередко связана не столько с потенциалом технологии, сколько с отдаленностью перспектив её прикладной реализации (например, крайне высокий потенциал киберзаводов пока не вызывает серьезного интереса из-за наличия множества нерешенных задач по их управлению).

Нейронные сети

Это направление стабильно держится на первом месте. Продолжается совершенствование алгоритмов обучения и классификации в масштабе реального времени, обработки естественных языков, распознавания изображений, речи, сигналов, а также создание моделей интеллектуального интерфейса, подстраивающегося под пользователя. Среди основных прикладных задач, решаемых с помощью нейронных сетей – финансовое прогнозирование, раскопка данных, диагностика систем, контроль за деятельностью сетей, шифрование данных. В последние годы идёт усиленный поиск эффективных методов синхронизации работы нейронных сетей на параллельных устройствах.

Эволюционные вычисления

На развитие сферы эволюционных вычислений (ЭВ) значительное влияние оказали прежде всего инвестиции в нанотехнологии. ЭВ затрагивают практические проблемы самосборки, самоконфигурирования и самовосстановления систем, состоящих из множества одновременно функционирующих узлов. При этом удаётся применять научные достижения из области цифровых автоматов. Другой аспект ЭВ – использование для решения повседневных задач автономных агентов в качестве персональных секретарей, управляющих личными счетами, ассистентов, отбирающих нужные сведения в сетях с помощью поисковых алгоритмов третьего поколения, планировщиков работ, личных учителей, виртуальных продавцов и т. д. Сюда же относится робототехника и все связанные с ней области. Основные направления развития – выработка стандартов, открытых архитектур, интеллектуальных оболочек, языков сценариев/запросов, методологий эффективного взаимодействия программ и людей. Модели автономного поведения предполагается активно внедрять во всевозможные бытовые устройства, способные убирать помещения, заказывать и готовить пищу, водить автомобили и т. п. Отдельно стоит отметить социальные аспекты – неизвестно как общество будет на практике относиться к таким сообществам интеллектуальных программ.

Нечеткая логика

Системы нечеткой логики активнее всего будут применяться преимущественно в гибридных управляющих системах.

Обработка изображений

Продолжится разработка способов представления и анализа изображений (сжатие, кодирование при передаче с использованием различных протоколов, обработка биометрических образов, снимков со спутников), независимых от устройств воспроизведения, оптимизации цветового представления на экране и при выводе на печать, распределенных методов получения изображений. Дальнейшие развитие получат средства поиска, индексирования и анализа смысла изображений, согласования содержимого справочных каталогов при автоматической каталогизации, организации защиты от копирования, а также машинное зрение, алгоритмы распознавания и классификации образов.

Экспертные системы

Спрос на экспертные системы (ЭС) остаётся на достаточно высоком уровне. Наибольшее внимание сегодня уделяется системам принятия решений в масштабе времени, близком к реальному, средствам хранения, извлечения, анализа и моделирования знаний, системам динамического планирования.

Интеллектуальные приложения

Рост числа интеллектуальных приложений, способных быстро находить оптимальные решения комбинаторных проблем (возникающих, например, в транспортных задачах), связан с производственным и промышленным ростом в развитых странах.

Распределенные вычисления

Распространение компьютерных сетей и создание высокопроизводительных кластеров вызвали интерес к вопросам распределенных вычислений – балансировке ресурсов, оптимальной загрузке процессоров, самоконфигурированию устройств на максимальную эффективность, отслеживанию элементов, требующих обновления, выявлению несоответствий между объектами сети, диагностированию корректной работы программ, моделированию подобных систем.

Операционные системы реального времени

Появление автономных робототехнических устройств повышает требования к операционным системам реального времени (ОС РВ) – организации процессов самонастройки, планирования обслуживающих операций, использования средств ИИ для принятия решений в условиях дефицита времени.

Интеллектуальная инженерия

Особую заинтересованность в ИИ проявляют в последние годы компании, занимающиеся организацией процессов разработки крупных программных систем (программной инженерией). Методы ИИ все чаще используются для анализа исходных текстов и понимания их смысла, управления требованиями, выработкой спецификаций, проектирования, кодогенерации, верификации, тестирования, оценки качества, выявления возможности повторного использования, решения задач на параллельных системах. Программная инженерия постепенно превращается в так называемую интеллектуальную инженерию, рассматривающую более общие проблемы представления и обработки знаний (пока основные усилия в интеллектуальной инженерии сосредоточены на способах превращения информации в знания).

Самоорганизующиеся СУБД

Самоорганизующиеся СУБД будут способны гибко подстраиваться под профиль конкретной задачи и не потребуют администрирования.

Автоматический анализ естественных языков

Автоматический анализ естественных языков (лексический, морфологический, терминологический, выявление незнакомых слов, распознавание национальных языков, перевод, коррекция ошибок, эффективное использование словарей).

Высокопроизводительный OLAP-анализ

Высокопроизводительный OLAP-анализ и раскопка данных, способы визуального задания запросов.

Интеллектуальные медицинские системы

Медицинские системы, консультирующие врачей в экстренных ситуациях, роботы-манипуляторы для выполнения точных действий в ходе хирургических операций.

Киберзаводы

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

Прикладные методы

Небольшое число конференций посвящено выработке прикладных методов, направленных на решение конкретных задач промышленности в области финансов, медицины и математики.

Игры

Традиционно высок интерес к ИИ в среде разработчиков игр и развлекательных программ (это отдельная тема). Среди новых направлений их исследований – моделирование социального поведения, общения, человеческих эмоций, творчества. [9]

Заключение

Однозначного ответа, что же такое «искусственный интеллект» на данный момент не существует. Каждый автор имеет своё мнение на этот счёт. Некоторые считают, что ИИ может быть создан на основе одной из методик перечисленных выше, другие считают, что создание ИИ невозможно именно на текущем этапе развития человечества, третьи – вообще в принципе отрицают возможность создания ИИ.

Особенность ИИ в том, что это не сложная и дорогая технология, вроде атомной энергии. Это программный продукт, который легко тиражировать (копировать). Если учить ИИ тому, что человечество считаем полезным, то затем, теоретически, ИИ сможет развиваться по экспоненте, потому что для каждого нового поколения ИИ не требуется тратить время на изучение того, что уже знают предыдущие поколения (старые версии ИИ).

Но, если позволить «разумной» машине принимать самостоятельные решения, то невозможно знать заранее, что это будут за решения, и нет уверенности, что эти решения устроят человека. Поэтому машина, снова таки теоретически, сможет осуществить свою волю в соответствии со «своими» суждениями, даже если вы этого не желаете. [6]

Ну а что будет на самом деле – покажет будущее.

Список использованных источников

1. М. Тим Джонс. «Программирование искусственного интеллекта в приложениях» – М.: ДМК Пресс, 2004 – 312 с.: ил.

2. Лекторский В.А. «Теория познания (гносеология, эпистемология)» – «Вопросы философии», 1999, №8

3. Лефевр В.А. «От психофизики к моделированию души.» – «Вопросы философии», 1990, №7, с. 25-31.

4. Карл, Левитин, Поспелов, Хорошевский. «Будущее искусственного интеллекта.» – М.: Наука, 1991.

5. Сотник С. Л., «Основы проектирования систем искусственного интеллекта» –1998.

6. Шамис А.Л. «Поведение, восприятие, мышление: проблемы создания искусственного интеллекта». – Серия «Науки об искусственном» – 2005.

7. Мамардашвили М.К. «Сознание как философская проблема» – «Вопросы философии», 1990, №10

8. Шалютин С.М. «Искусственный интеллект: гносеологический аспект» – М.: Мысль, 1985.

9. Бобровский С. «Перспективы и тенденции развития систем искусственного интеллекта» – PC Week/RE №32, 2001 г., стр. 32.

Уральская государственная горно-геологическая академия

Горно-механический факультет

Кафедра автоматики и компьютерных технологий

ДОКЛАД

На тему:

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

Разработал студент

Гладких В.С.

Группа АГП-97-2

г. Екатеринбург 2001 г.

Использование нечёткой логики в системах автоматического управления

Современный уровень развития промышленности требует комплексного подхода при разработке САУ техническими объектами. Это обусловлено, с одной стороны, необходимостью повышения качества управления при минимальных затратах на создание и эксплуатацию систем, с другой стороны – усложнением структуры объекта управления, функций, выполняемых им, и, как следствие, увеличением факторов неопределённости, которые необходимо учитывать для управления объектом.

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

Математический аппарат, используемый в традиционных методах автоматического управления, не всегда в полной мере может удовлетворить нуждам современного производства. Поэтому в последнее время находят широкое распространение так называемые “мягкие вычисления”, основной принцип которых заключается в обеспечении приемлемого (не обязательно оптимального) качества управления в условиях неопределённости при относительно невысоком уровне затрачиваемых ресурсов (стоимостных, временных, вычислительных и т. п.). К мягким вычислениям в настоящее время относят такие информационные технологии, как экспертные системы, нейронные сети, нечеткие системы, генетические алгоритмы и ряд других. В их основе лежит попытка некоторой формализации деятельности головного мозга человека и функционирования живых организмов.

Рассмотрим ряд аспектов использования нечеткой логики при управлении ТО (техническими объектами). Построение нечетких систем основано на имитации действия человека-оператора или ЛПР при помощи ЭВМ. Действительно, человеку свойственно оперировать не количественными показателями, а качественными, но следует учитывать, что эти качественные понятия носят, по сути, нечёткий характер. При этом используются лингвистические переменные, описывающие входную ситуацию и управляющие воздействия на качественном уровне [1] (например, «Расход ксантогената» — «Немного уменьшить», «Температура» — «Средняя», «Уровень пульпы» — «Не изменять»). Эти лингвистические переменные задаются на некоторой количественной шкале, при помощи которой определяются степени соответствия данных рассматриваемым понятиям. Для этого используются функции принадлежности, принимающие значения от 0 до 1. Возможные значения лингвистических переменных называются термами (например, для лингвистической переменной – «Уровень пульпы» термами являются «Понизить», «Повысить», «Не изменять»). Кроме того, задается набор правил, ставящих в соответствие входной ситуации определённое управляющее воздействие. Эти правила обычно имеют вид «Если …, то…» и формируются при помощи эксперта или группы экспертов. Однако во многих случаях экспертам не удаётся принять однозначное решение о требуемом воздействии на объект при сложившейся ситуации. Например, если рассогласование между уставкой и выходом объекта отрицательно, а его производная положительна, даже опытному специалисту бывает затруднительно ответить, каким должно быть управляющее воздействие. Поэтому представляется целесообразным каждому правилу «Если …, то…» также ставить в соответствие некоторую величину из интервала от 0 до 1, отражающую степень уверенности в предпринимаемых действиях. Таким образом, формируется нечеткое соответствие между пространством предпосылок и пространством заключений [2].

После описанных процедур, выполняемых экспертами, вступает в действие механизм нечеткого логического вывода, в ходе которого осуществляется композиция нечеткого множества [3]. Композицию можно представить как аналог умножения вектор-строки на матрицу, только вместо операции умножения используется расширенное представление логической операции И, а вместо операции сложения – расширенное ИЛИ. В результате определяется нечёткое множество управляющих воздействий. Последним этапом алгоритма нечеткого управления является дефаззификация (от англ. слова «Fuzzy» – «нечеткий») – процесс перевода нечетких данных в конкретные физические управляющие величины.

Обычно в качестве расширений операций И и ИЛИ выбирают операции взятия минимума и максимума соответственно, т.е. используют максминный логический базис. Однако существуют и другие точки зрения относительно выбора логического базиса. Вообще тот или иной логический базис задается априори. Наиболее распространенными являются максминный, алгебраический и ограниченный базисы.

Как было сказано выше, нечёткое соответствие отражает степень уверенности ЛПР, выполняющего данное действие в сложившейся ситуации. График нечеткого соответствия может быть представлен в виде матрицы. Так, например, если входная Х и выходная Y переменные имеют одинаковые терм-множества Тх = Ту ={«Отрицательно», «Около нуля», «Положительно»}, а график нечеткого соответствия имеет вид:

,

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

— если Х «Отрицательно», то Y – «Отрицательно» со степенью уверенности 0,9, «Около нуля» — со степенью уверенности 0,3;

— если Х «Около нуля», то Y «Отрицательно» со степенью уверенности 0,3, «Около нуля» со степенью уверенности 0,8 , «Положительно» со степенью уверенности 0,3;

— если Х «Положительно», то Y «Около нуля» со степенью уверенности 0,3, «Положительно» со степенью уверенности 0,9.

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

В качестве иллюстрации различий в статических характеристиках нечеткого регулятора при выборе различных логических базисов для одномерного случая рассмотрим зависимости, изображенные на рисунках 1…3 приложения А. График нечеткого соответствия имеет вид

Такой график нечеткого соответствия означает, что эксперт, чьи знания были использованы при построении НР, мог выразить свою мысль следующим образом: «Я уверен, что, если Х положительно, то Y должно быть положительно и, если Х отрицательно, то Y должно быть отрицательно, но если Х близко к нулю, то Y может быть как близким к нулю, так и отрицательным, так и положительным – наверно, это зависит от дополнительных неучтенных условий (например, от производной Х по времени)».

Приведенные примеры достаточно наглядно демонстрируют различия свойств НР при выборе того или иного логического базиса.

Так, например, алгебраический базис обеспечивает более линейную статическую характеристику. С одной стороны, это свойство является положительным, поскольку разработчику систем управления всегда удобней иметь дело с линейными характеристиками. С другой стороны, линейную зависимость легко реализовать, не прибегая к нечёткой логике. Иными словами, если разработчик системы управления считает, что зависимость между входом и выходом системы должна быть близка к линейной и настаивает на том, что система должна строится на основе теории нечетких множеств, то можно порекомендовать ему использовать именно алгебраический базис.

Максминный базис генерирует характеристику, которую можно аппроксимировать типовой нелинейностью «зона нечувствительности + насыщение». Подобная характеристика является достаточно надежной, поскольку «насыщение» не дает системе идти в разнос, ограничивая неустойчивый режим автоколебаниями, а «нечувствительность» стабилизирует систему в режиме, близком к установившемуся. Такой вид характеристики в полной мере удовлетворяет концепции мягких вычислений.

Наиболее интересным является ограниченный базис, поскольку изменение графика нечеткого соответствия в этом случае может качественно повлиять на характеристики системы. Наглядным примером тому служит зависимость, изображённая на рис. 3. Как видно из этого рисунка, статическая характеристика имеет два участка, где коэффициент передачи отрицателен, т. е. при попадании на эти участки система теряет устойчивость (несмотря на то, что все промежуточные операции на первый взгляд кажутся монотонными). Как показал анализ эта немонотонность обусловлена способом дефаззификации.

Таким образом, целесообразно при построении нечётких систем управления пользоваться не только знаниями эксперта, но также базовыми понятиями теории автоматического управления.

Дать общие рекомендации относительно выбора того или иного базиса не представляется возможным – все зависит от специфики управляемого объекта.

Анализ работы нечетких САУ позволил выявить следующие основные факторы, влияющие на качество управления:

количество термов входных и выходных переменных;

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

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

способ дефаззификации;

выбор логического базиса.

Следует заметить, что во многих публикациях на основании ограниченных экспериментальных данных делается вывод о том, что нечеткие алгоритмы обеспечивают более высокую эффективность по сравнению с классическими. Это далеко не всегда справедливо. В каждом конкретном случае необходимо сопоставлять требуемое качество управления с располагаемыми ресурсами. Появление теории нечетких множеств и алгоритмов управления на её основе обусловлено, в первую очередь, появлением задач, для решения которых традиционного математического аппарата просто не существует.

Эффективность использования мягких вычислений весьма высока. Об этом можно судить по многочисленным публикациям, посвященным данной теме. Однако эта эффективность заметно возрастает, если наряду с мягкими вычислениями применять традиционные методы теории автоматического управления, опробованные в течение десятилетий и имеющие под собой достаточно жесткую математическую основу.

Нечеткая логика в соединении с ПИД регулированием

Для управления дискретными событиями обычно служит многоступенчатая логика, реализованная на программируемых логических контроллерах (ПЛК). Для непрерывного управления применяют релейные (двухпозиционные) или ПИД-регуляторы. Последние работают хорошо, когда управляемый объект находится в устойчивом режиме. В ситуациях же сильных помех, изменения параметров во времени или наличия запаздывания традиционные регуляторы могут не справиться со своей задачей, поскольку исходное для них предположение о линейности объекта уже не действует. В подобных случаях замена (дополнение) ПИД-регуляторов регуляторами на нечеткой логике часто оказывается более удобной, чем использование привычных, но усложненных регуляторов состояния или применение адаптивного подхода.

Это, однако, не единственная область, где находят применение решения, базирующиеся на нечеткой логике. Её основной потенциал в области промышленной автоматизации реализуется в возможностях непосредственного конструирования многосвязных регуляторов. Обычно с регулированием одной переменной вполне справляется релейный или ПИД-регулятор. Однако установки для множества одноконтурных регуляторов приходится задавать вручную. Операторы анализируют условия функционирования объекта и задают установки регулятору в целях его оптимизации. Этот процесс называется диспетчерским управлением и охватывает множество переменных. К сожалению, релейные и ПИД-регуляторы имеют дело лишь с одной переменной, поэтому необходимо множество независимых контуров управления, которые не могут «общаться» друг с другом. В тех случаях, когда необходимо учитывать взаимосвязь физических величин (параметров объекта), приходится строить полную математическую модель (ММ) объекта, позволяющую найти решение.

В промышленной автоматизации этому препятствует длительность разработки ММ, необходимость введения специальных настроечных параметров для последующей оптимизации регулятора из-за существенных упрощений при построении большинства ММ и сложность настройки этих параметров (поскольку оптимизация объекта в одном режиме работы нередко ухудшает её работу в других режимах). Кроме того, большинство специалистов не имеют достаточной подготовки для построения строгой ММ.

В итоге релейный и ПИД-регулятор управляет отдельной переменной объекта, а операторы осуществляют диспетчерское управление.

Нечеткая логика предоставляет высокоэффективное решение этой проблемы. Она позволяет разрабатывать многосвязные регуляторы с диспетчерскими функциями не по ММ, а на основании экспериментальных данных и опыта операторов. Такое решение характерно для случаев, подобных, например, регулированию нескольких температурных зон в печи или управлению дозированием флотационных реагентов.

Промышленное применение нечеткой логики началось в 80 – х годах, прежде всего в Европе и Японии. Когда выяснилось, что достоинства нечеткой логики можно использовать в полной мере лишь в сочетании с традиционными способами регулирования, начался выпуск продуктов, интегрирующих технологии нечеткой логики в аппаратуру и программное обеспечение промышленной автоматизации.

В 1990 г. японская фирма Omron разработала микропроцессор на нечеткой логике и реализовала его в виде сопроцессорного модуля для своих ПЛК. В 1992 г. корпорация Klockner-Moeller (Австрия) разработала специализированный «нечеткий ПЛК», сочетающий нечеткую логику и обычные методы автоматизации как в самом ПЛК, так и в соответствующем программном обеспечении. В 1994 г. компании Allen-Breadley (США) и Siemens (Германия) разработали полностью программные реализации ПЛК в виде функциональных блоков.

В 1997 г. Международная электротехническая комиссия разработала стандарт нечеткой логики CD IEC 1131-7 с целью объединить её с существующим стандартом IEC 1131 для ПЛК. Производители следуют этому направлению и широко интегрируют компоненты на нечеткой логике в АСУТП. Таким образом, разработчики большинства промышленных систем управления сегодня вполне обеспечены средствами нечеткой логики.

В качестве примера успешного применения контроллера на нечеткой логике можно привести систему стабилизации температуры горения на мусоросжигательных заводах в Мангейме. При использовании стандартных регуляторов производительность паровых котлов колебалась в пределах ±35 % от номинальной. Внедрение контроллера на нечеткой логике позволило на порядок уменьшить эту величину. В результате существенно повысилась управляемость процесса и снизились вредные выбросы в атмосферу, в частности, оксида углерода в 2 раза.

Еще один пример практического применения НЛ – очистка стоков. Процесс включает в себя комбинацию биологических, химических и механических факторов и практически не поддается математическому моделированию. Однако имеется большой опыт операторов, который можно реализовать с использованием нечеткой логики.

Основной переменной, характеризующей качество процесса, является содержание ионов тяжелых металлов в стоках на выходе из аппарата очистки. Существующие средства измерения концентраций ионов тяжелых металлов сложны и дороги в эксплуатации, не обеспечивают необходимые для управления процессом точность и частоту измерения. Кроме того, малые изменения входных переменных процесса могут резко изменить показатели выходных переменных. Поэтому следует определить некий показатель, характеризующий качество очистки стоков, либо содержание ионов тяжелых металлов в них.

Как показали экспериментальные исследования, переменными, определяющими качество протекания процесса очистки, являются значения водородного показателя рН и окислительно-восстановительного потенциала стоков еН, измеряемые на входе и выходе из аппарата очистки. Однако каждая измеряемая переменная рН и еН в отдельности не дает четкой и достоверной информации о содержании ионов тяжелых металлов в стоках. Поэтому появилась необходимость синтезировать на основе этих двух величин косвенный показатель качества очистки промышленных стоков, используемый в роли индикатора при управлении процессом. Исследования позволили выявить как косвенный показатель величину произведения рН и еН [4].

Используя аппарат НЛ, был составлен алгоритм управления процессом очистки стоков.

Структуру схемы управления можно представить следующим образом. Измеряемые на выходе из аппарата очистки величины рН и еН поступают на вход контроллера на нечеткой логике в блок вычисления косвенного показателя Y. Контроллер, используя 207 правил, рассчитывает и задает уставки стандартному ПИД-регулятору расхода стоков, поступающих на очистку. Этот ПИД регулятор является функциональным блоком нечеткого ПЛК. Проект был реализован в течение 3 месяцев и окупился за полгода.

Использование нечеткой логики в алгоритмах управления процессом флотации

Процесс флотации характеризуется, с одной стороны, достаточной сложностью и многообразием протекающих во флотомашине взаимосвязанных химических и физико-механических процессов, с другой стороны, — отсутствием возможности на многих обогатительных фабриках непрерывного оперативного контроля за рядом важнейших технологических параметров. Поэтому термин «недостаточная информация при управлении» является синонимом понятия нечеткая логика. Действительно, весьма трудно составить более или менее полную ММ процесса флотации в условиях взаимного влияния многих факторов (например, взаимодействие различных типов флотационных реагентов, наличие внутренних технологических обратных связей). Кроме этого коэффициенты уравнений модели переменны, т.к. статические и динамические свойства процесса изменяются во времени под воздействием помех (изменение характеристик флотомашин и межремонтные промежутки времени; сезонные колебания ионного состава и температуры воды; изменение свойств реагентов в зависимости от срока и хранения). Применение алгоритмов управления, основанных на нечеткой логике, позволяет существенно сократить время введения САУ в эксплуатацию на фабриках, подлежащих модернизации, а также уменьшить капитальные затраты на средства автоматизации.

В качестве примера предлагаю рассмотреть систему автоматического управления дозированием ксантогената в процесс медной флотации на Красноуральской обогатительной фабрике. Стоит отметить, что расход реагентов – эффективное дорогостоящее регулирующее воздействие процесса флотации. От правильно выбранного расхода реагента зависят конечные результаты флотации, а перерасход реагентов сказывается неблагоприятно на технико-экономических показателях работы фабрики.

Автоматизация процесса подачи реагента позволяет значительно сократить его расход, а также должна служить тому, чтобы более точно следовать режимным технологическим картам, предъявляющим жесткие требования к соблюдению постоянства соотношения «возмущающее воздействие – расход реагента»[5]. Однако довольно часто решения по коррекции количества подаваемого реагента принимаются оператором – технологом на основе личного опыта и носят, по сути, интуитивный характер. Применение аппарата нечеткой логики позволит моделировать механизм принятия решения оператором, используя его опыт в полной мере, и, следовательно, более эффективно автоматизировать процесс подачи реагентов и флотации в целом.

Главной задачей управления процессом подачи реагентов является максимальное извлечение ценного металла в концентрат. Содержание ксантогената во флотационной пульпе колеблется от 0,5 – 1 мг/л до 15 — 20 мг/л. Для многих условий оптимальной считается вполне определенная концентрация ксантогената в пульпе. Между расходом ксантогената и его концентрацией прослеживается четкая зависимость (рис.4)[6]. Для условий Красноуральской обогатительной фабрики экспериментально установлена оптимальная концентрация ксантогената со значением 5,5 мг/л. При снижении концентрации увеличивается содержание меди в хвостах, а увеличение приводит к необходимости осуществления дополнительных мероприятий по очистке сточных вод ОФ.

Дозирование ксантогената осуществляется комбинированной САУ по расходу твердого Qт на входе с корректировкой по концентрации ионов ксантогената в пульпе. Однако непосредственное оперативное измерение концентрации ксантогената на должном уровне осуществить невозможно вследствие того, что относительная погрешность средств измерения концентрации составляет 10%.

Благодаря тому, что существует нелинейная зависимость между расходом ксантогената и его концентрацией и, используя знания экспертов, можно применить аппарат нечеткой логики.

Следует уточнить, что задачей корректирующего контура является сообщение основному контуру относительного расхода реагента.

Концентрационное состояние флотомашины будет характеризоваться лингвистической переменной «Концентрационный режим», которая в зависимости от значения концентрации ксантогената в пульпе может принимать три вербальных значения, т.е. термы: «Недопитка» (НП), «Нормальный режим» (НР), «Перепитка» (ПП). Использовать большое число значений, например дополнительную нечеткую переменную «Сильная перепитка», нецелесообразно, т.к. для ЛПР это, вероятно, будет эквивалентно в данных условиях термину «ПП», что внесет лишь дополнительную неопределённость на стадии экспертного опроса. Непрерывные кусочно-линейные функции принадлежности нечетких множеств «НП» СНП, «Н» СН и «ПП» СПП, построенные на интервале 1,5…9,5 мг/л, представлены на рисунке 5.

Возможные управляющие решения по количеству подаваемого в процесс ксантогената ограничены в зависимости от конкретной ситуации тремя управляющими воздействиями из терм-множества RК «Расход ксантогената»: «Уменьшить подачу (УМ)», «Не изменять (НИ)», «Увеличить подачу (УВ)». Непрерывные кусочно-линейные аппроксимированные функции принадлежности нечётких множеств, задающих на абсолютной оси значения управляющих решений, изображены на рисунке 6. Диапазон изменения относительного расхода ксантогената ограничен интервалом 42…118 г/т. Максимальное значение функции принадлежности нечёткого множества «НИ» достигается на отметке 80 г/т.

Для каждого терма «УМ», «НИ», «УВ» лингвистической переменной «Расход ксантогената» соответственно определены матрицы МУМ, МНИ и МУВ, описывающие силу воздействия соответствующих управляющих решений (рисунок 7, а…в). Например, на рисунке 7, в изображена матрица МУВ, характеризующая управляющее решение «УВ». Из анализа матрицы видно, что если объект управления имел значение «НП», то в результате управляющего воздействия он со степенью уверенности 0,2 будет иметь прежнее значение, со степенью 0,8 – значение «Н» и со степенью уверенности 0,4 – «ПП».

Ситуация, в которую желательно перевести объект, т. е. целевая ситуация, определяется исходя из анализа степеней предпочтения управляющих решений. Степени предпочтения последних зависят от конкретной ситуации и задаются как продукционная система (набор правил) «ситуация – предпочтение решений».

На основании экспертного опроса составляется следующая система:

1) если лингвистическая переменная имеет значение «НП», то степени предпочтения управляющих решений составляют:

a (УМ) = 0; a (НИ) = 0,5; a (УВ) = 1;

2) если значение лингвистической переменной «Н», то

a (УМ) = 0,4; a (НИ) = 1; a (УВ) = 0,4;

3) если лингвистическая переменная имеет значение «ПП», то

a (УМ) = 1; a (НИ) = 0,2; a (УВ) = 0.

При этом степень предпочтения каждого вида управляющего решения в конкретной ситуации определяется как конъюнкция степени применения того или иного правила и заданных в них степеней предпочтения управляющих решений. Результирующие степени предпочтения применения управляющих решений принимаются равными максимальным среди соответствующих степеней предпочтения по каждому значению признаков «УМ», «НИ», «УВ».

Рассмотрим процедуру поиска управляющего решения на основе алгоритмов нечеткого ситуационного вывода[2].

По рисунку 5 идентифицируем текущую ситуацию, в которой находится объект. Например, имеет место ситуация s0 = {б0,6/НПс,б0,4/Нс}.

1) Определяем степени предпочтения каждого управляющего решения «УМ», «НИ», «УВ». Они соответственно равны

a (R1,s0) = 0,4; a (R2,s0) = 0,5; a (R3,s0) = 0,6.

Выбираем управляющее решение R3 «УВ» как имеющее наибольшую степень предпочтения.

2) Моделируем принятие выбранного управляющего решения R3. Для этого выполняется композиция нечетких значений признаков в ситуации s0 и нечетких отношений, задающих силу воздействия управления R3 (рисунок 7, в). В результате получаем ситуацию s03 = {б0,2/НПс,б0,6/Нс, б0,4/ППс}.

3) Находим величину требуемого управляющего воздействия. Сначала определяем нечеткое отношение М, для этого вычисляем декартово произведение s0 ґ s03 и строим матрицу нечетких управляющих решений, которая представлена на рисунке 8.

4) Раскладываем полученное управляющее решение в базисе {«УМ», «НИ», «УВ»}. Для этого необходимо определить нечеткое множество

RJ = {бμR(УМ)/ УМ с,бμR(НИ)/ НИ с,бμR(УВ)/ УВс}.

Для определения коэффициентов μR(УМ), μR(НИ), μR(УВ) следует вычислить степени включения отношения М в отношения МУМ , МНИ, МУВ. Управляющее решение в нечетком виде выглядит следующим образом:

RJ = {б0,4/ УМ с,б0,4/ НИ с,б0,6/ УВс}.

5) Проводим дефаззификацию — определяем количественное значение управляющего решения. Для этого необходимо построить объединение конъюнкций нечетких множеств, задающих термы «УМ», «НИ», «УВ», со степенями принадлежности этих термов нечеткому множеству RJ и найти центр площади полученной фигуры (рисунок 6), т.е. применить метод «центральной точки». Верхняя огибающая, соответствующая объединению полученных множеств, показана пунктирной линией. Перпендикуляр, построенный в точке 86 г/т, делит площадь фигуры пополам. Это означает, что значение 86 г/т является количественным выражением нечеткого управляющего решения.

Следовательно, при возникновении рассмотренной в примере нечеткой ситуации, надо увеличить относительный расход ксантогената до 86 г/т.

Техническая реализация данной системы дозирования ксантогената может быть осуществлена с помощью микропроцессорного программируемого контроллера Omron C 200 H с блочно-модульной архитектурой. Корректирующий контур реализуется в модуле нечеткой логики, который выдает сигнал, пропорциональный величине относительного расхода, в модуль ПИД – регулирования, где и формируется управляющее воздействие для дозатора ксантогената.

Заключение

Можно сделать следующий вывод: ключ к успешному внедрению нечеткой логики в промышленную автоматизацию – в умелом сочетании её с традиционными средствами. Нечеткая логика не заменяет обычной техники управления, а дополняет её высокоэффективной методологией реализации стратегий многосвязного управления. Таким образом, основной потенциал нечеткой логики лежит в сфере реализации функций диспетчерского управления.

Список литературы

1. Заде Л. Понятие лингвистической переменной и его применение к принятию приближенных решений. М.: Мир,1976.

2. Мелихов А.Н., Бернштейн Л.С., Коровин С. Я. Нечеткие. Ситуационные советующие системы с нечеткой логикой. М.: Наука, 1990.

3. Нечеткие множества и теория возможностей. Последние достижения: Пер. с англ./ Под ред. Р. Р. Ягера. М.: Радио и связь, 1986.

4. Топчаев В. П. Шапировский М. Р. Гульдин В. И. Оптимальное управление процессом очистки стоков промышленных предприятий методом гальванокоагуляции // Цветные металлы. 1995. № 9.

5. Троп А. Е., Козин В. З., Прокофьев Е. В. Автоматическое управление технологическими процессами обогатительных фабрик: Учебник для вузов. – 2-е изд., перераб. и доп. – М.: Недра, 1986.

6. Троп А. Е., Козин В. З., Аршинский В. М. Автоматизация обогатительных фабрик. М.: Недра, 1970.

ПРИЛОЖЕНИЕ А

Рисунок 1- Алгебраический базис Рисунок 2 — Максминный базис

Рисунок 3 – Ограниченный логический базис.

Рисунок 4 – Зависимость между расходом и концентрацией ксантогената.

Рисунок 5 — Функции принадлежности нечетких множеств СНП, СН, СПП

Рисунок 6 — Функции принадлежности нечетких множеств «УМ», «НИ», «УВ»

а) МУМ =

б) МНИ =

в )

МУВ =

Рисунок 7 — Матрицы нечетких управляющих решений.

М =

Рисунок 8 — Матрица нечетких управляющих решений.

1. Общий обзор архитектуры UNIX систем. 5

Краткий обзор UNIX подобных операционных систем. 5
Основные причины популярности UNIX. 5
Структура операционной системы. 5
Задачи выполняемые ядром операционной системы 6
Подсистема управления процессами. 7
Подсистема управления памятью. 7
Файловая подсистема. 8
Подсистема ввода-вывода. 8

2. Шеллы и основные команды HP-UX. 9

Общее знакомство с шелами 9
Bourne Shell. 10
C Shell . 42
Korn Shell и POSIX shell 57
Key Shell (keysh). 65

3. Администрирование системы X Window 69

Базовые концепции X Window 69
Компоненты системы X Window 69
Предварительное конфигурирование 70
Имена и классы клиентов 73
Имена и классы ресурсов 74
Типы ресурсов 74
Управление шрифтами 75

2. Программирование на HP-UX 82

Этап линкирования. 85
Работа с библиотеками 85
Создание архивной библиотеки. 89
Открытие Библиотек Распределеного доступа 91
Создание Общедоступной Библиотеки с ld 92
Модифицирование Общедоступной Библиотеки 93
Применение make 94
Отладчик ADB 103
Отладчик XDB 109

3. Примеры команд 110

VARIABLES 117
LOCATIONS 117
FORMATS 118

4. Системные вызовы и взаимодействие с UNIX. 119

Время в UNIX. 124
Сигналы. 131
Деления просесса 135
Пайпы и FIFO-файлы. 135
Нелокальный переход. 138
Разделяемая память 139
Семафоры 140
Очереди сообщений 142

5. Старт системы. 146

6. Run-levels. 150

Остановка системы 155
Конфигурирование ядра системы 158

7. Изменение системных параметров 161

Инсталирование периферии 164
Системная конфигурация 165
Управление процессами 173
Управление процессами и ядро системы 182

8. 1. Файловая система HFS. 185

Структура файловой системы HFS 186
Главный суперблок 186
Группы цилиндров 187
Размер 187
Блоки данных 189

Доступ к блокам данных 190

Модификация файлов в HP-UX 193
Менджер логических дисков LVM 194
Создание корневой VG и корневого LV 201
Резервное копирование и свосстановление конфигурации Volume Groups 202
Перемещение и переконфигурирование дисков 203
3. Особенности файловой системы VxFS 206
Монтирование и демонтирование файловых систем 208
Проверка файловых систем 209

10. Мониторинг использования дискового пространства 212

11. . Организация веб-сайта 214

Выбор операционной системы. 214
Выбор программного обеспечения сервера. 215
Анализ веб-серверов. 216
Инсталляция веб-сервера. 217
Стратегическое планирование. Определение объема работы. 221
Тактическое планирование сайта. Разработка структуры. 226
Дизайн интерфейса. 228
Программирование. 230
Публикация и Маркетинг. 233

12. Веб-страницы и веб-приложения. 235

Классификация веб-объектов. 235
Спецификация DTD. Понятие ортогональности и методы ее реализации. 236
Веб-страницы. Языки разметки. (HTML, XML) 237
Веб-страницы. Программирование (JavaScript, CSS, SSI, CGI, PHP) 261
Модульность и ортогональность с использованием существующих технологий.
288
Веб-приложения. 289
Общие требования к страницам сайта. 290
Совместимость с различными браузерами. 292

13. Конфигурация и управление веб-серверами. 295

Встроенные средства управления сервером. (apachectl, apxs) 295
Глобальные разделы конфигурации. 296
Вспомогательные скрипты – просмотр и ротация логов, статистика посещений.
299
Безопасность веб-сервера. 299
Организация доступа и разграничение прав пользователей. 303
. Подключение новых модулей и апгрейд программного обеспечения веб-сайта.
303

14. Администрирование веб-сервера. 304

Логгирование и поиск ошибок. 305
Обеспечение безопасности . 311
Создание резервных копий. Технологии: Backup, mirroring. 313

15. Система безопасности HP-UX 314

16. Политика и планирование системы безопасности 314

Установка Trusted Системы 315
Управление паролями и системным доступом 316

17. Управлением доступом к файлам и каталогам 317

Контроль безопасности сети (networks) 319

Общий обзор архитектуры UNIX систем.

Краткий обзор UNIX подобных операционных систем.

В даный момент, не существует стандартной системы UNIX, вместо этого вы столкнетесь со множеством операционных систем, имеющих свои названия и особенности. Но за этими особенностями и названиями прослеживается общая архитектура, интерфейс и среда программирования. Все эти системы так или иначе являются родственными Из-за своей простоты, ясности, легкой способности к расширению и модификации UNIX стали переносить на множество платформ. Однако несмотря на множество реализаций базовой системы, среди всех них можно четко выделить две основные ветки: System V UNIX и BSD UNIX.
Различия между ними не носят принципияльный характер и зачастую сказать к какой из веток принадлежит та или иная реализация операционной системы бывает сложно. К основным различиям между System V и BSD подобными системами можно отнести терминальную инициализацию, имена конфигурационных файлов и файлов инициализации системы, стандартный размер блоков файловой системы, управление терминалами, различное отображение информации о процессах и.т.п. Одним словом принципиальных различий с точки зрения пользователя между разными ветками операционной системы UNIX не существует.
Рассматриваемая нами операционная система HP-UX 10.20 является одной из реализаций UNIX выпущенной фирмой Hewlett-Packard. По своей структуре это чистая System V подобная 32-х разрядная операционная система, включающая поддержку симметричных многопроцессорных систем (SMP), файловых систем большего объема (до 128Гб) и расширенного виртуального адресного пространства (до 3.75 Гб).

Основные причины популярности UNIX.

Каковы же причины популярности этой операционной системы ? В первую очередь это более чем трех десятилетний возраст. За этот период она полностью прошла проверку временем. Во вторых код системы практически полностью написан на языке высокого уровня С, что сделало ее простой для понимания, внесения изменений и переноса на другие аппаратные платформы.
Некоторые из версий UNIX поставляются вместе с исходными текстами, однако даже несмотря на то что большинство UNIX поставляется в виде бинарных файлов, система все равно остается легко расширяемой и настраиваемой. Так же следует отметить тот факт что UNIX в изначально создавалась как многопользовательская и многозадачная система ориентированная в первую очередь на выполнение серверных функций. Следует отметить и тот факт что
UNIX практически изначально создавалась как сетевая операционная система
(даже графическая оболочка UNIX система X Window является полностью сетевой), что позволило ей занять лидирующие позиции на рынке серверов для
Интернет приложений и дало мощные встроенные средства удаленного администрирования. Не маловажную роль в популярности UNIX сыграла ее единая иерархическая файловая система с унифицированным доступом не только к файлам данных но и к аппаратным ресурсам таким как диски, терминалы, принтеры, сеть, память и.т.п.

Структура операционной системы.

В задачу операционной системы UNIX входит непосредственное управление ресурсами компьютера, распределение их между пользователями, скрывая от последних внутреннюю архитектуру аппаратного обеспечения, путем предоставления унифицированного интерфейса доступа к аппаратным ресурсам.
К аппаратным ресурсам компьютера относится в первую очередь вычислительные ресурсы процессора, память и дисковое пространство, а также ряд периферийных устройств, таких как накопители на магнитных лентах, принтеры, терминалы, сетевые адаптеры и.т.п. Самый общий взгляд позволяет увидеть двухуровневую модель системы в том виде как она представлена на рис. 1.1.

Рис 1.1

В центре находятся аппаратные ресурсы компьютера с которыми непосредственно взаимодействует ядро операционной системы изолируя прикладные программы пользователя от особенностей аппаратной архитектуры.
Ядро имеет определенный минимальный набор услуг представляемых прикладным программам. В первую очередь это операции ввода-вывода (открытие, закрытие, чтение, запись и управление файлами), создание и управление процессами, организация синхронизации и обмена данными между процессами, управление памятью (реальной и виртуальной).

Второй важнейшей функцией выполняемой ядром является защита операционной системы от разрушения со стороны пользовательских программ и реализация механизмов защиты данных в многопользовательской среде. Все пользовательские приложения пользуются услугами ядра посредством системных вызовов.

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

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

Остановимся более подробно на структуре ядра операционной системы.
Функционально его можно представить состоящим из трех основных подсистем: подсистемы управления процессами и памятью, подсистемы ввода-вывода и файловой подсистемы. Все современные микропроцессоры поддерживают виртуальную память, защищенный и многозадачный режим работы. Последний подразумевает выделение кванта процессорного времени определенной задачи с последующим переключением на другую задачу

Каждая задача имеет идентификатор уровня защиты, некоторые команды из системы команд процессора могут выполняться на любом уровне защиты, но есть привелигированные команды выполнение которых возможно лишь задачей имеющей нулевой уровень привилегии. Ядро операционной системы работает на нулевом уровне защиты, только оно имеет непосредственный доступ к физической памяти, системным регистрам процессора и портам ввода вывода.
Пользовательские программы общаются с ядром посредством системных вызовов, представляющих собой команду приводящую к переключению процесса в контекст ядра, передачей параметров ядру. Затем ядро проверяет корректность параметров, права пользовательского процесса на возможность выполнения данного системного вызова и лишь после этого переходит к непосредственному выполнению всех низкоуровневых действий необходимых для исполнения пользовательского запроса. Благодаря этому достигается защита критически важных данных ядра от случайного или преднамеренного разрушения со стороны пользователя.

Второй из важнейших функций ядра является обработка исключительных ситуаций возникающих в результате работы операционной системы и представляющим собой програмные прерывания. К последним относятся ошибки защиты (на пример попытка прикладной программы получить доступ к портам ввода-вывода или чужой области памяти), ошибки в работе оборудования, а также системные события возникающие при нормальной работе операционной системы. Некоторые из исключительных ситуаций приводят к аварийному завершению системы (ошибки оборудования или исключительная ситуация возникшая во время обработки исключительной ситуации), некоторые к аварийному завершению пользовательской программы при этом возможен сброс на диск в файл образа процесса вызвавшего исключительную ситуацию c целью дальнейшего анализа отладчиком, а некоторые просто жизненно необходимы для нормального функционирования операционной системы (одна из таких исключительных ситуаций будет рассмотрена ниже).

Подсистема управления процессами.

Запущенная на выполнение программа порождает в системе один или больше процессов. Подсистема управления процессами отвечает за создание и уничтожение процессов, распределения ресурсом между процессами, синхронизацю и межпроцессное взаимодействие. Так как в данный момент времени на одном процессоре может выполняться лишь одна задача ядро операционной системы в зависимости от приоритета задачи выделяет ей определенный квант процессорного времени по истечению которого происходит переключение на следующую задачу. При этом исключается возможность захвата всех ресурсов процессора одной задачей и создается эффект параллельного выполнения нескольких задач.

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

Подсистема управления памятью управляет выделением, размещением и освобождением памяти для прикладных задач. Прикладные программы никогда не используют физическую память напрямую, т.к. все современные операционные системы реализуют так называемую виртуальную память объем которой может превышать объем физической памяти. При этом задействуется механизмы страничной адресации памяти в которых все виртуальное адресное пространство разделяется на небольшие блоки – страницы. Размер страницы варьируется в зависимости от архитектуры, для архитектуры HP PA-RISC это 2К, для Intel это 4K. Каждая страница имеет специальные атрибуты которые определяют права доступа к ней, факт присутствия в физической памяти, частоту обращений и.т.п. Преобразование из виртуального адреса в физический осуществляется аппаратно. Данная схема адресации дает ряд неоспоримых преимуществ которые используются всеми современными операционными системами. А именно: возможность экономии физической памяти путем совместного использования одних и тех же страниц виртуальной памяти разными процессами, реализация разделяемой памяти, а также возможность использования вторичных устройств в качестве устройств памяти что позволяет задачам задействовать виртуальной памяти больше чем есть реально физической памяти в системе. Реализуется это следующим образом: в случае нехватки физической памяти, ядро сбрасывает на внешний носитель (как правило диск) страницы к которым наиболее долго не было обращений, а так же при обращении к странице которой реально нет в физической памяти процессор генерирует исключительную ситуацию обработчик которой загружает страницу обратно с внешнего носителя в физическую память.
Этот процесс носит название пейджинг или свопинг.

Файловая подсистема.

Файловая подсистема ядра предоставляет унифицированный интерфейс для доступа к данным находящимися на дисках и других внешних устройствах. Она обеспечивает контроль прав доступа к файлам со стороны прользователя т.к. каждый файл имеет атрибуты доступа определяющие права доступа к нему со стороны определенного прользователя или групп пользователей.

Подсистема ввода-вывода.

Подсистема ввода-вывода обслуживает запросы файловой подсистемы и подсистемы управления процессами для доступа к периферийным устройствам
(сетевые адаптеры, диски, терминалы …). Также она обеспечивает буферизацию и кеширование данных и взаимодействует с драйверами устройств – специальными модулями ядра непосредственно работающими с внешними устройствами.

Шеллы и основные команды HP-UX.

2.1.1 Общее знакомство с шелами

2.1.2 Смена шела

2.2.1 Bourne Shell

2.2.1.1 Основные возможности Shell.

2. Shell скрипты

3. Основы программирования на языке shell

4. Некоторые специальные команды

Общее знакомство с шелами

Шелл это интерфейс между операционной системой и пользователем. Шелл интерпретирует пользовательский ввод и дает указания операционной системе выполнить те или иные действия. Шелл можно также рассматривать как язык программирования.

Bourne Shell. Это самый старейший из шелов который был написан
Стэфаном Борном в Лаборатории Беэлла. Этот шелл является шелом по умолчанию для HP-UX пользователей и долгое время был стандартом де факто.
Bourne Shell не имеет в своем арсенале ни интерактивных возможностей ни сложных программных конструкций в отличии от С и Korn шеллов.

C Shell. Этот шел был разработан Биллом Джоем в Калифорнийском
Университете Беркли. Его синтаксис имеет сходство с языком программирования
С. Он также имеет интерактивный интерфейс например историю команд и раскрытие имен файлов.

Korn Shell. Он является относительно новым шелом разработанным
Девидом Корном в Лаборатории Бэлла и является вверх совместимым с большинством возможностей Bourne Shell. Так же как и С shell он имеет интерактивные возможности, но выполняется быстрее имеет расширенные возможности редактирования командной строки.

POSIX shell. Этот шелл базируется на стандарте определенном в
Portable Operation System Interface (POSIX) – IEEE P1003.2. Этот стандарт был разработан для прикладных и системных программистов. Он фактически определяет стандарт на интерфейс операционной системы. Большинство возможностей POSIX Shell очень сильно схожи с аналогичными возможностями
Korn Shell-a. Мы будем рассматривать оба этих шела едино, указывая лишь небольшие различия между ними. POSIX Shell имеет тоже имя что и Bourne
Shell поэтому он помещен в /usr/bin/posix директорию в отличии от Bourne
Shell, который находится в директории /usr/bin.

Key Shell. Это оболочка для Kourn Shell-a разработанная фирмой
Hewlett-Packard. Она позволяет использовать меню и онлайн помощь помогая в построении команд и выполнению ряда часто встречаемых задач, таких как просмотр, редактирование и печать файлов, просмотр содержимого директории и.т.п. Построена она таким образом что пользователь может сам в дальнейшем

расширять ее возможности.

Bash. Название этого шела расшифровывается как Bourne Again Shell. Он бы разработан консорциумом Free Software Foundation и несмотря на то что по умолчанию он отсутствует в стандартной поставке HP-UX 10.20, в следствии своих мощных функциональных возможностей он пользуется огромной популярностью среди пользователей и администраторов HP-UX. Его интерпретатор команд совместим с Bourne Shell. Также он вместил в себе полезные возможности Korn C шеллов. Он разрабатывался в сооответствии со спецификациями IEEE POSIX Shell and Tools specification (IEEE Working
Group 1003.2).

2.1.2 Смена шела

Для того чтобы определить Ваш системный шелл достаточно сразу после логина выполнить команду:

echo $SHELL

она показывает содержимое переменной SHELL в которую система прописывает
Ваш шелл установленный по умолчанию. Для временной смены шела достаточно выполнить запуск желаемого шела в текущем:

$ ksh запуск Kourne Shell

$ ps печать списка процессов

PID TTY TIME COMMAND

12320 pts/2 0:00 sh Bourne shell

12322 pts/2 0:00 ksh Korn Shell

12323 pts/2 0:00 ps

$ exit выход из Korn Shell-a

Для постоянной смены шела устанавливаемого системой после входа (login shell) необходимо выполнить команду:

chsh

Замечание: список шелов доступных в системе для пользователей находится в файле /etc/shells

Bourne Shell.

1. Основные возможности Shell.

Запуск шелла и выход из шелла

Для запуска Bourne Shell достаточно ввести sh в текущем шеле. Выход из шела возможен либо по команде exit либо введя в терминале символ коца файла Ctrl-
D.

Последовательное выполнение команд.

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

$ who

$ ps –ef

$ ls –l и

$ who; ps –ef; ls -l дадут полностью одинаковый результат.

Фоновое выполнение.

Запуск программы в фоновом режиме (без блокировки текущего шела) достигается добавлением в конец команды знака &

Перенаправление ввода-вывода.

Каждая запущенная программа имеет три ассоциированных канала: стандартный ввод, стандартный вывод и стандартный канал диагностики ошибок. По умолчанию стандартный ввод закреплен за клавиатурой а стандартный вывод и канал ошибок закреплены за монитором. Однако шелл позволяет связать эти каналы с файлами абсолютно прозрачно для выполняемой программмы, т.к. изменения вывода и ввода осуществляются на системном уровне. Примеры перенаправлений ввода-вывода:

|Символ |Функция |Пример |
|< |Перенаправление ввода из файла |program < in_file |
|> |Перенаправление вывода в файл |program > out_file|
|>> |Перенаправление вывода в файл с |Program >> |
| |добавлением |out_file |

Пайпы. Две или более программ могут быть объединены таким образом что результат одной программы попадет на вход другой. При этом данные от одной программы к другой следуют через програмный канал, например:

program1 | program2 | program3

или более реалистичный пример:

ls –l /etc | more

Примечание: пайпы всегда работают лишь в одном направлении – со стандартного выхода одной к стандартному входу другой программы.

Расширение имен файлов.

В целях уменьшения количества набираемых символов при вводе имен файлов шел поддерживает метасимволы. Нпример для того чтобы вывести листинг всех файлов в текущей директории имена которых начинаются с буквы a достаточно воспользоваться командой ls –l a*

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

|Метасимвол |Описание |
|* |Означает любой символ в любом количестве |
|~ |Означает путь к домашнему каталогу |
|? |Любой символ в количестве один или больше |
|[ … ] |Равенство любого одного из символов заключенных|
| |в скобки. Пара символов разделенная знаком |
| |минус означает любой символ из промежутка между|
| |ними. Например [a-zA-Z] – любаялатинская буква |

5. Shell скрипты

Выполнение скриптов.

Несколько команд обьедененных одной последовательностью выполнения называется скриптом. Например последовательное выполнения команд, пайпы являются простейшими скриптами. Обычно команды из которых состоят скрипты сохраняют в файлах. Для запуска скрипта можно воспользоваться двумя методами:

sh

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

chmod +x

После чего можно выполнять скрипт:

./

Вывод текста.

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

echo “строка”

Файл .profile .

Каждый раз во время входа в систему Bourne Shell автоматически запускает файл .profile (скрипт) находящийся в вашей домашней директории. Этот скрипт устанавливает “окружение” в котором Вам предстоит работать. Это различные переменные окружения отвечающие за вид системной подсказки, путь поиска исполняемых файлов, тип терминала и.т.п. Приведем список основных переменных окружения.

. PATH устанавливает путь поиска исполняемых файлов и представляет собой набор директорий разделенных двоеточием
. MAIL определяет имя файла почтового ящика для уведомления о приходе новой электронной почты
. MAILCHECK параметр показывающий как часто (в секундах) следует проверять почтовый ящик на предмет прихода новой почты
. HOME определяет домашний каталог (каталог по умолчанию). Команда cd без параметров выполняет переход в этот каталог.
. PS1 основная системная подсказка (по умолчаию $)
. PS2 вторичная системная подсказка (по умолчанию >)
. SHELL имя логин шелла пользователя
. TERM тип терминала пользователя
. EDITOR имя текстового редактора по умолчанию

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

PATH=/bin:/usr/bin:/usr/sbin:/usr/contrib/bin:/usr/local/bin

и

PATH=/bin:/usr/bin:/usr/sbin

PATH=$PATH: :/usr/contrib/bin:/usr/local/bin

полностью эквивалентны. Для того чтобы эти переменные вошли в системное окружение (кроме шела, стали доступны и другим программам) необходимо выполнит команду

export

Комментарии.

Текст следующий за символом # рассматривается шелом как комментарий и не оказывает никакого влияния на работу скрипта.

Основы программирования на языке shell

Параметры.

В дополнение к стандартным параметрам шела можно создавать свои параметры, кторые затем можно использовать в командах. Например

$ x=test

$ echo $x test

$ aaa=/

$ ls $aaa

cdrom home nsmail tcb var

SD_CDROM dev lib opt tmp

TT_DB etc lost+found sbin tmp_mnt

Bin export net stand usr

При включении параметров в строку или в выражение знак $ должен предшествовать параметру. Также необходимо пользоваться следующими правилами:

${parameter} значение параметра заключенного в скобки будет использовано в выражении. Скобки {} используются когда за параметром следуют буквы или цифры не относящиеся к парамаметру. Например если значение параметра xxx равно test то значение выражения ${xxx}123 будет равняться test123

${parameter:-word} если параметр установлен и не пустой то результатом выражения будет являться значение параметра, в противном случае в результате будет использовано значение параметра word. Например: ${xxx:-/usr/bin/sh} если xxx пустой то результатом выражения будет являться строка

/usr/bin/sh

${parameter:=word} если параметр неустановлен или пустой, тогда значение word будет результатом выражения.
${parameter:+word} если параметр установлен и не пустой, тогда результатом выражения является word, в противном случае результат пустой.

Аргументы командной строки.

Когда Вы запускаете на выполнение программы, Вы можете передавать ей один или больше аргументов. Шелл скрипты имеют доступ к этим аргументам посредством параметров $0, $1, $2 …$9. Если аргументов больше девяти, их значения помещаются в буффер и могут быть доступны с использованием команды shift которая будет обсуждаться ниже. Параметр $0 всегда принимает значение имени выполняемого файла, $1 – первого аргумента командной строки,
$2 – второго, и.т.п.
Количество агрументов командной строки всегда можно узнать проанализировав параметр $#. В том случае если Вам необходим один параметр содержащий все аргументы командной строки разделенные пробелом нужно воспоьзоваться параметром $*.
Для получения доступа к аргументам с номером больше девяти необходимо воспользоваться командой shift. После очередного выполнения команды shift происходит сдвиг на один элемент в буффере параметров в результате которого значение параметра $2 получает параметр $1, значение параметра $3 получает
$2, и.т.п. Используя цикл (цыклы будут рассвотрены ниже) в сочетании с командой shift можно получать доступ ко всем аргументам командной строки с номерами превышающими 9.

Квотинг.

Очень часто случаются ситуации когда необходима особая трактовка тех символов которые шелл воспринимает как спец символы. Например случай когда строку текста включая пробелы нужно передать как один аргумент или знак $ должен не быть воспринят как указатель на параметр. Для этих целей используется квотинг (quoting).
Например символ бекслэша ( ) можно использовать для квотинга символа $.

$ param=aaa

$ echo $param aaa

$ echo $param

$param

В сочетании с бекслэшем для квотинга можно использовать двойные кавычки.
Например:

echo «$param is a «new directory»» aaa is a «new directory»

При этом знак $ внутри двойных кавычек интерпретируется как указатель на параметр а бэкслэш используется для “экранирования” внутренних кавычек.

Одинарные кавычки также можно использовать для квотинга но в отличии от двойных они “экранируют” все что находится внутри них. Разница сразу становится понятной после замены в предыдущем примере двойных кавычек однираными:

$ echo ‘$param is a «new directory»‘

$param is a «new directory»

Подстановка команд.

Символ обратного ударения ( ` ) используемый в скриптах указывает на подстановку команд. Это подразумевает что результат вывода команды подставляется в шелл как параметр. Нпример:

$ echo «The current date is `date`»

The current date is Sat Jan 6 04:16:35 GMT 2001

или

$ users=`who`

$ echo «Users currentrly logged in the system:n $users»

Users currentrly logged in the system: root console Jan 6 03:57 roman pts/0 Jan 5 23:12

Условия.

Очень часто случаются ситуации при написании скриптов когда необходимо выполнять те или иные команды в зависимости от конкретных условий.
Например, нужно отсортировать файл, а в случае его отсутствия вывести сообщение об ошибке. На этот случай шелл имеет условный оператор, и указанная задача решается с его использованием следующим образом:

if test –f $1 then sort $1 else echo “file $1 doesn’t exist” fi

Условный оператор имеет следующий синтаксис:

if then elif then

….. else fi

Оператор if проверяет статус выполненной команды (в данном примере test
–f)
И в случае успеха (программа возвращает 0) выполняет команды стоящие после then, в противном случае выполняются команды else/elif.

Наиболее часто используемой командой в оператореусловия является команда test. Она имеет множество опций, полный список которых можно получить обратившись к ее документации выполнив команду man test.Очень часто вместо команды test используют команду [ которая является ее фунуциональным аналогом. Здесь приводится лишь краткий список основных опций команды test.

-r file возвращает успех если файл существует и доступен для чтения.

-w file возвращает успех если файл существует и доступен для записи.

-x file возвращает успех если файл существует и выполняемый.

-f file возвращает успех если это регулярный файл.

-d file возвращает успех если это директория.

-c file возвращает успех если это специальный файл.

-s file возвращает успех если файл имеет ненулевой размер.

-h file возвращает успех если это симлинк.

-z s1 возвращает успех если длинна строки s1 нулевая.

-n s1 возвращает успех если длинна строки s1 ненулевая.

s1 = s2 проверка двух строк на равенство.

s1 != s2 проверка двух строк на неравенство

s1 возвращает успех если строка s1 непустая

n1 -eq n2 Алгебраическая проверка двух чисел n1 и n2 на равенство. Помимо –eq есть еще ряд опций для алгебраического сравнения такие как -ne, -gt, -ge, …

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

! отрицание

-a Бинарный И

-o Юинарный ИЛИ (-а имеет приоритет больший чем –о)

( expr ) Группировка выражений скобками

Ввод данных.

Для ввода иданных в скрипт можно воспользоваться командой

read [parameter …]

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

Примечание: знак $ перед именем параметра в команде read ставить не нужно.

Циклы.

Очень часто при составлении скриптов простого последовательного выполнения бывает недостаточно. Необходимы механизмы которые позволяли бы выполнять команды с изменяющимися параметрами. Для этих целей шелл предоставляет в распоряжение три цикличекие конструкции: циклы for,while и untill.

Цыкл for

Этот тип циклов позволяет выполнять один и тот же набор команд каждый раз с новыми значениями полученными из списка параметров. Он имеет следующий формат:

for parameter [ in wordlist ] do command-list done

где parameter это любое имя параметра, wordlist – один или несколько значений последовательно присваиваемых параметру, command-list – набор команд выполняемых при каждом проходе цикла. wordlist может быть либо просто набором аргументов разделенных пробелом, либо командой шелла которая генерирует сама аргументы. Например следующий скрипт:

for i in 1 2 3 4 5 do if mkdir $i then echo “directory $i was created” fi done

создает последовательно директории с именами 1 2 3 4 5 и в случае успешного создания директории выдает сообщение. Следующий скрипт:

for i in `ls a*` do cp $i /tmp echo “$i was copied” done

копирует все файлы начинающиеся с буквы a из текущего каталога в каталог
/tmp.

Цикл while

while command-list1 do command-list2 done

этот цикл запускает команды из списка command-list1, и если последняя команда из списка выполнилась успешно (код возврата равен 0) то начинают выполняться команды из списка command-list2, в противном случае цикл заканчивается. Цикл из следующего примера:

while [ -r $1 ] do echo “processing $1” cat $1 >> summary shift done

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

Цикл util

until command-list1 do command-list2 done

конструкция этого цикла полностью аналогична циклу while за исключением того что тело цикла (набор команд command-list2) выполняется как минимум один раз не зависимо от успешности выполнения условия цикла (набор команд command-list1).

Оператор case

Оператор case является расширением стандартного условного оператора if.
Если есть условие при котором может реализовываться множество вариантов то вместо серии операторов if лучше использовать один case.

case parameter in pattern1 [ | pattern2 …] ) command-list1 ;; pattern2 [ | pattern3 …] ) command-list2 ;;
… esac

шаблоны pattern определяют варианты параметра parameter. При совпадении параметра с одним из шаблонов будет выполнен соответствующий список команд command-list. В квадратных скобках ([ | pattern2…] ) указаны дополнительные варианты разделенные символом ( | ) которые может принимать parameter помимо основного. Заканчивается список шаблонов скобкой. Более понятней структура этого оператора станет после рассмотрения примера:

case $i in

-d | -c ) mkdir dir1 echo “directory dir1 was created” ;;

-r ) rmdir dir1 echo “directory dir1 was removed” ;;

* ) echo “invalid option” ;; esac

В этом примере скрипт получив при запуске один из аргументов –d или –c попытается создать директорию с именем dir1 , получив аргумент –r попытается ее стереть. Во всех остальных случаях (шаблон *) он выдаст предупреждение о неправильном аргументе.

Примечание: обратите внимание на то что порядок следования гшаблонов в операторе case имеет большое значение. Так если строку

* ) echo “invalid option” ;;

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

Команда . (точка)

Каждый раз когда Вы запускаете шелл программы, создается еще одна копия шелла в которой они выполняются. Поэтому если Вы написали шелл скрипт, то все переменные “живут” только во время выполнения скрипта. Если вы хотите чтобы все переменные из шелл программы были в вашем текущем окружении запускать скрипт нужно в текущем шеле, это достигается использованием команды . (точка).

. scriptname

Команда eval eval [arg …]

Аргументы читаються и соединяются в одну команду. Затем эта команда выполняется шеллом и статус выхода команды возвращается как результат команды eval. Если аргументы в команде отсутствуют или пустые то команда возвращает нулевой статус.
В качестве примера рассмотрим два скрипта:

d=’date &’ ; $d и d=’eval date &’ ; $d

первый из них не выполнится так как команда date воспримет символ & как аргумент а не как признак запуска в фоновом режиме, в результате чего первый скрипт не выполнится в отличии от второго.

Использование метасимволов.

Во всех конструкциях циклов и операторе case возможно использование метасимволов. Например скрипт из примера оператора цикла for

for i in `ls a*` do cp $i /tmp echo “$i was copied” done

можно переписать в более простом виде

for i in a* do cp $i /tmp echo “$i was copied” done

результат будет один и тот же.

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

Разделители && и ||

Это условные разделители. При разделении двух команд с помощью && вторая команда выполнится лишь в том случае когда первая завершится успешно. При разделении команд с помощью || вторая выполнится лишь тогда когда первая закончилась неуспешно (код возврата не равен нулю).
Например при выполнении скрипта:

test –d /usr/tools && cd /usr/tools

test –d /usr/tools || echo “directory doesn’t exist”

вход в директорию /usr/tools будет произведен только при ее наличии, в противном случае будет выдано сообщение о ее отсутствии.

Определение функций

Для сокращения обьема шелл программ и упрощения их понимания и сопровждения шелл допускает введение и использование функций. Для опредения функции используется следующий синтаксис:

name () { list; }

где name – это имя функции, а list – список команд из которых состоит тело функции. Ниже приведен пример функции возвращающей 0 если аргумент переданный ей является директорией и 1 в противном случае.

dir_test () { if [ -d $1 ] then echo “$1 is a directory” return 0 else echo “$1 is not directory” return 1 fi;

}

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

name [ parameter … ]

например в нашем случае это можно сделать так

dir_test /usr/bin/sh

Перенаправление ввода-вывода

Как было сказано выше для перенаправления ввода-вывода используються символы (> перенаправление вывода, >> перенаправление вывода с добавлением в файл и < перенаправление ввода). Кроме этого существует еще ряд конструкций, одна из которых:

word is found

> mark

These words will be printed the cat command until the «mark» word is found

$

Если перед строчкой word стоит минус то все символы табуляции в начале строк будут вырезаны.

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

& цифра

При этом задействуется файловый дискриптор ассоциированый с указаной цифрой. В большинстве программ со стандартным вводом связан дискриптор 0, со стандартным выводом дискриптор 1, и со стандартным потоком ошибок дискриптор 2. Все программы которые работают друг с другом через пайпы по умолчанию пользуються дискрипторами 0 и 1. Наиболее часто используемые перенаправления это 1>&2 и 2>&1. Рассмотрим следующий пример из которого станет понятен смысл этих конструкций:

$ ls /no/such/file > out

/no/such/file not found

$ cat out

$

$ ls /no/such/file >out 2>&1

$ cat out

/no/such/file not found

$

первая команда пытается вывести листинг не суцествующего файла перенаправив стандартный вывод в файл out. Файл out при этом оказывется пустым т.к. сообщение об ошибке выводится в стандартный поток ошибок и появляется на терминале. Вторая команда объединяет стандартный поток ошибок со стандартным выводом который перенаправлен в файл out. При этом сообщения об ошибке попадают в файл, о чем свидетельствует команда cat.

Команда exec exec [arg …]

Эта команда выполняет замещение текущего шела новым шелом или программой.
Разница между простым запуском шела и запуском через exec становится очевидной на следующем примере:

$ ksh

$ ps

PID TTY TIME COMMAND

2125 pts/0 0:00 ksh

2094 pts/0 0:00 sh

2126 pts/0 0:00 ps

$

$ exec ksh

$ ps

PID TTY TIME COMMAND

2127 pts/0 0:00 ps

2094 pts/0 0:00 ksh

$

Команда expr expr expression { +, -, *, /, *, =, >, >=, = operand2 )

|Операци|Описание |
|я | |
|> |Больше |
|< |Меньше |
|>= |Больше или равно |
|> |Правый битовый сдвиг |
| file Append commands to file.
>@ file Record-all debugger commands & output to file.
>>@ file Append all debugger commands & output to file.

«>>» is equivalent to «>» for the next four commands.
> Show status of current recording file.
>@ Show status of current record-all file.
>(t | f | c) Turn recording on (t), or off (f), or close the recording file (c).
>@(t | f | c) Turn record-all on (t), or off (f), or close the record-all file (c).

Misc: ss file Save (breakpoint, macro, assertion) state. tc Toggle case sensitivity in searches.

Repeat previous command.
~ Repeat previous command.
! [command-line] Execute shell (with or without commands). q Quit debugger.
$addr Unary operator, address of object.
$sizeof Unary operator, size of object.
$in Unary boolean operator, execution in procedure.
# [text] A comment.
I Print debugger status.
M [(t | c) [expr [; expr …]]] Print or set (text or core) maps. tM Toggle between default and modifiable core maps.

VARIABLES

var Search current procedure and globals. class::var Search class for variable.
[[class]::]proc:[class::]var Search procedure for variable.
[[class]::]proc:depth:[class::]var Search procedure at depth on stack.
:var or ::var Search for global variable only.
. Shorthand for last thing you looked at.
$var Define or use special variable.
$result Return value of last cmd line procedure call.
$signal Current child process signal number.
$lang Current language for expression evaluation.
$depth Default stack depth for local variables.
$print Display mode for character data.
$line Current source line number.
$malloc Debugger memory allocation (bytes).
$step Instr. count in non-debug before free-run.
$cplusplus C++ feature control flags.
$regname Hardware registers.
$fpa Treat fpa sequence as one instruction.(S300 only)
$fpa_reg Address register for fpa sequences.
(S300 only)

LOCATIONS

line source line & code address (if any)
#label » file[:line] «
[file:]proc[:proc[…]][:line|#label] «
[class]::proc[:line|#label] » proc#line code address (if any)
[class]::proc#line » name@shared_lib Address of name in shared library

FORMATS

A format has the form [count]formchar[size]. formchar’s are: a String at address.
(b | B) Byte in decimal (either way).
(c | C) (Wide) character.
(d | D) (Long) decimal.
(e | E) E floating point notation (as double).
(f | F) F floating point notation (as double).
(g | G) G floating point notation (as double). i Machine instruction (disassembly).
(k | K) Formatted structure display (with base classes). n «Normal» format, based on type.
(o | O) (Long) octal. p Print name of procedure containing address.
(r | R) Print template of object (with base classes). s String from pointer.
S Formatted structure display.
(t | T) Print type of object (with base classes).
(u | U) (Long) unsigned decimal.
(w | W) Wide character string (at address).
(x | X) (Long) hexadecimal.
(z | Z) (Long) binary.

Size can be a number or one of the following: b 1 byte (char) s 2 bytes (short) l 4 bytes (long)
D 8 bytes (double — floating point formats only)
L 16 bytes (long double — floating point only)

Системные вызовы и взаимодействие с UNIX.

В этой главе речь пойдет о процессах. Скомпилированная программа хранится на диске как обычный нетекстовый файл. Когда она будет загружена в память компьютера и начнет выполняться — она станет процессом.
UNIX — многозадачная система (мультипрограммная). Это означает, что одновременно может быть запущено много процессов. Процессор выполняет их в режиме разделения времени — выделяя по очереди квант времени одному процессу, затем другому, третьему… В результате создается впечатление параллельного выполнения всех процессов (на многопроцессорных машинах параллельность истинная). Процессам, ожидающим некоторого события, время процессора не выделяется. Более того, «спящий» процесс может быть временно откачан (т.е. скопирован из памяти машины) на диск, чтобы освободить память для других процессов. Когда «спящий» процесс дождется события, он будет
«разбужен» системой, переведен в ранг «готовых к выполнению» и, если был откачан будет возвращен с диска в память (но, может быть, на другое место в памяти!). Эта процедура носит название «своппинг» (swapping).
Можно запустить несколько процессов, выполняющих программу из одного и того же файла; при этом все они будут (если только специально не было предусмотрено иначе) независимыми друг от друга. Так, у каждого пользователя, работающего в системе, имеется свой собственный процесс- интерпретатор команд (своя копия), выполняющий программу из файла /bin/csh
(или /bin/sh).
Процесс представляет собой изолированный «мир», общающийся с другими
«мирами» во Вселенной при помощи: a) Аргументов функции main: void main(int argc, char *argv[], char *envp[]);
Если мы наберем команду

$ a.out a1 a2 a3 то функция main программы из файла a.out вызовется с argc = 4 /* количество аргументов */ argv[0] = «a.out» argv[1] = «a1» argv[2] = «a2» argv[3] = «a3» argv[4] = NULL
По соглашению argv[0] содержит имя выполняемого файла из которого загружена эта программа*. b) Так называемого «окружения» (или «среды») char *envp[], продублированного также в предопределенной переменной extern char **environ;
Окружение состоит из строк вида

«ИМЯПЕРЕМЕННОЙ=значение»
Массив этих строк завершается NULL (как и argv). Для получения значения переменной с именем ИМЯ существует стандартная функция char *getenv( char *ИМЯ );
Она выдает либо значение, либо NULL если переменной с таким именем нет. c) Открытых файлов. По умолчанию (неявно) всегда открыты 3 канала:

ВВОД В Ы В О Д

FILE * stdin stdout stderr соответствует fd 0 1 2 связан с клавиатурой дисплеем

#include main(ac, av) char **av; { execl(«/bin/sleep», «Take it easy», «1000», NULL);

}
Эти каналы достаются процессу «в наследство» от запускающего процесса и связаны с дисплеем и клавиатурой, если только не были перенаправлены. Кроме того, программа может сама явно открывать файлы (при помощи open, creat, pipe, fopen). Всего программа может одновременно открыть до определенное количество файлов в зависииости от настройки ядра. d) Процесс имеет уникальный номер, который он может узнать вызовом int pid = getpid(); а также узнать номер «родителя» вызовом int ppid = getppid();
Процессы могут по этому номеру посылать друг другу сигналы: kill(pid /* кому */, sig /* номер сигнала */); и реагировать на них signal (sig /*по сигналу*/, f /*вызывать f(sig)*/); e) Существуют и другие средства коммуникации процессов: семафоры, сообщения, общая память, сетевые коммуникации. f) Существуют некоторые другие параметры (контекст) процесса: например, его текущий каталог, который достается в наследство от процесса-«родителя», и может быть затем изменен системным вызовом chdir(char *имя_нового_каталога);
У каждого процесса есть свой собственный текущий рабочий каталог. К
«прочим» характеристикам отнесем также: управляющий терминал; группу процессов (pgrp); идентификатор (номер) владельца процесса (uid), идентификатор группы владельца (gid), реакции и маски, заданные на различные сигналы; и.т.п. g) Издания других запросов (системных вызовов) к операционной системе
(«богу») для выполнения различных «внешних» операций. h) Все остальные действия происходят внутри процесса и никак не влияют на другие процессы и устройства («миры»). В частности, один процесс НИКАК не может получить доступ к памяти другого процесса, если тот не позволил ему это явно (механизм shared memory); адресные пространства процессов независимы и изолированы (равно и пространство ядра изолировано от памяти процессов).
Операционная система выступает в качестве коммуникационной среды, связывающей «миры»-процессы, «миры»-внешние устройства (включая терминал пользователя); а также в качестве распорядителя ресурсов «Вселенной», в частности — времени (по очереди выделяемого активным процессам) и пространства (в памяти компьютера и на дисках).
Уже неоднократно упоминали «системные вызовы». Что же это такое? С точки зрения Си-программиста — это обычные функции. В них передают аргументы, они возвращают значения. Внешне они ничем не отличаются от написанных нами или библиотечных функций и вызываются из программ одинаковым с ними способом.
С точки же зрения реализации — есть глубокое различие. Тело функции- сисвызова расположено не в нашей программе, а в резидентной (т.е. постоянно находящейся в памяти компьютера) управляющей программе, называемой ядром операционной системы*.
Поведение всех программ в системе вытекает из поведения системных вызовов, которыми они пользуются. Даже то, что UNIX является многозадачной системой, непосредственно вытекает из наличия системных вызовов fork, exec, wait и спецификации их функционирования! То же можно сказать про язык Си — мобильность программы зависит в основном от набора используемых в ней библиотечных функций (и, в меньшей степени, от диалекта самого языка, который должен удовлетворять стандарту на язык Си). Если две разные системы предоставляют все эти функции (которые могут быть по-разному реализованы, но должны делать одно и то же), то программа будет компилироваться и работать в обоих системах, более того, работать в них одинаково.
Сам термин «системный вызов» как раз означает «вызов системы для выполнения действия», т.е. вызов функции в ядре системы. Ядро работает в привелегированном режиме, в котором имеет доступ к некоторым системным таблицам*, регистрам и портам внешних устройств и диспетчера памяти, к которым обычным программам доступ аппаратно запрещен (в отличие от MS DOS, где все таблицы ядра доступны пользовательским программам, что создает раздолье для вирусов). Системный вызов происходит в 2 этапа: сначала в пользовательской программе вызывается библиотечная функция-«корешок», тело которой написано на ассемблере и содержит команду генерации программного прерывания. Это — главное отличие от нормальных Си-функций — вызов по прерыванию. Вторым этапом является реакция ядра на прерывание:

1. переход в привелегированный режим;

2. разбирательство, КТО обратился к ядру, и подключение u-area этого процесса к адресному пространству ядра (context switching);

3. извлечение аргументов из памяти запросившего процесса;

4. выяснение, ЧТО же хотят от ядра (один из аргументов, невидимый нам — это номер системного вызова);

5. проверка корректности остальных аргументов;

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

7. вызов тела требуемого системного вызова — это обычная Си-функция в ядре;

8. возврат ответа в память процесса;

9. выключение привелегированного режима;
10. возврат из прерывания.
Во время системного вызова (шаг 7) процесс может «заснуть», дожидаясь некоторого события (например, нажатия кнопки на клавиатуре). В это время ядро передаст управление другому процессу. Когда наш процесс будет
«разбужен» (событие произошло) — он продолжит выполнение шагов системного вызова.
Большинство системных вызовов возвращают в программу в качестве своего значения признак успеха: 0 — все сделано, (-1) — сисвызов завершился неудачей; либо некоторое содержательное значение при успехе (вроде дескриптора файла в open(), и (-1) при неудаче. В случае неудачного завершения в предопределенную переменную errno заносится номер ошибки, описывающий причину неудачи (коды ошибок предопределены, описаны в include- файле и имеют вид Eчтото). Заметим, что при УДАЧЕ эта переменная просто не изменяется и может содержать любой мусор, поэтому проверять ее имеет смысл лишь в случае, если ошибка действительно произошла:

#include /* коды ошибок */ extern int errno; extern char *sys_errlist[]; int value; if((value = sys_call(…)) < 0 ){ printf(«Error:%s(%d)n», sys_errlist[errno], errno ); exit(errno); /* принудительное завершение программы */

}
Предопределенный массив sys_errlist, хранящийся в стандартной библиотеке, содержит строки-расшифровку смысла ошибок (по-английски). Посмотрите описание функции per- ror().

Время в UNIX.

Ниже приведены примеры как узнавать время:
. В системе UNIX время обрабатывается и хранится именно в виде числа секунд; в частности текущее астрономическое время можно узнать системным вызовом

#include

#include time_t t = time(NULL); /* time(&t); */
Функция struct tm *tm = localtime( &t ); разлагает число секунд на отдельные составляющие, содержащиеся в int-полях структуры: tm_year год (надо прибавлять 1900) tm_yday день в году 0..365 tm_mon номер месяца 0..11 (0 — Январь) tm_mday дата месяца 1..31 tm_wday день недели 0..6 (0 — Воскресенье) tm_hour часы 0..23 tm_min минуты 0..59 tm_sec секунды 0..59
Номера месяца и дня недели начинаются с нуля, чтобы вы могли использовать их в качестве индексов: char *months[] = { «Январь», «Февраль», …, «Декабрь» }; printf( «%sn», months[ tm->tm_mon ] );

Часто бывает нужда передавать значения времени в одной строке
Вот пример программы которая преобразовывает в ремя в такой формат:
/* Mon Jun 12 14:31:26 2000 */

#include

#include main() { /* команда date */ time_t t = time(NULL); char *s = ctime(&t); printf(«%s», s);

}
UNIX-машины имеют встроенные таймеры (как правило несколько) с довольно высоким разрешением. Некоторые из них могут использоваться как «будильники» с обратным отсчетом времени: в таймер загружается некоторое значение; таймер ведет обратный отсчет, уменьшая загруженный счетчик; как только это время истекает — посылается сигнал процессу, загрузившему таймер.
Вот как, к примеру, выглядит функция задержки в микросекундах (миллионных долях секунды). Примечание: эту функцию не следует использовать вперемежку с функциями sleep и alarm.

#include

#include

#include

void do_nothing() {}

/* Задержка на usec миллионных долей секунды (микросекунд) */ void usleep(unsigned int usec) {

struct itimerval new, old;

/* struct itimerval содержит поля: struct timeval it_interval; struct timeval it_value;

Где struct timeval содержит поля: long tv_sec; — число целых секунд long tv_usec; — число микросекунд

*/ struct sigaction new_vec, old_vec;

if (usec == 0) return;

/* Поле tv_sec содержит число целых секунд.

Поле tv_usec содержит число микросекунд.

it_value — это время, через которое В ПЕРВЫЙ раз таймер «прозвонит», то есть пошлет нашему процессу сигнал SIGALRM.

Время, равное нулю, немедленно остановит таймер.

it_interval — это интервал времени, который будет загружаться в таймер после каждого «звонка»

(но не в первый раз).

Время, равное нулю, остановит таймер после его первого «звонка».

*/ new.it_interval.tv_sec = 0; new.it_interval.tv_usec = 0; new.it_value.tv_sec = usec / 1000000; new.it_value.tv_usec = usec % 1000000;

/* Сохраняем прежнюю реакцию на сигнал SIGALRM в old_vec, заносим в качестве новой реакции do_nothing()

*/ new_vec.sa_handler = do_nothing; sigemptyset(&new_vec.sa_mask); new_vec.sa_flags = 0;

sigaction(SIGALRM, &new_vec, &old_vec);

/* Загрузка интервального таймера значением new, начало отсчета.

* Прежнее значение спасти в old.

* Вместо &old можно также NULL — не спасать.

*/ setitimer(ITIMER_REAL, &new, &old);

/* Ждать прихода сигнала SIGALRM */ sigpause(SIGALRM);

/* Восстановить реакцию на SIGALRM */ sigaction(SIGALRM, &old_vec, (struct sigaction *) 0); sigrelse(SIGALRM);

/* Восстановить прежние параметры таймера */ setitimer(ITIMER_REAL, &old, (struct itimerval *) 0);

}

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

#include

#include /* _SC_CLK_TCK */

#include /* SIGALRM */

#include /* не используется */

#include /* struct tms */

struct tms tms_stop, tms_start; clock_t real_stop, real_start;

clock_t HZ; /* число ticks в секунде */

/* Засечь время момента старта процесса */ void hello(void){ real_start = times(&tms_start);

}

/* Засечь время окончания процесса */ void bye(int n){ real_stop = times(&tms_stop);

#ifdef CRONO

/* Разность времен */ tms_stop.tms_utime -= tms_start.tms_utime; tms_stop.tms_stime -= tms_start.tms_stime;

#endif

/* Распечатать времена */ printf(«User time = %g seconds [%lu ticks]n», tms_stop.tms_utime / (double)HZ, tms_stop.tms_utime); printf(«System time = %g seconds [%lu ticks]n», tms_stop.tms_stime / (double)HZ, tms_stop.tms_stime); printf(«Children user time = %g seconds [%lu ticks]n», tms_stop.tms_cutime / (double)HZ, tms_stop.tms_cutime); printf(«Children system time = %g seconds [%lu ticks]n», tms_stop.tms_cstime / (double)HZ, tms_stop.tms_cstime); printf(«Real time = %g seconds [%lu ticks]n»,

(real_stop — real_start) / (double)HZ, real_stop — real_start); exit(n);

}

/* По сигналу SIGALRM — завершить процесс */ void onalarm(int nsig){ printf(«Выход #%d ================n», getpid()); bye(0);

}

/* Порожденный процесс */ void dochild(int n){ hello(); printf(«Старт #%d ================n», getpid()); signal(SIGALRM, onalarm);

/* Заказать сигнал SIGALRM через 1 + n*3 секунд */ alarm(1 + n*3);

for(;;){} /* зациклиться в user mode */

}

#define NCHLD 4 int main(int ac, char *av[]){ int i;

/* Узнать число тиков в секунде */

HZ = sysconf(_SC_CLK_TCK); setbuf(stdout, NULL);

hello(); for(i=0; i < NCHLD; i++) if(fork() == 0) dochild(i); while(wait(NULL) > 0); printf(«Выход MAIN =================n»); bye(0); return 0;

}

Сигналы.

Процессы в UNIX используют много разных механизмов взаимодействия. Одним из них являются сигналы.
Сигналы — это асинхронные события. Что это значит? Сначала объясним, что такое синхронные события: я два раза в день подхожу к почтовому ящику и проверяю — нет ли в нем почты (событий). Во-первых, я произвожу опрос —
«нет ли для меня события?», в программе это выглядело бы как вызов функции опроса и, может быть, ожидания события. Во-вторых, я знаю, что почта может ко мне прийти, поскольку я подписался на какие-то газеты. То есть я предварительно заказывал эти события.
Схема с синхронными событиями очень распространена. Кассир сидит у кассы и ожидает, пока к нему в окошечко не заглянет клиент. Поезд периодически проезжает мимо светофора и останавливается, если горит красный. Функция Си пассивно «спит» до тех пор, пока ее не вызовут; однако она всегда готова выполнить свою работу (обслужить клиента). Такое ожидающее заказа (события) действующее лицо называется сервер. После выполнения заказа сервер вновь переходит в состояние ожидания вызова. Итак, если событие ожидается в специальном месте и в определенные моменты времени (издается некий вызов для ОПРОСА) — это синхронные события. Канонический пример — функция gets, которая задержит выполнение программы, пока с клавиатуры не будет введена строка. Большинство ожиданий внутри системных вызовов — синхронны. Ядро ОС выступает для программ пользователей в роли сервера, выполняющего сисвызовы
(хотя и не только в этой роли — ядро иногда предпринимает и активные действия: передача процессора другому процессу через определенное время
(режим разделения времени), убивание процесса при ошибке, и.т.п.).
Сигналы — это асинхронные события. Они приходят неожиданно, в любой момент времени — вроде телефонного звонка. Кроме того, их не требуется заказывать
— сигнал процессу может поступить совсем без повода. Аналогия из жизни такова: человек сидит и пишет письмо. Вдруг его окликают посреди фразы — он отвлекается, отвечает на вопрос, и вновь продолжает прерванное занятие.
Человек не ожидал этого оклика (быть может, он готов к нему, но он не озирался по сторонам специально). Кроме того, сигнал мог поступить когда он писал 5-ое предложение, а мог — когда 34-ое. Момент времени, в который произойдет прерывание, не фиксирован.
Сигналы имеют номера, причем их количество ограничено — есть определенный список допустимых сигналов. Номера и мнемонические имена сигналов перечислены в includeфайле и имеют вид SIGнечто. Допустимы сигналы с номерами 1..NSIG-1, где NSIG определено в этом файле. При получении сигнала мы узнаем его номер, но не узнаем никакой иной информации: ни от кого поступил сигнал, ни что от нас хотят. Просто «звонит телефон». Чтобы получить дополнительную информацию, наш процесс должен взять ее из другого известного места; например — прочесть заказ из некоторого файла, об имени которого все наши программы заранее
«договорились». Сигналы процессу могут поступать тремя путями:
От другого процесса, который явно посылает его нам вызовом kill(pid, sig); где pid — идентификатор (номер) процесса-получателя, а sig — номер сигнала. Послать сигнал можно только родственному процессу — запущенному тем же пользователем.
От операционной системы. Система может посылать процессу ряд сигналов, сигнализирующих об ошибках, например при обращении программы по несуществующему адресу или при ошибочном номере системного вызова. Такие сигналы обычно прекращают наш процесс.
От пользователя — с клавиатуры терминала можно нажимом некоторых клавиш послать сигналы SIGINT и SIGQUIT. Собственно, сигнал посылается драйвером терминала при получении им с клавиатуры определенных символов. Так можно прервать зациклившуюся или надоевшую программу.
Процесс-получатель должен как-то отреагировать на сигнал. Программа может: проигнорировать сигнал (не ответить на звонок); перехватить сигнал (снять трубку), выполнить какие-то действия, затем продолжить прерванное занятие; быть убитой сигналом (звонок был подкреплен броском гранаты в окно);
В большинстве случаев сигнал по умолчанию убивает процесс-получатель.
Однако процесс может изменить это умолчание и задать свою реакцию явно. Это делается вызовом signal:

#include void (*signal(int sig, void (*react)() )) ();
Параметр react может иметь значение:
SIG_IGN сигнал sig будет отныне игнорироваться. Некоторые сигналы (например

SIGKILL) невозможно перехватить или проигнорировать.
SIG_DFL восстановить реакцию по умолчанию (обычно — смерть получателя). имя_функции Например void fr(gotsig){ ….. } /* обработчик */

… signal (sig, fr); … /* задание реакции */

Тогда при получении сигнала sig будет вызвана функция fr, в которую в качестве аргумента системой будет передан номер сигнала, действительно вызвавшего ее gotsig==sig. Это полезно, т.к. можно задать одну и ту же функцию в качестве реакции для нескольких сигналов:

… signal (sig1, fr); signal(sig2, fr); …

После возврата из функции fr() программа продолжится с прерванного места.

Перед вызовом функции-обработчика реакция автоматически сбрасывается в реакцию по умолчанию SIG_DFL, а после выхода из обработчика снова восстанавливается в fr. Это значит, что во время работы функции- обработчика может прийти сигнал, который убьет программу.
Приведем список некоторых сигналов; полное описание посмотрите в документации. Колонки таблицы: G — может быть перехвачен; D — по умолчанию убивает процесс (k), игнорируется (i); C — образуется дамп памяти процесса: файл core, который затем может быть исследован отладчиком adb; F — реакция на сигнал сбрасывается; S — посылается обычно системой, а не явно. сигнал G D C F S смысл

SIGTERM + k — + — завершить процесс

SIGKILL — k — + — убить процесс

SIGINT + k — + — прерывание с клавиш

SIGQUIT + k + + — прерывание с клавиш

SIGALRM + k — + + будильник

SIGILL + k + — + запрещенная команда

SIGBUS + k + + + обращение по неверному

SIGSEGV + k + + + адресу

SIGUSR1, USR2 + i — + — пользовательские

SIGCLD + i — + + смерть потомка
Сигнал SIGILL используется иногда для эмуляции команд с плавающей точкой, что происходит примерно так: при обнаружении «запрещенной» команды для отсутствующего процессора «плавающей» арифметики аппаратура дает прерывание и система посылает процессу сигнал SIGILL. По сигналу вызывается функция- эмулятор плавающей арифметики (подключаемая к выполняемому файлу автоматически), которая и обрабатывает требуемую команду. Это может происходить много раз, именно поэтому реакция на этот сигнал не сбрасывается.
SIGALRM посылается в результате его заказа вызовом alarm() (см. ниже).
Сигнал SIGCLD посылается процессу-родителю при выполнении процессом- потомком сисвызова exit (или при смерти вследствие получения сигнала).
Обычно процессродитель при получении такого сигнала (если он его заказывал) реагирует, выполняя в обработчике сигнала вызов wait (см. ниже). По- умолчанию этот сигнал игнорируется.
Реакция SIG_IGN не сбрасывается в SIG_DFL при приходе сигнала, т.е. сигнал игнорируется постоянно.
Вызов signal возвращает старое значение реакции, которое может быть запомнено в переменную вида void (*f)(); а потом восстановлено.
Синхронное ожидание (сисвызов) может иногда быть прервано асинхронным событием (сигналом), но об этом ниже.

Деления просесса

Системный вызов fork() (вилка) создает новый процесс: копию процесса, издавшего вызов. Отличие этих процессов состоит только в возвращаемом fork- ом значении:

0 — в новом процессе. pid нового процесса — в исходном.
Вызов fork может завершиться неудачей если таблица процессов переполнена.
Простейший способ сделать это: main(){ while(1) if( ! fork()) pause();

}
Одно гнездо таблицы процессов зарезервировано — его может использовать только суперпользователь (в целях жизнеспособности системы: хотя бы для того, чтобы запустить программу, убивающую все эти процессы-варвары).

Пайпы и FIFO-файлы.

Процессы могут обмениваться между собой информацией через файлы. Существуют файлы с необычным поведением — так называемые FIFO-файлы (first in, first out), ведущие себя подобно очереди. У них указатели чтения и записи разделены. Работа с таким файлом напоминает проталкивание шаров через трубу
— с одного конца мы вталкиваем данные, с другого конца — вынимаем их.
Операция чтения из пустой «трубы» проиостановит вызов read (и издавший его процесс) до тех пор, пока кто-нибудь не запишет в FIFOфайл какие-нибудь данные. Операция позиционирования указателя — lseek() — неприме- нима к
FIFO-файлам. FIFO-файл создается системным вызовом

#include

#include mknod( имяФайла, S_IFIFO | 0666, 0 ); где 0666 — коды доступа к файлу. При помощи FIFO-файла могут общаться даже неродственные процессы.
Разновидностью FIFO-файла является безымянный FIFO-файл, предназначенный для обмена информацией между процессом-отцом и процессом-сыном. Такой файл
— канал связи как раз и называется термином «труба» или pipe. Он создается вызовом pipe: int conn[2]; pipe(conn);
Если бы файл-труба имел имя PIPEFILE, то вызов pipe можно было бы описать как mknod(«PIPEFILE», S_IFIFO | 0600, 0); conn[0] = open(«PIPEFILE», O_RDONLY); conn[1] = open(«PIPEFILE», O_WRONLY); unlink(«PIPEFILE»);
При вызове fork каждому из двух процессов достанется в наследство пара дескрипторов: pipe(conn); fork();

conn[0]———conn[0] процесс A процесс B
Пусть процесс A будет посылать информацию в процесс B. Тогда процесс A сделает: close(conn[0]);

// т.к. не собирается ничего читать write(conn[1], … ); а процесс B close(conn[1]);

// т.к. не собирается ничего писать read (conn[0], … );
Получаем в итоге: conn[1]—->—-FIFO—->——conn[0] процесс A процесс B
Обычно поступают еще более элегантно, перенаправляя стандартный вывод A в канал conn[1] dup2 (conn[1], 1); close(conn[1]); write(1, … ); /* или printf */ а стандартный ввод B — из канала conn[0] dup2(conn[0], 0); close(conn[0]); read(0, … ); /* или gets */
Это соответствует конструкции

$ A | B записанной на языке СиШелл.
Файл, выделяемый под pipe, имеет ограниченный размер (и поэтому обычно целиком оседает в буферах в памяти машины). Как только он заполнен целиком
— процесс, пишущий в трубу вызовом write, приостанавливается до появления свободного места в трубе. Это может привести к возникновению тупиковой ситуации, если писать программу неаккуратно. Пусть процесс A является сыном процесса B, и пусть процесс B издает вызов wait, не закрыв канал conn[0].
Процесс же A очень много пишет в трубу conn[1]. Мы получаем ситуацию, когда оба процесса спят:
A потому что труба переполнена, а процесс B ничего из нее не читает, так как ждет окончания A;
B потому что процесс-сын A не окончился, а он не может окончиться пока не допишет свое сообщение.
Решением служит запрет процессу B делать вызов wait до тех пор, пока он не прочитает ВСЮ информацию из трубы (не получит EOF). Только сделав после этого close(conn[0]); процесс B имеет право сделать wait.
Если процесс B закроет свою сторону трубы close(conn[0]) прежде, чем процесс A закончит запись в нее, то при вызове write в процессе A, система пришлет процессу A сигнал SIGPIPE — «запись в канал, из которого никто не читает».

Нелокальный переход.

Теперь поговорим про нелокальный переход. Стандартная функция setjmp позволяет установить в программе «контрольную точку»*, а функция longjmp осуществляет прыжок в эту точку, выполняя за один раз выход сразу из нескольких вызванных функций (если надо)*. Эти функции не являются системными вызовами, но поскольку они реализуются машинно-зависимым образом, а используются чаще всего как реакция на некоторый сигнал, речь о них идет в этом разделе. Вот как, например, выглядит рестарт программы по прерыванию с клавиатуры:

#include

#include jmp_buf jmp; /* контрольная точка */

/* прыгнуть в контрольную точку */ void onintr(nsig){ longjmp(jmp, nsig); }

main(){ int n; n = setjmp(jmp); /* установить контрольную точку */ if( n ) printf( «Рестарт после сигнала %dn», n); signal (SIGINT, onintr); /* реакция на сигнал */ printf(«Началиn»);

…

} setjmp возвращает 0 при запоминании контрольной точки. При прыжке в контрольную точку при помощи longjmp, мы оказываемся снова в функции setjmp, и эта функция возвращает нам значение второго аргумента longjmp, в этом примере — nsig.
Прыжок в контрольную точку очень удобно использовать в алгоритмах перебора с возвратом (backtracking): либо — если ответ найден — прыжок на печать ответа, либо если ветвь перебора зашла в тупик — прыжок в точку ветвления и выбор другой альтернативы. При этом можно делать прыжки и в рекурсивных вызовах одной и той же функции: с более высокого уровня рекурсии в вызов более низкого уровня (в этом случае jmp_buf лучше делать автоматической переменной — своей для каждого уровня вызова функции).

Разделяемая память

shmget создает новый сегмент разделяемой памяти или находит существующий сегмент с тем же ключом shmat подключает сегмент с указанным дескриптором к виртуальной памяти обращающегося процесса shmdt отключает от виртуальной памяти ранее подключенный к ней сегмент с указанным виртуальным адресом начала shmctl служит для управления параметрами, связанными с существующим сегментом После подключения сегмента разделяемой памяти к виртуальной памяти процесса, он может обращаться к соответствующим элементам памяти с использованием обычных машинных команд чтения и записи shmid = shmget(key, size, flag); size определяет желаемый размер сегмента в байтах если в таблице разделяемой памяти находится элемент, содержащий заданный ключ, и права доступа не противоречат текущим характеристикам процесса, то значением системного вызова является дескриптор существующего сегмента реальный размер сегмента можно узнать с помощью системного вызова shmctl иначе создается новый сегмент с размером не меньше установленного в системе минимального размера сегмента разделяемой памяти и не больше установленного максимального размера создание сегмента не означает немедленного выделения под него основной памяти откладывается до выполнения первого системного вызова подключения сегмента к виртуальной памяти некоторого процесса при выполнении последнего системного вызова отключения сегмента от виртуальной памяти соответствующая основная память освобождается virtaddr = shmat(id, addr, flags); id — это ранее полученный дескриптор сегмента addr — желаемый процессом виртуальный адрес, который должен соответствовать началу сегмента в виртуальной памяти virtaddr — реальный виртуальный адрес начала сегмента не обязательно совпадает со значением прямого параметра addr если addr == 0, ядро выбирает наиболее удобный виртуальный адрес начала сегмента shmdt(addr); addr — виртуальный адрес начала сегмента в виртуальной памяти, ранее полученный от системного вызова shmat shmctl(id, cmd, shsstatbuf); cmd идентифицирует требуемое конкретное действие важна функция уничтожения сегмента разделяемой памяти

Семафоры

Обобщение классического механизма семафоров общего вида Диекстры
Целесообразность обобщения сомнительна
Обычно использовался облегченный вариант двоичных семафоров
Известен алгоритм реализации семафоров общего вида на основе двоичных
Семафор в ОС UNIX: значение семафора идентификатор процесса, который хронологически последним работал с семафором число процессов, ожидающих увеличения значения семафора число процессов, ожидающих нулевого значения семафора
Три системных вызова: semget для создания и получения доступа к набору семафоров semop для манипулирования значениями семафоров semctl для выполнения управляющих операций над набором семафоров id = semget(key, count, flag); key, flag и id — обычный смысл count — число семафоров в наборе семафоров, обладающих одним и тем же ключом индивидуальный семафор идентифицируется дескриптором набора семафоров и номером семафора в наборе если набор семафоров с указанным ключом уже существует, то число семафоров в группе можно узнать с помощью системного вызова semctl oldval = semop(id, oplist, count); id — дескриптор группы семафоров oplist — массив описателей операций над семафорами группы count — размер этого массива возвращается значение последнего обработанного семафора
Элемент массива oplist: номер семафора в указанном наборе семафоров операция флаги
Если проверка прав доступа проходит нормально указанные в массиве oplist номера семафоров не выходят за пределы общего размера набора семафоров для каждого элемента массива oplist значение семафора изменяется в соответствии со значением поля «операция»
Значение поля операции положительно значение семафора увеличивается на единицу все процессы, ожидающие увеличения значения семафора, активизируются
(пробуждаются)
Значение поля операции равно нулю если значение семафора равно нулю, выбирается следующий элемент массива oplist иначе число процессов, ожидающих нулевого значения семафора, увеличивается на единицу обратившийся процесс переводится в состояние ожидания (усыпляется)
Значение поля операции отрицательно
(1) его абсолютное значение меньше или равно значению семафора это отрицательное значение прибавляется к значению семафора если значение семафора стало нулевым, то ядро активизирует все процессы, ожидающие нулевого значения этого семафора
(2) значение семафора меньше абсолютной величины поля операции число процессов, ожидающих увеличения значения семафора увеличивается на единицу текущий процесс откладывается
Стремление добиться возможности избегать тупиковых ситуаций
Системный вызов semop выполняется как атомарная операция
Флаг IPC_NOWAIT заставляет ядро ОС UNIX не блокировать текущий процесс лишь сообщать в ответных параметрах о возникновении ситуации, приведшей бы к блокированию процесса semctl(id, number, cmd, arg); id — это дескриптор группы семафоров number — номер семафора в группе cmd — код операции arg — указатель на структуру, содержимое которой интерпретируется в зависимости от операции
Можно уничтожить индивидуальный семафор в указанной группе

Очереди сообщений

Четыре системных вызова: msgget для образования новой очереди сообщений или получения дескриптора существующей очереди msgsnd для посылки сообщения (его постановки в очередь сообщений) msgrcv для приема сообщения (выборки сообщения из очереди) msgctl для выполнения управляющих действий msgqid = msgget(key, flag);
Сообщения хранятся в виде связного списка
Декскриптор очереди сообщений — индекс в массиве заголовков очередей сообщений
В заголовке очереди хранятся: указатели на первое и последнее сообщение в данной очереди число сообщений общий размер в байтах сообщений, находящихся в очереди идентификаторы процессов, которые последними послали или приняли сообщение через данную очередь временные метки последних выполненных операций msgsnd, msgrsv и msgctl

msgsnd(msgqid, msg, count, flag); msg — это указатель на структуру, содержащую целочисленный тип сообщения и символьный массив

. count — задает размер сообщения в байтах flag определяет действия ядра при выходе за пределы допустимых размеров внутренней буферной памяти
Условия успешной постановки сообщения в очередь: процесс должен иметь право на запись в очередь длина сообщения не должна превосходить верхний предел общая длина сообщений не должна превосходить установленного предела тип сообщения должен быть положительным целым числом
Процесс продолжает свое выполнение
Ядро активизирует (пробуждает) все процессы, ожидающие поступления сообщений из очереди
Превышается верхний предел суммарной длины сообщений обратившийся процесс откладывается до разгрузки очереди но есть флаг IPC_NOWAIT (как для семафоров) count = msgrcv(id, msg, maxcount, type, flag); msg — указатель на структуру данных в адресном пространстве пользователя для размещения принятого сообщения maxcount — размер области данных (массива байтов) в структуре msg type специфицирует тип сообщения, которое желательно принять flag указывает ядру, что следует предпринять, если в указанной очереди сообщений отсутствует сообщение с указанным типом count — реальное число байтов, переданных пользователю
Значением параметра type является нуль выбирается первое сообщение копируется в заданную пользовательскую структуру данных процессы, отложенные по причине переполнения очереди сообщений, активизируются если значение параметра maxcount оказывается меньше реального размера сообщения, ядро не удаляет сообщение из очереди и возвращает код ошибки если задан флаг MSG_NOERROR, то выборка сообщения производится, и в буфер пользователя переписываются первые maxcount байтов сообщения
Значение type есть положительное целое число выбирается первое сообщение с таким же типом
Значение type есть отрицательное целое число выбирается первое сообщение, значение типа которого меньше или равно абсолютному значению type
В очереди отсутствуют сообщения, соответствующие спецификации type процесс откладывается до появления в очереди требуемого сообщения но есть флаг IPC_NOWAIT msgctl(id, cmd, mstatbuf); опрос состояния описателя очереди сообщений изменение его состояния уничтожение очереди сообщений

1. Старт системы
2. run levels
3. Остановка системы
4. Конфигурирование ядра системы
5. Инсталирование периферии на примере ленточного накопителя.
6. Инсталирование софта
7. Управление процессами

Старт системы.

В самом начале, после включения питания выполяется последовательность команд записанная в Boot ROM машины. Boot ROM выполняет общую диагностику и проводит инициализацию устройств необходимую для дальнейшей загрузки операционной системы. В задачи Boot ROM кода входит:

. Определение типа процессора

. Инициализация и тест таймеров

. Нахождение и инициализация видео консоли

. Загрузка конфигурации с EEPROM

. Инициализации системы ввода-вывода включая пользовательский интерфейс и аудио

. Распечатка на консоли copyright и других баннеров, типа процессора

EEPROM статуса, количества памяти

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

. Тест и инициализация системы прямого доступа к памяти (DMA)

. Поиск и распечатка информации о встроенных интерфейсных платах

. Тест и инициализация SCSI интерфеса и интерфейса локольной сети

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

При этом возможен вариант запгрузки как с SCSI устройства (диск,
CDROM, лента, …) так и через локальную сеть. Загрузочный диск должен быть предварительно сконфигурирован. Так как обьем Boot ROM не может быть большим, в его задачи входит загрузка вторичного загрузчика операционной системы. Для этого загрузочный диск должен быть инициализирован определенным образом. Помимо стандартной файловой системы он еще должен содержать так называемы LIF (Logical Interchange Fomat) раздел в котором записан вторичный загрузчик и ряд необходимых утилит. Посмотреть состав LIF блока можно с помощью команды lifls принимающей в качестве аргумента имя блочного устройства диска:

lifls /dev/dsk/c0t5d0

ISL AUTO HPUX LABEL

Для создания LIF области используется команда lifinit
(инициализируються только диски которые не являются подмонтированными файловыми системами). Для записи в или копирования из LIF области используется утилита lifcp .Например, команда:

lifcp /dev/dsk/c0t5d0:ISL a

копирует файл ISL из LIF области в файл с именем а. Во время инсталяции LIF область создается автоматически и необходимости работы с ней практически не появляется, за исключением случаев сбоев.

После завершения всех тестов и выполнения поиска возможных устройств загрузки в и в случае если параметр SECURE записанный в EEPROM равен OFF возможен вход в меню загрузки boot ROM при нажатии на клавишу ESC. Если
SECURE=OFF и процесс загрузки не прерывался нажатием ESC а также EEPROM параметр AUTOBOOT=ON, boot ROM попытается загрузить из LIF области вторичный загрузчик ISL. Устройство загрузки при этом выбирается из EEPROM параметра PRIMARY BOOT PATH. В случае неудачной загрузки, boot ROM будет грузить ISL из устройства имя которого записано в EEPROM параметре
ALTERNATE BOOT PATH. Если не удается загрузиться и от туда, система выйдет в boot ROM меню. Для поиска всех возможных устройств загрузки boot ROM имеет команду SEARCH. Для загрузки с какогото конкретного устройства найденого командой SEARCH используется команда BOOT:

boot [device_path] [isl]

запущеная без аргументов она приводит к загрузке системы из устройства адрес которого содержится в PRIMARY BOOT PATH. Если указан аргумент isl то система загрузит вторичный загрузчик ISL в интерактивный режим. Основные случаи когда необходима загрузка не с основного устройства перечислены ниже:

. На основном диске нет загрузочного ядра

. LIF область диска повреждена

. Корневая файловая система ОЧЕНЬ сильно запорчена

Примечание: В том случае если SECURE=ON (безопасный режим) нет никакой возможности попасть в boot ROM меню за исключением как физически отключить устройства первичной и вторичной загрузки.

Если был выбран интерактивный режим загрузки ISL то последний после загрузки, не станет автоматически загружать ядро системы а перейдет в диалоговый режим. В этом режиме есть ряд команд влияющих на загрузку системы. Например по команде 700SUPPORT возможна загрузка с CDROM специальной версии ядра системы предназначеной для восстановления системы в том случае если ядро основной системы не загружается. Список утилит которые доступны для запуска ISL можно увидеть по команде LS. Основная утилита –
HPUX, предназначенная для загрузки ядра системы. Для того чтоб посмоьреть содержимое директории /stand на устройстве загрузки по умолчанию нужно воспользоваться командой:

ISL> HPUX ll disk (;0) /stand/

При загрузке ядра возможно указание файла ядра отличного от того что используется по умолчанию (/stand/vmunix) для загрузки а также запустить ядро с определенными параметрами. Например команда:

ISL> hpux /stand/vmunix.prev

загружает ядро с именем /stand/vmunix.prev (эту команду используют в тех случаях когда вновь собранное ядро не хочет по какимто причинам запускаться и нужно загрузить старое ядро).

А команда:

ISL> hpux –is /stand/vmunix

загружает ядро с именем /stand/vmunix в однопользовательский режим.
Ситуации прикоторых необходима загрузка в однопользовательский режим:

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

. поврежден файл /etc/inittab

. какой то из загрузочных скриптов по каким то причинам зависает

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

. Находит и монтирует корневую файловую систему

. Запускает процесс init и если ядру не было указано дополнительных аргументов относительно run-level то init переводит систему на default run-level (обычно это многопорльзовательский режим работы)

Run-levels.

После успешного монтирования корневой файловой системы ядро запускает процесс init. Отличительной особенностью этого процесса является то что его создает непосредственно ядро,он имеет PID=1 и не имеет родительского процесса, в отличии от остальных процессов получающихся в следствие системного вызова fork(). Конфигурациооный файл программы init называется
/etc/inittab. Приведем его формат:

Id:run-levels:action:process

где

id От одно до четырехбуквенный индекс который идентифицирует

строку файла inittab.

run-level определяет run-level.в одной строке может быть несколько run-levels. run-levels определяются как цифры от 0 до 6. Когда boot init пытается измнить run-level, все процессы которые не имеют run-level поля равному изменяемому run-level получают предупреждающий сигнал (SIGTERM) и те которые не завершили работу по истечению 20-ти секундного интервала получат сигнал (SIGKILL).Если run level не определен, то это подразумевает все run levels, с 0 до 6.

Это поле также может принимать три других значения “a”,
“b” и “c”.

Строки имеющие эти значения в поле run-level выполняются только когда пользовательский init процесс запрашивает их.

(независимо от текущего run level системы).

Они в корне отличается от run levels в которые boot init никогда не входит a, b, or c. Также выполнение процессов из этих run- levels никогда не меняет текущий run level системы.

Более того, процессы запущенные с rul-level a, b, или c не терминируются когда boot init изменяет run-level системы.

Процессы терминируются лишь когда соответствующая строка inittab помечена как off в поле action или полностью удалена из inittab или система загружается в однопользовательский режим.

action определяет действия этой строки файла, которые могут принимать следующие значения:

boot выполнять процесс только во время чтения inittab исключительно при загрузке системы. Boot init стартует процесс не дожидаясь его окончания и по его завершении не рестартует его заново.

bootwait выполнять процесс только во время чтения inittab исключительно при загрузке системы.

Boot init стартует процесс дожидается его окончания и по его завершении не рестартует его заново.

initdefault процесс выполняется только во время начальной загрузки. Boot init использует эту строку если она существует для того чтобы определить в какой run-level входить в самом начале. Если в этой строке указано несколько run-levels то запускается с наибольшим номером. Если run- level не указан то стартует по умолчанию run- level c номером 6. Если строка initdefaul не найдена в /etc/inittab то при старте системы будет запрошено на какой run-level запускать систему.

off если процесс асоцированный с этой строкой в данный момент запущен то послать ему предупреждающий сигнал (SIGTERM) и подождать 20 секунд его завершения, после чего принудительно завершить его сигналом SIGKILL. Если процесс не запущен – игнорировать эту строку.

once Когда boot init стартует run level который совпадает с указанным в этой строке он не дожидается его окончания и после окончания не запускает его вновь. Если boot init запускает новый run level но процесс все еще в запущеном состоянии от предыдущего run-level то процесс не перестартовывается.

ondemand Эта инструкция есть синоним инструкции respawn за исключением того что она используется только с “a”, “b”, или “c” значениями run-level.

powerfail Запустить процесс асоциированный с этой строкой только в том случае если boot init получит сигнал power-fail signal (SIGPWR).

powerwait Запустить процесс асоциированный с этой строкой только в случае если boot init получит power- fail signal (SIGPWR) и ждать пока процесс завершит работу перед запуском любых других процессов из inittab.

respawn Если процесс не запущен, то запустить его не дожидаясь окончания (прподолжив сканирование inittab). После завершения процесса запустить его заново. Если процесс запущен – то ничего не делать продолжив сканирование inittab.

sysinit процессы содержащиеся в строках этого типа будут запускаться перед тем как boot init попытается получить доступ к системной консоли.

Это подразумевает что процессы будут запускаться только для инициализации устройств на которых boot init может получать run level информацию. Boot init ожидает завершение процессов запущенных с этим параметром.

wait Когда boot init запускает run-level с этим параметром, он ждет завершения процесса. Любые сканирования файла inittab пока boot init находится на томже run level являються причиной игнорирования этой строки в файле inittab.

process это шелл скрипт который запускается из шела созданного системным вызовом fork() как «sh -c ‘exec command’.

Запуск init может сопровождаться следующими аргументами:

/sbin/init [0|1|2|3|4|5|6|S|s|Q|q|a|b|c]

агрументы означают следующее:

0-6 перевод системы на уровень от 0 до 6

a|b|c выполнение действий из файла из строк inittab eкоторые помечены как специальный run-level a, b, или c без изменения значения текущего run-level.

Q|q реинициализация файла inittab без изменения значения текущего run-level

S|s перевод системы в однопользовательский режим, при этом логическая системная консоль /dev/syscon изменяется на тот терминал с которого была запущена команда.

Остановка системы

Для остановки системы Вы должны иметь права администратора

(пользователь с UID=0). Различают два вида остановки системы, первый это перевод системы в однопользовательский режим, при котором все пользовательские и системные процессы работающие в многопользовательском режиме завершаются, и доступ к машине остается лишь через логическую системную консоль (тот терминал с которого была запущена команда). Такой режим часто бывает необходим во время бэкапа или восстановления данных, при установке нового оборудования или програмного обеспечения. После этого для возврата назад в многопользовательский режим нужно воспользоваться командой init.

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

SAM. При использовании SAM в разделе Routine Tasks выбрать пункт

System shutdown а затем тип шатдауна:

. Halt system — полная остановка системы

. Reboot — перезагрузка системы

. Go to single user state — перевод системы в однопользовательский режим

При использовании hpux комманд необходимо выполнить переход в корневой каталог (т.к. нельзя размонтировать файловые системы которые используются просцессами), а затем выполнить команду shutdown с одним из параметров:

. cd /

. shutdown –h now — немедленная остановка системы

. shutdown –r now — немедленная перезагрузка системы

. shutdown — немедленный перевод системы в однопользовательский режим

. shutdown –h 300 — остановка системы через пять минут.

При этом раз в всем залогиненым пользователям

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

Команда shutdown переключает логическую системную консоль /dev/syscon изменяется на тот терминал с которого была запущена команда. shutdown использует программу /usr/sbin/wall для посылки сообщения о остановке или перезагрузки системы на все терминалы на которых есть асктивные пользователи. По умолчанию лишь администратор системы обладает правами на остановку системы, однако существует файл /etc/shutdown.allow который позволяет выполнять остановку системы (но не перевод в однопользовательский режим) пользователям не имеющих администраторских прав. В этом файле указывается имя пользователя и имя системы (для случая кластеров) которую пользователь может остановить. Симвод # исполдьзуется для комментариев, символ + обозначает любое имя. Например:

# пользователь user1 может останавливать систему systemA и systemB systemA user1 systemB user1

# администратор может останавливать все системы

+ root

# любой пользователь может остановить систему systemC systemC +

Отсутствие файла /etc/shutdown.allow или отсутствие в нем администратора
(root) не может помешать администратору остановить систему.
После запуска, shutdown выполняет:

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

. установку real UID в 0

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

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

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

Так же как и при старте, во время остановки системы используется скрипт
/etc/rc . Если стартовый скрипт линк (например /sbin/rcN.d/S123test) в последовательности N имеет стоп действие, соответствующий остановочный скрипт должен быть помещен в последовательность
N-1 (/sbin/rcN-1.d/K200test). Действия запущенные на уровне N должны быть остановлены на уровне N-1. Поэтому остановка системы (т.е., переход с уровня 3 напрямую в уровень 0) приведет к корректному завершению всех подсистем путем вызова соответствующих остановочных скриптов.

Помомо команды shutdown существует команда rebooot которая выполняет похожие действия. Например reboot –h вызывает остановку системы а reboot без параметров перезагрузку. Между командами reboot и shutdown есть принципиальная разница. reboot всем процессам в системе (кроме самой себя
() посылает 9-й сигнал, который процесс не может перехватить или обработать и после этого вызывает остановку или перезагрузку системы. Поэтому не рекомендуется использовать эту команду в системах где есть критически важные приложения (например сервера баз данных) которые требуют корректной остановки.

Конфигурирование ядра системы

Для большинства систем вполне хватает стандартной конфигурации ядра, однако в ряде случаев оговоренных ниже возникает необходимость переконфигурирования ядра. К этим случаям можно отнести:

. Добавление или удаление периферии (драйверов устройств) а также псевдодрайверов. В случае удаления периферии удалять драйвер устройства из ядра совсем не обязательно, но крайне желательно, т.к. в этом случае ядро будет меньше по обьему и будет работать более эффектино. Прежде чем удалять драйвер устройства убедитесь не зависят ли от него драйвера других устройств проверив файлы в директории /usr/conf/master.d в таблицах зависимости в секции

DRIVER_DEPENDENCY. Особое внимание следует обратить на файл core- hpux.

. Изменение системных параметров (tunable parameters). В тех случаях когда система работает с большим количеством пользователей часто возникает необходимость изменения стандартных системных параметров.

Эти параметры определяются в секции TUNABLE в файлах

/usr/conf/master.d. Большинство из них находится в файле core-hpux.

. Инсталирование специализированного програмного обеспечения HP

(подсистем). Если вы добавляете в систему специализированное програмное обеспечение например поддержку LAN, ATM, FDDI и.т.п в этом случае также требуется модификация ядра.

. Добавление файловых систем отлдичных от HFS.

. Добавление, удаление или модификация swap и (или) dump областей, устройства консоли или корневой файловой системы.

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

. Символьные драйвера. Работа с этими драйверами происходит в побайтном режиме без использования буферного кэша. К таким драйверам можно отнести драйвера таких устройств как драйвера последовательных портов, терминалов, магнитных лент …

. Блочные драйвера. Этот тип драйверов позволяет проводить обмен блоками данных. Так например обмен с диском происходит фиксироваными блоками (секторами), даже в том случае если идет операция с данными количество которых меньше размера блока всеравно физически будет прочитан или записан один блок. При работе эти драйвера используют системный буферный кэш.

. Драйвера низкого уровня (raw drivers) Этот тип драйверов производит обмен с блочными устройствами напрямую минуя буферный кэш с ситемы.

Кроме драйверов устройств существует множество других драйверов не имеющих непосредственного отношения к периферии компьютера. Такие драйвера называются псевдодрайверами. Вот примеры некоторых из них:

/dev/kmem обеспечивает доступ к физической памяти компьютера

/dev/mem обеспечивает доступ к виртуальной памяти ядра

/dev/null нулевое устройство. Призаписи в него данные удаляются, а при чтении считывается 0 байт

lvm (Logical Volume Manager) обеспечивает построение и доступ к логическим дискам

Драйвера адресуются старшим номером устройства (major number). Помимо него также существует младший номер (minor number) для адресации одного из клонов драйвера. Например в случае с драйвером диска младший номер может означать номер диска.

$ ls -l /dev/dsk/ total 0 brw-r—r— 1 root sys 31 0x002000 Jun 10 1996 c0t2d0 brw-r—r— 1 root sys 31 0x005000 Jun 10 1996 c0t5d0 brw-r—r— 1 root sys 31 0x006000 Jun 10 1996 c0t6d0

$ ls -l /dev/rdsk/ total 0 crw-r—— 1 root sys 188 0x002000 Jun 10 1996 c0t2d0 crw-r—— 1 root sys 188 0x005000 Jan 3 16:47 c0t5d0 crw-r—— 1 root sys 188 0x006000 Jun 10 1996 c0t6d0

Первая команда выводит файлы блочных дисковых устройств, вторая файлы raw дисковых устройств. Как создаются файлы устройств будет показано чуть позже. Доступ к драйверу осуществляется через специальную структуру данных называемою коммутатором устройств каждый элемент которой содержит указатели на соответствующие функции драйвера (d_open(), d_close(), d_strategy(), d_read(), d_write(), d_ioctl, d_xpoll(), d_intr(), …), так называемые точки входа. Старший номер является указателем на элемент коммутатора устройств.
Блочные и символьные устройства имеют свои собственные коммутаторы. Список драйверов можно посмотреть воспользовавшись программой lsdev.

Изменение системных параметров

К одним из основных системных параметров относится параметр MAXUSERS который является макросом на основании которого вычисляются множество других параметров (например nproc вычисляется как 20+8*MAXUSERS). Этот параметр не указывает, как может показаться на первый взгляд на максимальное число пользователей в системе. На системах с небольшим количеством пользователей (рабочие станции) он обычно равен 32, на больших системах (T500) его значение может превышать 200. Перечислим краткий список основных системных параметров:

|Параметр |Значение|Описание |
| |по | |
| |умолчани| |
| |ю | |
|dbc_max_pc|50 |Максимальный размер буферного кэша в |
|t | |процентах от обьема RAM |
|maxdsiz |67108864|Максимальный размер сегмента данных |
|maxssiz |8388608 |Максимальный размер стека |
|maxtsiz |67108864|Максимальный размер сегмента кода |
|maxfiles |60 |Максимальное количество открытых файлов |
| | |на процесс |
|maxuprc |75 |Максимальное число процессов пользователя|
|maxusers |32 |Макрос через который определяются |
| | |большинство других параметров |
|nfile |2172 |Максимальное число открытых файлов в |
| | |системе |
|nflock |200 |Максимальное количество заблокированных |
| | |файлов |
|npty |60 |Максимальное количество псевдотерминалов |
| | |в системе |
|semmns |128 |Максимальное количество семафоров |
|shmmax |67108864|Максимальный обьем разделяемой памяти |
|shmmni |200 |Максимальное количество идентификаторов |
| | |разделяемой памяти |
|shmseg |120 |Максимальное количество сегментов |
| | |разделяемой памяти на процесс |

Для изменения системных параметров можно воспользоваться утилитой SAM либо выполнить изменения конфигурационных файлов и пересобрать ядро вручную. При использовании SAM после запуска sam необходимо:

. Открыть меню “SAM Kernel Configuration”

. Выбрать “Configurable parameters”

. Выбрать нужный параметр из списка

. Активировать пункт меню “Actions->Modify Configurable Parameter”

. Ввести новое значения параметра

После выхода из раздела “Configurable parameters” SAM предложит создать новое ядро и перезагрузить систему.

Конфигурирование ядра с использованием команд HP-UX.

Для этого необходимо выполнить следующую последовательность действий:

. cd /stand/buil

. /usr/lbin/sysadm/system_prep –v –s system

Этот скрипт сосздает файл system являющийся шаблоном конфигурационного файла ядра

. vi system

Редактируем файл ядра

. mk_kernel –s system

Компилируем ядро. Новое ядро будет содержаться в файле

/stand/build/vmunix_test

. mv /stand/vmunix /stand/vmunix.prev mv /stand/system /stand/system.prev

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

. mv /stand/build/vmunix_test /stand/vmunix mv /stand/build/system /stand

Перемещаем ядро в директорию из которой идет загрузка

. shutdown –r now выполняем перезагрузку системы

Инсталирование периферии

Файлы устройств

Обычно файлы устройств располагаются в каталоге /dev и cуществует специальное соглашение по поводу их имен. Имена файлов устройств как правило маркируются в соответствии со следующим соглашением: c#t#d#[s#] :

c# представляет класс интерфейса или интерфейсной карты.

t# адрес устройства на шине. Обычно он выставляется физически переключателями расположеными на устройстве.

d# номер устройства. (для SCSI устройств это логический номер устройства LUN)

s# необязательный параметр показывающий номер секции устройства.
Например для дисков он показывает номер портиции, 0 – указывает на целый диск.

Утилиты lssf и ioscan могут помочь в определении интерфейса к которому подключено то или иное устройство. Например:

bash-2.04$ lssf /dev/dsk/c0t6d0 sdisk card instance 0 SCSI target 6 SCSI LUN 0 section 0 at address

2/0/1.6.0 /dev/dsk/c0t6d0

bash-2.04$ lssf /dev/null pseudo driver mm minor 0x000002 /dev/null

Системная конфигурация

Утилита ioscan является одной из наиболее полезных утилит для просмотра системной информации. Ее можно использовать для построения аппаратного адреса устройства. В простейшем виде ioscan показывает аппартный путь
(адрес), класс устройства и описание. Опции –u (используемые устройства) или –k (структуры ядра) дают быстрый результат без сканирования оборудования.

# /usr/sbin/ioscan

H/W Path Class Description

============================================= bc

1 graphics Graphics

2 ba Core I/O Adapter

2/0/1 ext_bus Built-in SCSI

2/0/1.2 target

2/0/1.2.0 disk TOSHIBA CD-ROM XM-5401TA

2/0/1.5 target

2/0/1.5.0 disk SEAGATE ST32151N

2/0/1.6 target

2/0/1.6.0 disk SEAGATE ST32151N

2/0/1.7 target

2/0/1.7.0 ctl Initiator

2/0/2 lan Built-in LAN

2/0/4 tty Built-in RS-232C

2/0/6 ext_bus Built-in Parallel Interface

2/0/8 audio Built-in Audio

2/0/10 pc Built-in Floppy Drive

2/0/11 ps2 Built-in Keyboard

4 ba EISA Adapter

5 ba Core I/O Adapter

5/0/1 hil Built-in HIL

5/0/2 tty Built-in RS-232C

8 processor Processor

9 memory Memory

#

Использование ключа –f приводит к выдаче полной информации включая номер интерфейса или интерфейсной карты.

Class I H/W Path Driver S/W State H/W Type
Description

================================================================ bc 0 root CLAIMED
BUS_NEXUS graphics 0 1 graph3 CLAIMED INTERFACE
Graphics ba 0 2 bus_adapter CLAIMED BUS_NEXUS
Core I/O Adapter ext_bus 0 2/0/1 c720 CLAIMED INTERFACE
Built-in SCSI target 0 2/0/1.2 tgt CLAIMED DEVICE disk 0 2/0/1.2.0 sdisk CLAIMED DEVICE
TOSHIBA CD-ROM XM-5401TA target 1 2/0/1.5 tgt CLAIMED DEVICE disk 1 2/0/1.5.0 sdisk CLAIMED DEVICE

SEAGATE ST32151N target 2 2/0/1.6 tgt CLAIMED DEVICE disk 2 2/0/1.6.0 sdisk CLAIMED DEVICE

SEAGATE ST32151N target 3 2/0/1.7 tgt CLAIMED DEVICE ctl 0 2/0/1.7.0 sctl CLAIMED DEVICE

Initiator lan 0 2/0/2 lan2 CLAIMED INTERFACE

Built-in LAN tty 0 2/0/4 asio0 CLAIMED INTERFACE

Built-in RS-232C ext_bus 1 2/0/6 CentIf CLAIMED INTERFACE
Built-in Parallel Interface audio 0 2/0/8 audio CLAIMED INTERFACE
Built-in Audio pc 0 2/0/10 fdc CLAIMED INTERFACE

Built-in Floppy Drive ps2 0 2/0/11 ps2 CLAIMED INTERFACE
Built-in Keyboard ba 2 4 eisa CLAIMED
BUS_NEXUS EISA Adapter ba 1 5 bus_adapter CLAIMED BUS_NEXUS
Core I/O Adapter hil 0 5/0/1 hil CLAIMED
INTERFACE Built-in HIL tty 1 5/0/2 asio0 CLAIMED INTERFACE

Built-in RS-232C processor 0 8 processor CLAIMED PROCESSOR
Processor memory 0 9 memory CLAIMED MEMORY
Memory

Использование ключа –n приводит к тому что ioscan дополнительно выдает информацию о файле устройства:

target 0 2/0/1.2 tgt CLAIMED DEVICE disk 0 2/0/1.2.0 sdisk CLAIMED DEVICE TOSHIBA CD-ROM
XM-5401TA

/dev/dsk/c0t2d0 /dev/rdsk/c0t2d0 target 1 2/0/1.5 tgt CLAIMED DEVICE disk 1 2/0/1.5.0 sdisk CLAIMED DEVICE SEAGATE
ST32151N

/dev/dsk/c0t5d0 /dev/rdsk/c0t5d0

В том случае когда драйвер устройства не может быть автоматически сконфигурирован и соответствующий файл устройства оказывается несозданным приходится создавать его вручную с помощью команд mkfs или mknod. Ядро взаимодействует с аппаратным обеспечением ассоциируя имя драйвера и аппаратный адрес. Стандартный интерфейс HP-UX к драйверам поставляется вместе с библиотекой /usr/conf/lib/libhp-ux.a. Ядро распознает интерфейсные драйвера и драйвера устройств через младшие и старшие нгомера “прошитые“ в файлах устройств.

Старший номер (major number)

Старший номер, как уже было сказано раньше является индексом в таблице переключателя устройств ядра. Для нахождения правильного старшего номера можно воспользоваться программой lsdev. Она считывает заголовки и список драйверов сконфигурированных в ядре с ихними блочными и символьными старшими номерами. Номера выводятся в десятичной форме, -1 означает либо то что устройство является модулем, драйвер несконфигурирован либо драйвер не поддерживает какогото из режимов (блочного или символьного).

Младший номер (minor number)

Младший номер определяет собой: расположение устройства и его драйвер- зависимые характеристики. Некоторые примеры младших номеров файлов устройств приведено ниже. Более полную информацию можно почерпнуть из руководства “Configuring HP-UX for Peripherals”.

SCSI Disk device. Рассмотрим что означает младший номер 0x023000 у SCSI устройства.

|bits |8-11 |12-15 |16-19 |20-23 |24-27 |28-31 |
|Binar|0000 |0010 |0011 |0000 |0000 |0000 |
|y | | | | | | |
|hex |0 |2 |3 |0 |0 |0 |

0000 0010 Первые восемь бит идентифицируют интерфейс или интерфейсную карту

0011 SCSI адрес диска

оставшиеся биты нулевые.

SCSI ленточный накопитель.

| |Bits |20-23 |24-27 |28-31 |
| |16-19 | | | |
|Binary|SCSI |SCSI LUN |24 – поведение как у BSD систем |
| |номер | |при закрытии |
| | | |25 – без перемотки |
| | | |26 – конфигурационный метод (если|
| | | |1 то биты от 27 до 31 означают |
| | | |индекс, если 0 то плотность |
| | | |записи) |
| | | |27-31 Индекс/плотность записи |

Создавать файлы устройств можно с помощью команды mknod. Она имеет следующий синтаксис:

mknod file_name [c|b] major minor

например

mknod /dev/null c 3 0x000002

8. Инсталирование периферии на примере ленточного накопителя.

Прежде чем перейти к включению ленточного накопителя нужно убедится в том что его SCSI id не совпадает ни с одним из уже установленных устройств
(диски, CD-ROM, …). После физического подключения накопителя к SCSI шине необходимо в ядро. В случае использования SAM для этого необходимо войти в раздел Kernel Configuration -> Drivers, в списке драйверов найти stape, и активировать его выбрав опцию Actions -> Add driver to Kernel. После выхода из окна конфигурации ядра SAM предложит перестроить я дро и перегрузить компьютер, также создаст все необходимые файлы устройств в каталоге
/dev/rmt. Все тоже самое можно сделать используя командыв hpux как это было указано выше. В качестве имя драйвера нужно использовать stape.

# cd /stand/build

# /usr/lbin/sysadm/system_prep –v –s system

# vi system

# /usr/sbin/mk_kernel –s system

# mv /stand/system /stand/system.prev

# mv /stand/vmunix /stand/vmunix.prev

# mv /stand/build/system /stand/system.prev

# mv /stand/build/vmunix_test /stand/vmunix

# shutdown –r now

# ioscan –f –C tape

Class I H/W Path Driver S/W State H/W Type
Description

================================================================ tape 0 2/0/1.3.0 stape CLAIMED DEVICE HP
HP35480A

# lsdev | grep tape

205 -1 stape tape

# mkdir /dev/rmt

# cd /dev/rmt

# mknod 0m c 205 0x003000

# mknod 0mn c 205 0x003040

# mknod 0mnb c 205 0x0030c0

Примечание: младшие номера для файла устройств можно узнать из файла
/usr/include/sys/mtio.h (раздел Masks for minor number bits )
9. Инсталирование софта

Для работы с программными пакетами существует целая серия команд. Эти команды носят название SD-UX команды. Приведем список основных из них:

swintsall инсталирование программных пакетов swremove удаление программных пакетов swlist список инсталированого програмного обеспечения swacl просмотр и модификация прав для защиты программных компонент

Управление процессами

Что такое процесс ?

Процесс это запущенная программа обслуживаемая такими компонентами ядра как планровщик задач и подсистемой управления памятью. Процесс состоит из сегмента кода, данных и стека. С процессом ассоциировано два стека – пользовательский и системный. В дополнение к этому роцесс идентифицируется

. програмными данными (переменные, массивы, записи …)

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

. идентификатором пользователя и группы PID, GID

. информацией о открытых файлах

. текущей рабочей директорией

Взаимоотношения процессов

Процессы в системе постороены по иерархическому принципу родитель-потомок.
Каждый процесс (за исключением init) имеет одного родителя, но каждый родитель может иметь несколько потомков. Процесс потомок наследует окружение родителя (переменные окружения, открытые файлы, рабочую директорию). Все процессы за исключением init, pagedaemon, и swapper) принадлежат к группам процессов.

Процесс ID и родительский процесс ID.

Во время создания процесса HP-UX назначает ему уникальный номер известный как процесс ID (PID), именно по этому номеру ядро идентифицирует процесс при выполнении системных вызовов. Помомо PID процесс имеет параметр как
PPID (PID родителя). Используя программу ps можно посмотреть эти параметры:

$ ps -f

UID PID PPID C STIME TTY TIME COMMAND torry 3865 3699 2 13:35:43 ttyp3 0:00 ps -f torry 3699 3698 0 12:58:21 ttyp3 0:00 ksh

Идентификаторы пользователя и группы. (реальные и эффективные)

Помимо PID и PPID процесс имеет еще ряд идентификационных номеров:

* реальный идентификатор пользователя (a real user ID)

* реальный идентификатор группы (a real group ID)

* эффективный идентификатор пользователя (effective user ID)

* эффективный идентификатор группы effective group ID.

Реальный идентификатор пользователя это целое число показывающее владельца процесса. Реальный идентификатор группы это целое число показывающее группу к которой принадлежал пользователь создатель процесса. Комманда id показывает оба этих значения.

%id uid=513(torry) gid=20(users)

% grep 513 /etc/passwd torry:EqqHevH:513:20:Torry Ho,[44MY],474-1969
,:/home/torry:/usr/bin/csh

Эффективный идентификатор пользователя и группы процесса позволяет процессу получать доступ к файлам или выполнять программы как пользователь имеющим
ID равным эффективному. Обычно реальный и эффективные идентификаторы процессов совпадают, но не всегда. Когда эффективный идентификатор равен нулю, процесс начинает выполнять системные вызовы как администратор системы.
Эффективный идентификатор пользователя и группы остаються установленными до:

* окончания процесса.

* пока они не заменяться при выполнении системного вызова exec() программы c установленными битами setuid или setgid.

* пока эффективный, реальный или сохраненные идентификаторы группы и пользователя не будут установлены системными вызовами setuid(), setgid(), setresuid().

Группы процессов

Каждый процесс за исключением системных процессов таких как init и swapper принадлежат к группе процессов. Когда созхдается задание, шелл присваивает всем процессам в задании одну и туже группу процессов. Сигналы при этом могут распостраняться на все процессы в группе, в этом и заключается преимущество управления заданиями. Каждая группа процессов идентифицируется целым числом которое называется Process Group ID (PGID). PGID у группы процессов равен PID лидера группы – создателя группы. Все процессы в группе имеют одинаковый GID. PGID не может быть использован системой пока живет группа процессов. Время жизни группы процессов определяется как период времени между созданием группы и когда процесс покидает группу. Процесс покидает группу если:

* когда другой процесс вызывает wait() или waitpid() функции на неактивный процесс.

* при вызове setsid или setpgid системных вызовов.

Списки доступа группы

Каждый процесс имеет до NGROUPS_MAX списков групп к которым он может принадлежать.
NGROUPS_MAX определено в /usr/include/limits.h, и обычно равняется 20.
Процессу разрешается получать доступ к файлам с групповымим правами любой из списка групп. Списки доступа. Групповые права доступа контролируются командой chgrp.

Сессии

Каждый процесс является членом сессии. Все процессы запущенные после логина принадлежат к одной сессии. Процесс принадлежит к той же сессии что и его родитель. Процесс может изменить сессию используя системный вызов setsid(), при этом этот процесс будет являться лидером сессии. Временем жизни сессии будет время с момента ее создания до момента завершения последнего процесса.

Процессы и терминальное взаимодействие.

Каждая сессия имеет управляющий терминал. Лидер сессии подключенный к управляющему терминалу называется еще контрольным процессом. Исключением являются процессы- демоны (cron, inetd, …) которые не имеют управляющего терминала. Все процессы принадлежащих к одной сессии используют управляющий терминал как стандартное устройство ввода, вывода и ошибок. В любой момент времени лишь одна группа процессов в сессии может находится не в фоновом выполнении и она имеет исключительные права на работу с управляющим терминалом.

Попытки чтения фоновой группой процессов

Если процесс из фоновой группы пытается читать из управляющего терминала, этой группе посылается сигнал SIGTTIN, который по умолчанию приостанавливает процесс. В любом случае системный вызов read() возвращает
–1.

Попытки чтения фоновой группой процессов

Если процесс в фоновой группе пытается записать в управляющий терминал, группа процессов получает при этом сигнал SIGTTOU, который по умолчанию останавливает процесс.

Создание процессов

Один процесс может создать другой через:

* паралельное выполнение другой программы

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

На системном уровне процесс создается во время вызова системного вызова fork() или vfork().

Системный вызов fork()

Этот системный вызов создает новый процесс путем клонирования существующего. В старых реализациях HP-UX, система копировала полностью сегмент данных процесса, что негативно сказывалось на скорости и эффективности работы системы. Сейчас реализуется механизм известный как copy-on-write (на самом деле HP-UX реализует механизм copy-on-access), который позволяет использовать общие страницы памяти до момента записи.

Системный вызов vfork()

Приложения которым нужно создать независимый процесс могут делать это более эффективно если вместо fork() будут использовать vfork().Использование vfork оправдано только когда процесс потомок сразуже выполняет exec() или
_exit() системные вызовы. При использовании vfork, потомок использует виртуальное адресное пространство родителя, поэтому оба процесса не могут работать одновременно. Процесс родитель при этом засыпает.

Системный вызов exec()

Очень часто после вызова fork() процесс запускает exec() на выполнение другой программы, при этом происходит перезапись сегмента кода и данных новым процессом.

Открытые файлы

При системных вызовах fork() и vfork() происходит наследование процессом потомков всех открытых файловых дискрипторов. Для системных параметра определяют ограничение на количество открытых файлов на процесс: maxfiles и maxfiles_lim. Параметр maxfiles определяет мягкий лимит как много открытых файлов может иметь процесс. Мягкий лимит наследуется после вызовов fork() vfork(). Параметр maxfiles_lim опреджеляет жесткий лимит на количество открытых файлов на один процесс. maxfiles должен быть меньше или равен maxfiles_lim. Мягкий лимит процесс наследует от своего родителя, который может быть уменьшен или увеличен до жесткого лимита (такое может сделать только процесс с правами администратора) с использованием системного вызова setrlimit().

Завершение процессов

Процесс завершается если:

* Он успешно окончил свое выполнение

* Процесс завершил.себя вызвав системный вызов exit()

* Процесс получил сигнал на с фатальным действием

Когда процесс завершается все открытые файлы завершаются и все занятые ресурсы освобождаются, после чего процесс умирает.
Команды управления процессами.

Управлять процессами можно либо с использованием команд HP-UX либо с использованием утилиты SAM. Наиболее часто используемые команды будут описаны ниже.

Команда ps (process status)

Команда ps показывает следующие параметры процессов:

* идентификатор пользователя User ID

* идентификатор процесса Process ID

* идентификатор родительского процесса Parent process ID

* командную строку породившую процесс

* терминал с которого была запущена комманда

* время (rela time CPU) которое было затрачено процессором на выполнение процесса.

Запущенная без опций она показывает process ID, terminal ID (tty), real CPU time usage, имя команды которую запустил на выполнение пользователь. С ключем –f ps также показывает имя пользователя, PPID, и время с момента когда процесс был fork-нут.

$ ps -f

UID PID PPID C STIME TTY TIME COMMAND torry 3286 2016 9 16:19:03 ttyp1 0:00 ps -f torry 25705 25649 0 08:47:58 ttyp1 0:02 -ksh /home/torry [ksh] torry 2016 25705 0 15:13:02 ttyp1 0:24 vi processes.tag

Опция –e приводит к выдаче информации о всех активных процессах в системе.
Опция -l (long) дополнительно показывает состояние процесса (S), параметр nice (NI), адрес процесса в памяти (ADDR), приоритет (PRI), и размер в блоках (SZ) образа процесса.

$ ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME COMD
1 R 513 11009 7793 5 179 20 d6e200 16 ttyu4 0:00 ps
1 S 0 7792 133 15 154 20 e06100 13 214fb0 ttyu4 0:00 rlogind
1 S 513 7793 7792 16 168 20 df5a80 52 7ffe6000 ttyu4 0:00 csh

Относительные приоритеты процессов — nice и renice

Все процессы имеют приоритет устанавливаемый на основе таких факторов как прльзователь запустивший процесс и в каком окружении запущен процесс: с разделением времени или в реального времени. Комманда nice может быть использована для запуска процесса с более низким чем по умолчанию приоритетом. nice не уменьшает приоритетов уже запущеных процессов.

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

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

top

Периодически показывает информацию о процессах в системе в порядке убывания использования ресурсов. Суммирует состояние системы (среднюю загрузку), использование виртуальной памяти. В отличии от psкоторый дает лишь снимок текущего состояния системы top выдает информацию с периодичностью. На мультипроцессорных системах, top выдает состояние каждого процессора раздельно.

sar

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

vmstat

Выдает информацию об использовании виртуальной памяти и активность CPU.

iostat

Выдает информацию об дисковой активности ввода-вывода, терминальной активности статистику CPU.

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

Процесс может иметь доступ на чтение и запись к своему сегменту данных и стеку но не к другим процессам (за исключением сегментов разделяемой памяти). Процесс обменивается данными с другими процессами либо через системные вызовы либо через разделяемую память.

Приоритеты процесса

Все процессы в HP-UX могут находится в двух режимах: пользовательский режим и режим ядра. Когда процесс переключается в режим ядра (например при системном вызове) он исполняет код ядра и пользуется стеком ядра. В зависимости от приоритета и наличия других процессов процесса планировцик процессов может выделять ему больше или меньше квантов процессорного времени.
Приоритеты можно разделить на две части: диапазон POSIX standard приоритетов и диапазхон HP-UXприоритетов. POSIX standard приоритеты всегда выше чем все другие HP-UX приоритеты. Процесс который имеет меньшее числовое значение приоритета имеет преимущество при выполнении над процессом с большим цифровым значением приоритета. Следующий список выводит по категориям диапазоны приоритетов от большого к маленькому:

1. POSIX standard приоритеты (системный параметр)

POSIX standard приоритеты, известные как RTSCHED приоритеты, являются самыми высокими приоритетами. Количество RTSCHED приоритетов есть системный параметр

(rtsched_numpri), устанавливаемый между 32 и 512 (default 32).

2. приоритеты реального времени (0-127)

Зарезервированы для процессов SCHED_RTPRIO стартующих с системного вызова rtprio()

3. Системные приоритеты (128-177)

Используются системными процессами.

4. Пользовательские приоритеты (178-255)

Устанавливаются пользовательским процессам.

Ядро может изменять приоритеты процессов разделения времени (128-255) но не процессов реального времени (0-127).

Состояние процесса

В процессе своей жизни процесс может менять несколько раз свое состояние.Процессы размиещаются в очередях выполнения планировщика процесса в соответствии с их состоянием как определено в файле
/usr/include/sys/proc.h . События, такие как получение сигнала могут переводить процесс из одного состояния в другое.

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

* idle – процесс простаивает в очереди выполнения планировщика.

* run — процесс выполняется в очереди планировщика либо в пользовательском режиме либо в режиме ядра.

* stopped – процесс остановлен сигналом либо процессом родителем.

* sleep – процесс не выполняется пока он находится в спящем состоянии в очереди

(например он ждет окончания операции ввода-вывода)

* zombie – процесс уже фактически не существует, но так как он оставил для родителя некоторые непрочитанные данные о своем выполнении он не может осуществить завершение.

Когда программа запускает прооцесс, ядро выделяет для него сроку из своей таблицы процессов и процесс находится в idle состоянии. Затем после получения ресурсови попадания в очередь он находится в состоянии run. Если процесс получкает сигнал SIGSTOP или его переводлят в режи трассировки, он переходит в stop состояние. После получения сигнала SIGCONT signal, процесс возвращается в состояние run. Если запущеный процесс ждет освобождение какихто ресурсов (семафор) или завершения операции вво-да вывода – он переходит в спящее состояние. Спящий процесс может быть отсваплен в первую очередь.Как только процесс заканчивает свою работу он переходит в состояние zombie.
1. Файловая система HFS.
2. Менеджер логических дисков LVM
3. Особенности файловой системы VxFS
4. Операции над файловой системой

1. Файловая система HFS.

Одной из испольуемых HP-UX файловых систем является High Performance File
System (HPFS, HFS) известная также как MCKusic или BSD файловая система.
Файловая система это структура данных существующая на дисковых устройствах позволяющая сохранять и получать доступ к информации хранящейся в ней в иерархическом виде. Существует ряд причин исходя из которых информацию хранящуюся на дисковых носителях приходится организовывать в виде нескольких файловых систем, к ним можнно отнестиЖ

. Если суммарный обьем данных превышает обьем поддерживаемый одной файловой системой

. Для увеличения производительности системы, разнося данные имеющие разную структуру (средний размер файла, наличия ограничения на дисковое пространство для пользователей) на разные файловые системы или данные к которым идет частый доступ разносятся на разные физические устройства.

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

В общих чертах файловую систему HP-UX состоит из дерева каталогов
(директорий) расположеных иерархически с корневым каталогом в вершине. Все файловые системы имеют свойство “монтируемости” заключающееся в том что любая файловая система может быть смонтирована (прикреплена) к существующей директории. Любую смонтированную файловую систему кроме корневой можно размонтировать. Монтирование корневой файловой системы осуществляет ядро, сразу же после загрузки.

Структура файловой системы HFS

Все HFS файловые системы имеют в своем составе следующие структуры:

. Главный суперблок

. Набор групп цилиндров

Структуры данных используемые в файловой системе содержатся в файле
/usr/include/sys/fs.h. Первичный суперблок это непрерывный блок данных размеров 8К размещающийся перед началом файловой системы который содержит статическую информацию о файловой системы в момент ее создания (или последнего расширения):

. Размер файловой системы

. Количество inodes которые может хранить файловая система

. Позиция свободного места на диске

. Количество групп цилинров

. Позиции суперблоков, крупп цилиндро, блоков inodes и блоков данных

. Размер блока и фрагмента

Главный суперблок

Помимо этого главный суперблок содержит вспомагательную информацию о том когда последний раз монтировалась, модифицировалась и проверялась файловая система. Потому что главный суперблок содержит исключительно важную информацию о файловой системе, HP-UX всегда хранит его копии в каждой группе цилиндров. Одна из копий загружается в память после загрузки.
Главный суперблок размещается в самом начале файловой системы и каждая группа цилиндпров имеет имеет свою копию суперблока. Таким образом достигается резервирование критически важной информации. Суперблоки групп цилиндров на диске обновляются каждый раз когда выполняется команда sync или когда файловая система размонтируется. В файле /etc/sbtab присутствует запись положения всех суперблоков файловых систем.

Группы цилиндров

Группа цилиндров – это группа дисковых цилиндров идущих подряд. Цилиндр представляет собой совокупность треков каждый из которых размещен на одинаковом расстоянии от центра поверхности дискового носителя. Все треки в цилиндрк доступны за одну операцию чтения/записи дисковой головки. В целях повышения производительности, цилиндры группируются (по умолчанию 16 цилиндров) в группы цилиндров. Каждая группа цилиндров имеет свой набор inodes и свою карту свободного пространства в группе. Такая организация хранения позволяеет минимизировать время поиска данных файла в группе цилиндров. Приведем структуру группы цилиндров:

|Структура |Размер |
|Главный суперблок 1 |8 Кб |
|Запасной суперблок |8 Кб |
|Информация группы |1 блок (4 Кб или 8 |
|цилиндров |Кб) |
|Таблица inodes |Переменный 2 |
|Блоки данных |0 или более блоков 3 |

1 только для первой группы цилиндров

2 см. раздел inodes

3 см. раздел блоки данных

Раздел информации о группе цилиндров хранит динамические параметры группы цилиндров, такие как:

. Количество inodes и блоков данных в группе цилиндров

. Указатели на последний использованый блок, фрагмент и inode

. Количество свободных фрагментов

. Карту использованных inodes

. Карту свободных блоков

Информация о группе цилиндров занимет один блок (размер блока определяется присоздании файловой системы и обычно равен либо четырем либо восьми килобайтам).

Inodes

Кроме хранения информации о состоянии файловой системы, группы цилиндров хранят ключевую информацию о inodes файловой системы – индексам файлов данных (и директорий). Дисковая inode содержит следующую информацию о файле:

. Тип файла и атрибуты доступа

. Количество ссылок на файл

. Владельца и группу файла

. Размер файла в байтах

. Временные метки (время последнего обращения, последней модификации)

. Указатели на блоки файловой системы содержащих данные

Когда файл открыт процессом, информация о его inode находится в памяти ядра
(in-core inode) в сочетании с доаполнительными атрибутами, такими как:

. Статус inode, включая факт блокировки inode, отличается ли in-core inode от дисковой inode в следствие модификации файла, является ли файл точкой монтирования файловой системы …

. Цифровой адрес файловой системы содержащий файл

. Указатель на другие in-core inodes выстроенные в виде списка.

Если inode указывает на специальный (не регулярный) файл, то с ним ассоциируются дополнительные параметры, такие как является ли файл FIFO или pipe, символьным или блочным устройством или же директорией. Когда создается файловая система (команда newfs), создаются inodes. Количество inodes ограничивает количество файлов в файловой системе. При создании файловой системы по умолчанию система подразумевает что в среднем на одну inode припадает 2048 байт данных, что в большинстве случаев является более чем достаточным количеством. Иногда, возможна ситуация когда ядро сигнализирует об ошибке переполнения таблицы in-core inodes (inode: table is full). В этом случае необходимо изменить размер этой таблицы увеличив системный параметр ядра ninode.

Блоки данных

После суперблока, данных о группе цилиндров и таблице inodes идет место зарезервированное под блоки данных. HP-UX поддерживает блоки размером
4,8,16,32 и 64Кб. Размер блока задается при создании файловой системы
(команда newfs). Большой размер блока дает выиграш в скорости передачи данных при работе с большими файламино при этом является причиной неэффективного использования дискового пространства приработе с маленькими
(которых большинство в HP-UX) файлами. Поэтому в целях экономии дискового пространства блок может быть разделен на несколько фрагментов (1,2 или
4Кб). Размер фрагмента также определяется при создании файловой системы и не может иметь размер меньше чем одна восьмая размера блока.

Доступ к блокам данных

Как было указано выше, inode содержит указатель на блоки данных. В зависимости от размера файла данные содержащиеся в файлах могут быть доступны напрямую через указатели содержащиеся в inode, либо через двойную или тройную ссылку. Первый уровень ссылок позволяет адресовать непосредственно из inode 12 блоков данных, если этого не достаточно для адресации файла соответствующего размера то 12-й блок используется для адресации второго уровня. Размер ссылки составляет 4 байта, поэтому при размере блока в 4096 байт он может адресовать 1024 блока данных.
Аналогичным образом осуществляется адресация третьего уровня. При этом ограничение на максимальный размер файла практически снимается. Помимо указателя на блок, inode хранит указатель на фрагмент. Этот указатель может быть интерпретирован как ссылка на целый блок или оддин или несколько его фрагментов. Если обьем данных файла такой что последний блок остается не полностью заполненным то при этом используются фрагмент(ы). Рассмотрим этот случай на примере 20К файла хранимого в 8К блоках. Файл будет хранится в 2- х полных блоках и 4-х фрагментах. Этот случай изображен на рисунке:

Размер файла

8 15 24
31 40 43 46

1

2

блоки адреceсуемые 3 напрямую с inode

4

12

Когда для записи файла требуется блок или фрагмент, система начинает искать свободныйе блоки на диске. Когда файловая система заполненная, выполняется очень долгие линейные поиски для нахождения свободных блоков, и обычно находится блок соседний с тем котрый использовался при записи предыдущего файла. В конце концов это приводит к сильному падению производительности файловой системы. Поэтому для более быстрого поиска свободных блоков на файловой системе резервируется некоторая часть свободного места (minfree).
Этот параметр задается при создании файловой системы и может быть изменен в дальнейшем. Как правило это 10% от всего места отведенного под файловую систему.

Распределение дискового места.

Свободное место на диске определяется через битовую карту ассоциированную с каждой группой цилиндров. Битовая карта содержит один бит для каждого фрагмента. Для определения свободен ли блок, система проверяет смежные фрагменты. Пример куска битовой карты для файловой системы использующей
1024-х байтные фрагменты и 8192-х байтные блоки показан ниже:

|Битовая карта |00000000 |00000011 |11111100 |11111111|
|Номера фрагментов|0-7 |8-15 |16-23 |24-31 |
|Номера блоков |0 |1 |2 |3 |

Фрагменты с номерами 14-21 в этом примере сободны (отмечены 1), а фрагменты
0-13 и 22-23 уже заняты. Любые восемь подряд идущих фрагментов не могут составлять блок, только восемь фрагментов выровненных по границе блока могут составить блок. HP-UX пытается положить все все файлы находящиеся в одной директории в одну и туже группу цилиндров. Новосозданные директории помещаются в те группы цилиндров где наибольшее количество свободных inodes и наименьшее количество директорий. Если размер файла превішает порог определяемій параметром maxbpg (определяется при создании файловой системі и может меняться в дальнейшем) то HP-UX начинает выделять свободные блоки из другой группы цилиндров. Это позволяет более тесно группировать в одну группу цилиндров файлы находящиеся в одной директории путем размазывания больших файлов по нескольким группам цилинров.

Модификация файлов в HP-UX

Каждій раз когда происходит запись в файл, данные сначала записываются в буферный кэш находящийся в памяти. Физический диск обновляется ассинхронно по отношению к кэшу. Изменение данных на диске принадлежащие к определенной inode происходит позже, за исключерием если файл біл откріт в синхронном режиме (параметр O_SYNC O_SYNCIO в системных вызовах open() и fcntl()).
Если система останавливается без сброса буферов на диск то файловая система приходит в сосотояние с нарушеной целостностью. В єтом случае необходимо ее восстановление утилитой fsck. Команда sync может быть использована для принудительного сброса буферов на диск в любой момент времени. Системній демон syncer выполняет периодический сброс буферов на диск. Приведем список изменений происходящих в фаловой системе при выполнении некоторых основных операций над ней:

Главный суперблок сбрасывается на диск при выполнениии команды umount или команды sync при условии что файловая система была модифицирована

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

Обновляется либо синхронно либо ассинхронно по

Отношению к буферному кєшу

Блоки данных In-core блоки (директории, файлы, пайпы, симлинки,

FIFO) записываются на диск после модификации.

Блоки данных файлов буферизируются. Физически запись на диск происходит когда выполняется команда sync или системный вызов fsync() или непосредственно после модификации если на файл при открытии установлен флаг O_SYNC.

Информация о группе эта информация сбрасывается на диск после цилиндров выполнения sync (fsync).

Замечание: команда reboot –n перегружает систему без сброса буферов на диск. Эту команду нужно использовать после выполнения проверки и устранения сбоев корневой файлой системы. Остальные файловые системы необходимо проверять только в отмонтированном состоянии.

Менджер логических дисков LVM

Перед появлением HP-UX 10.* управление дисками в сриях HP 800 и HP 700 осуществлялось различным образом. В серии 800 была возможность разбивки диска на жестко определенные партиции, а также управление через LVM. В серии 700 таких возможностей не было, и единственное что можно было использовать – так это использование целого диска для создания файловой системы. С появлением HP-UX 10.* ситуация радикально изменилась, LVM стал доступен на обеих сериях и является рекомендуемым инструментом для работы с файловыми системами. Он представляет собой псевдодрайвер ядра системы эмулирующий логические диски.

Что такое Logical Volumes и в каких случаях их следует использовать ?

Logical Volumes (LV) это набор дисковых участков с одного или более дисков организованных в таком виде, что операционная система видит их как один логический диск. Как и физические дискиони могут быть использованы для поддержки файловых систем, raw областей данных, swap или dump областей.
Использование LV оправдано в случаях больших файловых систем которые не умещаются на одном диске и (или) нуждаются в последующем расширении а также в случаях когда необходимо организовать резервирование (зеркалирование) данных или когда к файловой системе предъявляются жесткие требования по производительности.

Physical Volumes

(диски)

Volume Groups

(пул дисков)

Для использования LVM диски должны быть инициализированны как physical volumes. Physical volumes идентифицируются именами ссответствующих файлов- устройств дисков /dev/dsk/cntndn и /dev/rdsk/cntndn. Затем из одного или нескольких дисков собирается volume group. Один физический диск может принадлежать только к одной volume group. Максимальное число volume group которое может быть в системе определяется параметром maxvgs. Одна volume group может содержать не более 255 физических дисков. Дисковое пространство из volume group распределяется между одной или несколькими logical volumes.
Дисковое пространство из logical volumes может быть использовано для создания файловой системы, под swap или dump области. LVM разбивает каждый диск на набор адресуемых блоков называемых physical extents. Их размер определяется во время создания volume group и одинаков для всех дисков входящих в volumes group. Размер physical extents варьируется от 1 до 256
Мб, по умолчанию он равен 4Мб. Базовым блоком для адресации logical volumes является logical extent, он напрямую отображается в physical extents. В HP-
UX команды показывающие эти отображения имеют названия pvdisplay и lvdisplay:

# pvdisplay /dev/dsk/c0t5d0

— Physical volumes —

PV Name /dev/dsk/c0t5d0

VG Name /dev/vg00

PV Status available

Allocatable yes

VGDA 2

Cur LV 9

PE Size (Mbytes) 4

Total PE 511

Free PE 81

Allocated PE 430

Stale PE 0

IO Timeout (Seconds) default

# lvdisplay /dev/vg00/lvol1

— Logical volumes —

LV Name /dev/vg00/lvol1

VG Name /dev/vg00

LV Permission read/write

LV Status available/syncd

Mirror copies 0

Consistency Recovery MWC

Schedule parallel

LV Size (Mbytes) 48

Current LE 12

Allocated PE 12

Stripes 0

Stripe Size (Kbytes) 0

Bad block off

Allocation strict/contiguous

Если logical volumes используется для корневой (root) файловой системы, первичной swap области или dump области, physical extents должны распределяться методом contiguous. Это означает что между они должны следовать непрерывно на одном физическом диске и между ними не должно возникать прпомежутков. Другие logical volumes использующиеся для некорневых файловых систем могут не следовать этому ограничению.

Для определения требуемого объема logical volume необходимого для создания файловой системы можно использовать следующую диаграмму:

Управление Logical Volumes (LV)

Системная утилита SAM позволяет выполнять большинство но не все операции над LV. К тем задачам с которыми она справляется можно отнести:

. Создание и удаление volume groups.

. Добавление и удаление дисков из volume groups.

. Создание, удаление и модификация logical volumes.

. Создание и увеличение обьема файловых систем находящихся на logical volumes.

. Cоздание и модификация swap и dump logical volumes.

Для этого, после запуска SAM нужно войти в раздел “Disks and file systems” а затем в один из нужных подразделов. Все дальнейшие действия выполняются с использованием графической оболочки и являются интуитивно понятными. Все тоже самое можно выполнить используя команды HP-UX.

Создание physical volume (PV).

pvcreate /dev/rdsk/c0t6d0

Все данные имеющиеся на этом диске будут потерены, в качестве аргумента программы pvcreate необходимо использовать символьный (raw) файл-устройство диска. Послк инициализации, данный диск можно рассматривать как physical volume.
Помещение PV в одну из volume groups (VG)

Если необходимо создать новую VG, то в самом начале нужно сделать директорию для файлов-устройств отвечающих за данную VG:

mkdir /dev/vgnn cd /dev/vgnn

Затем нужно создать необходимые файлы устройств:

mknod /dev/vgnn/group c 64 0xNN0000

В качестве старшего номера устройства всегда нужно использовать 64,
0xNN0000 является младшим номером устройств и NN представляет собой уникальный среди всех VG номер. Теперь можно приступать к созданию VG:

vgcreate /dev/vgnn /dev/dsk/c0t6d0 …

Вторым (третьим, четвертым …) аргументом этой команды должен быть файл- устройство блочного типа соответствующего physical volume который не является членом какойто из существующих VG.

Создание Logical Volume.

lvcreate /dev/vgNN

После чего появится блочные и символьные файлы устройств /dev/vgNN/lvoln и
/dev/vgNN/rlvoln. LVM сам выберет подходящий номер n. Для создания LV с именем отличным от того что создается по умолчанию нужно воспользоваться опцией –n. Данный LV будет иметь нулевой размер, в дальнейшем его можно увеличить. Также указав опцию –L можно создать LV заранее необходимого размера (в Мб), при этом реальный размер LV будет округлен в большую сторону и кратен целому количеству physical extents.

Задачи котоые можно выполнить только с использованием комманд HP-UX

К ним можно отнести:

. Расширение LV за счет определенного диска

. Создание корневой (root) VG и корневого LV

. Резервное копирование и восстановление конфигурации VG

. Перемещение данных с одного LVM диска на другой

. Уменьшение размера LV

Расширение LV за счет определенного диска

Допустим имеется необходимость создать LV на 120Мб, причем первые 60 Мб необходимо взять с одного диска а оставшиеся 60 с другого. Так поступают часто в случаях когда необходимо повысить производительность файловой системы за счет паралельного использования нескольких дисков. Вначале создаем LV нулевого размера:

lvcreate –n lvol11 /dev/vg00

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

lvextend –L 60 /dev/vg00/lvol11 /dev/dsk/c0t5d0 lvextend –L 60 /dev/vg00/lvol11 /dev/dsk/c0t6d0

Создание корневой VG и корневого LV

Корневой VG это VG который используется системой при загрузке. На нем размещается LV содержащий корневую файловую систему, первичный swap и dump области. Ниже приводятся этапы последовательного создания корневого VG. Во- первых создается PV на котором размещается LIF раздел в котором находятся загрузочные утилиты. Для этого в команде pvcreate используется опция -B:

pvcreate -B /dev/rdsk/c0t6d0

Создаем корневой LV:

vgcreate /dev/vgroot /dev/dsk/c0t6d0

Помещаем загрузочные утилиты в LIF область VG:

mkboot /dev/rdsk/c0t6d0

Записываем в LIF область AUTO файл:

mkboot –a “hpux (;0)/stand/vmunix” /dev/rdsk/c0t6d0

После выполнения всех этих действий корневая VG готова к созданию на ней
LV. Корневой LV должен быть самым первым в этой VG, и следовать сразу за boot областью. Это значит что он должен начинаться с нулевого physical extent. Теперь можно переходить к созданию корневого LV, при его создании нужно включить опцию “смежный LV” (-C) и запретить перемещение bad блоков (- r):

lvcreate –C y –r n –n root /dev/vgroot lvextend –L 160 /dev/vgroot/root /dev/dsk/c0t6d0

В конеце необходимо пометить сосзданный LV как корневой:

lvlnboot –r /dev/vgroot/root

Резервное копирование и свосстановление конфигурации Volume Groups

Для создания резервной копии конфигурации VG нужно воспользоваться командой vgcfgbackup. Пежде чем выполнять эту команду нужно убедится что все LV в данной VG находятся в состоянии available/syncd (для этого можно воспользоваться командой vgdisplay –v). По умолчанию команда vgcfgbackup сохраняет конфигурационый файл VG под именем
/etc/lvmconf/volume_group_name.conf. Это имя можно переопределить задав опцию –f.

Восстановление конфигурации выполняется командой vgcfgrestore. Перед этим необходимо предварительно деактивировать данную VG командой vgchange.
Например:

vgchange –a n /dev/vg01 vgcfgrestore –n /dev/vg01 /dev/rdsk/c0t6d0

Выполнение этих команд приведет к восстновлению информации о VG vg01 из файла /etc/lvmconf/vg01.conf . Затем необходимо активировать данную VG:

vgchange –a y /dev/vg01

Перемещение и переконфигурирование дисков

В жизни могут возникнуть ситуации при которых необходимо:

. Переместить диск входящий в состав VG на другое положение в пределах системы.

. Переместить целую VG с одной системы на другую.
Файл /etc/lvmtab содержит информацию о отображении LVM дисков на соответствующие VG. При любых изменениях связанных с дисками и VG в системе этот файл изменяется, однако это не текстовый файл и напрямую его редактировать нельзя. Вместо этого нужно пользоваться программами vgexport и vgimport.

Перемещение диска в системе.

Для перемещения диска в системе на новое место необходимо выполнить следующее:

. Создать резервную копию конфигурации VG в которую входит диск и данных хранящихся на диске

. Деактивировать VG в состав которой входит диск:

vgchange –a n /dev/vgxxx

. Удалить запись ассоциированную с этим диском из /etc/lmvtab а также файлы устройств из каталога /dev/vgxxx

vgexport /dev/vgxxx

. Создать заново VG, и добавить запись в /etc/lvmtab

mkdir /dev/vgxxx mknod /dev/vgxxx/lvolN c 64 0x010000 vgimport /dev/vgxxx /dev/dsk/cntndn

. Активировать вньовь ипортированную VG

vgchange –a y /dev/vgxxx

. Создать резервную копию конфигурации VG

vgcfgbackup /dev/vgxxx

Перемещение диска между системами

Для перемещения диска с одного места на другое между двумя системами необходимо выполнить следующие действия:

. Деактивировать VG

vgchange –a n /dev/vgxxx

. Удалить информацио о VG из /etc/lvmtab указав имя map файла который будет содержать удаляемую информацию (он содержит также имена удаляемых LV из VG)

vgexport –p –v –m plan_map vgxxx

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

vgexport –v –m plan_map vgxxx

. Переносим map_file на новую систему, останавливаем старую систему, переносим диски на новую.

. На новой системе создаем VG

mkdir /dev/vgxxx cd /dev/vgxxx mknod /dev/vgxxx c 64 0x080000

. Импортируем новую конфигурацию. Для просмотра используется опция

–p, для выполнения реального импорта она должна отстутствовать:

(предполагается что в новую систему переносились диски которые распозхнались как /dev/dskc0t2d0 /dev/c0t3d0)

vgimport –p –v –m plan_map /dev/vgxxx /dev/dskc0t2d0 /dev/c0t3d0

. Активируем VG

vgchange –a y /dev/vgxxx

Перенос данных на другой physical volume.

Для переноса данных содержащихся в LV с одного диска на другой необходимо воспользоваться командой pvmove. Например для переноса данных из LV
/dev/vg01/lvo1 с диска /dev/dsk/c0t0d0 на /dev/c0t1d0:

pvmove –n /dev/vg01/lvol1 /dev/dsk/c0t0d0 /dev/c0t1d0

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

pvmove /dev/dsk/c0t0d0 /dev/c0t1d0

Уменьшение обьема Logical Volumes

Для уменьшения обьема LV используется команда lvreduce. Однако в этом случае данные хранящиеся в файловой системе на этом LV будут потеряны, поэтому необходимо предварительное резервное копирование. Также можно воспользоваться другой техникой – вначале удалить LV командой lvremove, а затем создать LV требуемого размера командой lvcreate.

3. Особенности файловой системы VxFS

VxFS является HP-UX реализацией журнальной файловой системы известной как JFS на базе версии корпорации VERITAS. Прежние версии HP-UX (меньше
10.*) имели в своем арсенале лишь HFS, начиная с 10.01 появилась дополнительная опция на использование VxFS в качестве файловой системы.
Однако VxFS не может быть использована как файловая система для раздела
/stand из которого происходит зщагрузка ядра. В ранних версиях 10-го релиза
HP-UX она так же не могла быть использована для корневой файловой системы.
По сравнению с HFS имеет меньшее время восстановление при сбоях и имеет повышеную производительность на больших объемах данных, т.к. блок используемый ею может состоять из множества физических блоков. Т.к. это журнальная файловая система то она позволяет вести online backup. Однако в отличии от HFS она потребляет больше памяти.

В стандартной поставке HP-UX включены лишь базовые элементы VxFS.
Дополнительные функциональные возможности возможны только при использовании отдельного пакета под названием HP OnlineJFS.

4. Операции над файловой системой

Все операции над файловой системой могут быть произведены с использованием системной утилиты SAM или напрямую с использованием команд HP-UX. Файловые системы могут создаваться на LVM и не LVM дисках. Использование LVM дисков является более предпочтительным.

Создание файловой системы

Для создания файловых систем используют команду newfs. Она имеет следующий синтаксис:

newfs [-F FStype] [-o specific_options] [-V] special

где special имя символьного файла-стройства

FSType тип файловой системы (HFS, VxFS) specific_options опции специфические для данного типа файловой системы

Если не указывать опцию –F то тип файловой системы берется из файла
/etc/fstab, если в нем нет соответствующей special строки то используется тиип по умолчанию из файла /etc/defaults/fs. При создании HFS возможно использование опций –L (длинные имекна файлов 255 знаков) или –S (короткие имена файлов 14 знаков). В VxFS все имена файлов длинные. После создания файловой системы ее можно монтировать.

Монтирование и демонтирование файловых систем

Для монтирования файловых систем или получения информации о смонтированных файловых системах используется команда mount. Монтирование заключается в присоединении файловой системы к директории. Примеры использования команды mount:

mount –a монтирование всех файловых систем указанных в файле /etc/fstab

mount /tmp монтирование на каталог /tmp соответствующей из /etc/fstab файловой системы.

mount /dev/vg00/lvol1 /tmp монтирование файловой системы находящейся в LV /dev/vg00/lvol1 в каталог /tmp

mount выдача информации о смонтированных файловых системах

После загрузки системы все файловые системы перечисленные в файле
/etc/fstab автоматически монтируются. Список всех смонтированных в данный момент файловых систем находится в файле /etc/mnttab.

Для демонтирования файловых систем используется команда umount. Синтаксис ее очень схож с командой mount.

umount –a монтирование всех файловых систем указанных в файле /etc/mnttab

umount /tmp размонтирование файловой системы от каталога /tmp

umount /dev/vg00/lvol1 размонтирование файловой системы

Файловая система может быть размонтирована только в том случае если нет процессов использующих ее в данный момент. Для определения какие процессы используют файловую систему применяют команду fuser, например:

fuser –u /dev/vg00/lvol1 выводит ID всех процессов использующих данную FS

fuser –ku /dev/vg00/lvol1 посылает сигнал завершения всем процессам использующим данную FS

Проверка файловых систем

Если система некорректно завершила свою работу (пропадание питания, system panic) то все смонтированные на тот момент файловые системы с огромной вероятностью будут содержать ошибки. Для их устранения применяется утилита fsck. Она вызываетс ясистемой после перезагрузки из стартового скрипта
/etc/bcheckrc и проверяет все файловые системы из файла /etc/fstab.

Файловая система HFS

При проверке файловых систем нужно выполнить следующие шаги:

1. Проверить наличие каталога lost+found на корню проверяемой файловой системы. Если его нет , то создать его.

2. Терминировать все процессы использующие фанную файловую систему.

3. Размонтировать файловую систему командой umount.

4. Запустить fsck –p . Опция –p позволяет устранять большинство проблем без вмешательства со стороны администратора (неинтерактивно). Если fsck находит проблему на решение которой она не может принять решение то fsck заканчивает свою работу с сообщением об ошибке. Если fsck завершила свою работу удачно, значит все повреждения файловой системы были исправлены. В противном случае:

5. Запустить fsck без аргументов –p или –P (интерактивно). При этом возможна потеря данных или имени файлов. После окончания работы fsck перегрузите систему киспользуя команду reboot -n. Если не выполнить такую перезагрузку, то можно заново повредить файловую систему.

6. Проверить содержимое каталога lost+found. В него fsck сбрасывает все данные которые не подлежат восстановлению.

Файловая система VxFS

В том случае когда нужно проверить VxFS (разумеется не в случае физического сбоя) нет необходимости проверять всю файловую систему а джостаточно проверить так называемый iintent log содержащий записи всех изменений ожидаемых в структуре файловой системы, который представляет собой не что иное как лог транзакций которые система хотела осуществить перед сбоем.
Проверка intent log происходит очень быстро и время восстановления VxFS существенно меньше чем HFS. В случае дискового сбоя сканирование intent log- а неоправдано и в такой ситуации необходимо сканирование всей файловой системы. Для этого нужно запускать fsck –o full.

Сокращение обьема файловой системы

Для уменьшения обьема файловой системы нужно выполнить следующие действия:

. Сделать резервную копию файловой системы

. Размонтировать файловую систему

. Уменьшить обьем LV командой lvreduse.

. Создать заново файловую систему командой newfs.

. Смонтировать ее

. Восстановить данные из резервной копии

Увеличение обьема файловой системы

Для увеличения обьема файловой системы необходимо выполнить следующие действия:

. Размонтировать файловую систему umount /dev/vg01/lvol01

. Увеличить размер LV (например до суммарного обьема 1.5 Гб)

lvextend –L 1500 /dev/vg01/lvol1

. Увеличить обьем файловой системы:

extendfs /dev/vg01/lvol01

. Смонтировать файловую систему:

mount /dev/vg01/lvol1 /xxx

Мониторинг использования дискового пространства

Команды df и bdf позволяют вести мониторинг свободного и занятого дискового пространства и числа inodes. Команда df выводит значения в 512 байтных блоках, bdf в килобайтах. Например:

bash-2.04# bdf -i
Filesystem kbytes used avail %used iused ifree %iuse Mounted on
/dev/vg00/lvol3 86016 77263 7875 91% 4566 2078
69% /
/dev/vg00/lvol7 163840 137219 24231 85% 8164 6304 56%

/var
/dev/vg00/lvol6 339968 296156 41079 88% 17857 10947 62%
/usr
/dev/vg00/lvol4 360448 318130 39684 89% 8867 10573 46%
/opt
/dev/vg00/home 204800 186722 8178 96% 13797 2163 86%
/home
/dev/vg00/lvol5 32768 2594 28244 8% 204 7524
3% /tmp
/dev/dsk/c0t2d0 381402 381402 0 100% -1 0

100% /cdrom
/dev/vg00/lvol1 47829 21052 21994 49% 25 7655
0% /stand

Для контроля места занимаемого какойто директорией можно использовать команду du. Наример:

bash-2.04# du -s /usr/contrib/*
2594 /usr/contrib/X11R6
352 /usr/contrib/X11drivers
5346 /usr/contrib/Xm1.2
11118 /usr/contrib/bin
374 /usr/contrib/doc
0 /usr/contrib/etc
0 /usr/contrib/games
0 /usr/contrib/include
262 /usr/contrib/lib
432 /usr/contrib/man
514 /usr/contrib/src

Организация веб-сайта

Выбор операционной системы.

Выбор операционной системы, прежде всего, определяется тем, что имеется в наличии. В настоящее время www-сервера строятся на основе Windows
NT и Unix-системах преимущественно, поскольку платформа OS/2 фактически не используется из-за неудачной маркетинговой политики, а MacOS не предназначена для использования как серверная технология.

Предпочтительнее всего – иметь Unix-подобную систему. Она не намного сложнее в администрировании «навороченного» NT-сервера, несмотря на бытующее мнение, и значительно снижает затраты на ПО, администрирование и поддержку www-сервера, как, например, за счет того, что существует огромное количество бесплатного ПО и ПО с открытым исходным кодом в рамках лицензии
GPL (1,2) за которое не придется платить деньги. Кроме того, бесплатность не является основным преимуществом, в первую очередь ПО с открытым исходным кодом получает все большее распространение и признание благодаря именно открытости программного кода и технологий. Получая такое ПО, вы получаете десятки тысяч добровольных разработчиков и тестеров во всем мире.
Что это означает. Такое ПО гораздо быстрее обновляется, ошибки и бреши в системе безопасности исправляются значительно быстрее, чем в коммерческих продуктах, и, как это не удивительно, оно является более стабильным. Кроме этого некоторые специфические задачи для веб-сайта можно решить только на основе Unix-систем и ПО с открытым кодом в силу того, что необходимо создавать собственные модули, парсеры и программы и серверные приложения для интерактивной работы с сервером; понятно, что сделать это на основе коммерческого ПО сложно в связи с тем, что вы имеете дело с готовыми бинарными файлами и не имеете возможности их менять. Отрицательные стороны: необходимость постоянно следить за новостями и обновлениями (коммерческие организации рассылают соответствующие бюллетени и CD, здесь – необходимо подписаться на рассылку по электронной почте и самому загружать обновления); второе, необходимы некоторые базовые знания программирования и особенностей операционной системы для установки новой версии и внесения исправлений в ПО. Причем на платформе Windows делать это будет значительно труднее.

Выбор программного обеспечения сервера.

Под программным обеспечением сервера понимается программа-демон, которая обрабатывает http-запросы, а так же все сопровождающее программное обеспечение: клиенты баз данных, специфические компиляторы, парсеры, анализаторы логов, генераторы статистики, счетчики и т.п.

Итак, ПО веб-сервера в первую очередь – это именно процесс (демон) который обрабатывает запросы и обычно, собственно, и носит название «веб- сервер». Существует достаточно много различных технологий и веб-серверов от разных производителей, но, как и везде, есть бесспорные лидеры. Прежде всего, это Microsoft IIS, Apache, Netscape FastTrack Server, а так же менее известные Stronghold и FHTTPD. Немного статистики: наиболее распространенным сервером в странах СНГ является Apache – около 80% веб- сайтов построены на нем, порядка 15% принадлежит Microsoft IIS, оставшиеся
5% с переменным успехом разделены между другими оставшимися веб-серверами.
Для платформы HP-UX прежде всего следует рассмотреть Apache, Netscape
FastTrack Server, как совместимые с платформой и возможные к использованию.
Недостатком упоминавшихся ранее Stronghold и FHTTPD является следующее, первый – коммерческий с ограниченной лицензией и ограниченной поддержкой новых технологий, второй сервер – является так же и сервером обслуживания
FTP-запросов, что значительно снижает безопасность и устойчивость сервера.
Сопутствующее ПО. В самом простейшем случае это различные интерпретаторы, парсеры и/или модули, которые могут понадобиться для создания интерактивного сайта, обработки форм и исполнения приложения. В минимальный комплект как минимум будут входить: компилятор С, интерпретатор языка Perl, которые понадобятся для создания cgi-скриптов, обработки форм и запросов, а так же оживления сайта; кроме этого на сервере можно установить компилятор
Java, если в перспективе планируется использовать сервелеты, а так же некоторые другие средства разработки – Tcl/Tk, PHP, если предполагается использование баз данных, то для работы необходимо будет установить, как минимум, клиенты к базам данных и соответствующие библиотеки, как, например, MySQL или PostgresSQL. Кроме того, для оживления сайта, мониторинга посещаемости можно установить программы подсчета посещений и анализа логов (WWWCount, Webalizer), если вы не собираетесь использовать счетчики внешних рейтинговых систем, которые значительно замедляют загрузку страниц сайта, а так же имеют обыкновение не работать в течение длительных периодов времени или работать некорректно.

Анализ веб-серверов.

Netscape FastTrack Server.
По заверениям компании Netscape это веб-сервер начального уровня пригодный для малых и средних серверов с устойчивым базовым движком, пригодным для создания статических и динамических сайтов, а так же предлагающий простейшие инструменты для работы с базами данных на веб-сайте. Сервер поддерживает HTTP 1.1 и SSL 3 технологии, сервелеты на основе JavaScript
1.1, а так же доступ к ODBC базам данных. Для корпоративных сайтов и крупных серверов предлагается использовать усовершенствование версии до
Netscape Enterprise Server, что значительно дешевле, чем изначально покупать лицензию Enterprise Server

Apache. (Apache Software Foundation)
Веб-сервер разрабатывается на основе движка NCSA httpd 1.3, который был переработан Apache Software Foundation, лицензирование – GPL2, с открытым исходным кодом. Этот достаточно мощный сервер, который пригоден как для небольших и средних сайтов, так и для крупных корпоративных проектов в настоящее время используется на 60% веб-сайтов всего мира. Сервер поддерживает HTTP 1.1 и SSL 3 технологии, сервелеты на основе JavaScript
1.1, технологии SSI, так же содержит более 50 модулей, позволяющих реализацию проекта практически любой сложности. Кроме этого, к серверу можно подключить не меньшее количество модулей от сторонних производителей, как, например, FastCGI от OpenMarket Group (разработчиков FHTTPD), что значительно расширяет его возможности. Сервер доступен в вариантах под платформы Windows NT и все Unix-системы.

Инсталляция веб-сервера.

Инсталляция Netscape FastTrack Server.

Инсталляция Netscape FastTrack Server достаточно проста, поскольку это сугубо коммерческий продукт, поставляемый в бинарном виде, и устанавливается он стандартными средствами, как, например, для HP-UX это с помощью swinstall.
Далее следует вручную исправить в файле /opt/ns-fasttrack/admserv/admpw пароль доступа. Проще всего убрать всякий пароль для пользователя root, тем более, что по умолчанию заход с административными правами разрешен только с localhost. Дальнейшая конфигурация и настройка осуществляется из браузера после запуска ns-admin и не представляет сложностей. Принципиально необходимо настроить практически такие же параметры как и для apache только все это делается через веб-интерфейс.

Инсталляция Apache.
Архитектуру сервера можно описать так:

Для инсталляции веб-сервера Apache, вполне достаточно стандартной поставки в Unix-системе, т.е. компилятора СС. Однако, рекомендуется все-таки поставить GCC (Gnu-CC) компилятор, особенно в том случае, если вы собираетесь использовать модули от сторонних производителей, обычно для их инсталляции требуется именно GCC. Для того чтобы сконфигурировать и запустить Apache под Windows NT, можно воспользоваться доступной готовой инсталляцией в традиционном стиле Windows-приложений, если же собирать сервер из исходных кодов, то потребуется инсталляция MS Developer Studio или MS Visual C как минимум.
Рассмотрим процесс инсталляции в Unix-среде. Для того чтобы успешно скомпилировать сервер, необходимо знать основы работы с шеллом и некоторое стандартное программное обеспечение под Unix.
Процесс инсталляции:
1. Развернем дистрибутив apache-x.x.x в какую либо директорию (можно в home)
2. Для сборки сервера без подгружаемых модулей достаточно запустить конфигурационный скрипт с такими ключами:

./configure —with-layout=Apache —prefix=/usr/local/httpd/ —enable- shared=max —enable-suexec —suexec-caller=#65533 —suexec- docroot=/usr/local/httpd/ —suexec-logfile=/usr/local/httpd/logs/suexec_log
—suexec-safepath=/usr/local/httpd/cgi-bin —sbindir=/usr/local/httpd/bin
3. После того как отработает конфигурационный скрипт, достаточно набрать make, потом make install и можно приступать к конфигурированию сервера.
Для проверки правильности компиляции следует запустить
/usr/local/httpd/bin/httpd -l
Результат будет приблизительно таким:
Compiled-in modules: mod_env.c http_core.c mod_so.c suexec: enabled; valid wrapper /usr/local/apache/bin/suexec
2а. Для сборки сервера в идеальном варианте, когда сам сервер содержит только suexec wrapper, http_core и статически вкомпилированную библиотеку поддержки подгружаемых модулей mod_so, необходимо запустить скрипт автоконфигурации configure с такими ключами (для удобства приведен пример скрипта, который выполняется из шелла, поскольку более полусотни ключей неудобно набирать, особенно при возникновении опечаток)

./configure
«—with-layout=Apache»
«—enable-module=so»
«—prefix=/usr/local/httpd/»
«—enable-module=env»
«—enable-shared=env»
«—enable-module=setenvif»
«—enable-shared=setenvif»
«—enable-module=mime»
«—enable-shared=mime»
«—enable-module=negotiation»
«—enable-shared=negotiation»
«—enable-module=alias»
«—enable-shared=alias»
«—enable-module=rewrite»
«—enable-shared=rewrite»
«—enable-module=userdir»
«—enable-shared=userdir»
«—enable-module=dir»
«—enable-shared=dir»
«—enable-module=autoindex»
«—enable-shared=autoindex»
«—enable-module=access»
«—enable-shared=access»
«—enable-module=auth»
«—enable-shared=auth»
«—enable-module=auth_anon»
«—enable-shared=auth_anon»
«—enable-module=auth_dbm»
«—enable-shared=auth_dbm»
«—enable-module=auth_db»
«—enable-shared=auth_db»
«—enable-module=digest»
«—enable-shared=digest»
«—enable-module=headers»
«—enable-shared=headers»
«—enable-module=cern_meta»
«—enable-shared=cern_meta»
«—enable-module=expires»
«—enable-shared=expires»
«—enable-module=asis»
«—enable-shared=asis»
«—enable-module=include»
«—enable-shared=include»
«—enable-module=cgi»
«—enable-shared=cgi»
«—enable-module=actions»
«—enable-shared=actions»
«—enable-module=status»
«—enable-shared=status»
«—enable-module=info»
«—enable-shared=info»
«—enable-module=log_config»
«—enable-shared=log_config»
«—enable-module=log_agent»
«—enable-shared=log_agent»
«—enable-module=log_referer»
«—enable-shared=log_referer»
«—enable-module=usertrack»
«—enable-shared=usertrack»
«—enable-module=imap»
«—enable-shared=imap»
«—enable-module=proxy»
«—enable-shared=proxy»
«—enable-module=mmap_static»
«—enable-shared=mmap_static»
«—enable-suexec»
«—suexec-caller=#65533»
«—suexec-docroot=/usr/local/httpd/»
«—suexec-logfile=/usr/local/httpd/logs/suexec_log»
«—suexec-safepath=/usr/local/httpd/cgi-bin»
«—sbindir=/usr/local/httpd/bin»
3а. После того как отработает конфигурационный скрипт, достаточно набрать make, потом make install и можно приступать к конфигурированию сервера.
Для проверки правильно ли скомпилирован сервер запустим его с ключом –l:
/usr/local/httpd/bin/httpd -l
Соответствующий правильному результат будет следующий:
Compiled-in modules: http_core.c mod_so.c suexec: enabled; valid wrapper /usr/local/apache/bin/suexec

Стратегическое планирование. Определение объема работы.

Концепция:
Опрос клиента: вопросники, профили посетителей
Стратегический план: задачи маркетинга, обзор конкурентов, требования к рекламе, потребности пользователей ресурса.
Функциональный план: технические задачи, задачи функциональности.
Административные задачи:
Выбор команды: продюсер, арт-директор/дизайнер, автор/эдитор, программист.
Расписание и бюджет проекта.

Многие приступают к работе над новым сайтом с выбора цветов, шрифтов, технологий и т.п. Тогда как логичнее начать с анализа проекта, планирования предстоящей работы и поиска ответов на ряд важных вопросов, касающихся будущего сайта. Время, потраченное на сбор и обработку нужной информации, окупится с лихвой, помогая избежать потери денег и энергии в дальнейшем.
1. Вы получили деловое предложение. В первую очередь постарайтесь узнать как можно больше о вашем заказчике, о его фирме; сферу бизнеса, в котором он работает, и занимаемую в ней нишу.
2. Получите у него ответы на следующие вопросы:
— Зачем ему нужен сайт? Почему он его создает и какие цели и задачи преследует?
— — Желает ли он моментальной отдачи или подготавливает почву для более агрессивного бизнеса в Сети в дальнейшем?
— — Что входит в его цели: продать продукцию или сервис, увеличить покупательский рынок, обеспечить поддержку уже проданному товару?
— — Возможно, он надеется подняться на уровень конкурентов, которые давно имеют свои ресурсы в Интернет?
— — Если бы у него была возможность донести только одну идею до своих пользователей, какой бы она была?
— — Какие дальнейшие действия ожидает он от посетителей его Веб-страниц?

Обращение за более полной информацией? Визит в магазин или офис, покупка напрямую с сервера?
— — Как заказчик измерит успех или неудачу сайта? Как узнать, что сайт получился удачным — понравилось начальнику? Выиграл Сетевые награды?

Популярен в среде пользователей?
— — Кого он хочет видеть своим посетителем? (Дизайн и содержание сайта должны оправдывать ожидания и удовлетворять потребности пользователя)
— — Почему к нему будут приходить? За какой информацией?
— — А какую информацию он может предоставить? Одна из распространенных ошибок профессионалов — это убежденность в том, что пользователи достаточно просвещены в вопросах, касающихся деятельности фирмы.

Вероятнее всего, это не так. Маркетинг заказчика только выиграет от результатов обучения возможных клиентов. Ваша с ним задача — выбрать из моря информации ту, в которой нуждается посетитель.
— — Интересуется ли он привлечением одноразовых посетителей (для счетчика) или надеется превратить случайных прохожих в регулярных пользователей?

Лояльность требует частого обновления материалов.
3. Узнайте, кто является конкурентом заказчика. Как выглядят их Интернет ресурсы. Очень важно, чтобы сайт клиента не подражал другим, а представлял уникальный и последовательный в себе имидж. Составьте документ с подробным описанием того, что вы знаете о данной индустрии в Интернете. Сделайте выводы — что работает и что не работает для схожей группы пользователей на других сайтах. Что бы вы могли использовать на сайте заказчика, и что использовать не стоит.
4. Когда вы утвердите профиль будущего посетителя (см. вопросы выше), составьте список возможных требований (например, основной группой пользователей будет молодежь, которая дозванивается в Интернет через слабый модем и терпеть не может ждать загрузки страницы дольше, чем 30 сек.) и пожеланий (они хотели бы иметь возможность обмениваться мнениями на доске или болтать в чате) различных посетительских групп.
4. Следующие, решите вопросы по функциональности ресурса.
— Что заказчик находит необходимым для его сайта? К примеру, динамические страницы, генерируемые базой данных, веб-коммерция, каталоги, программы?

Сделать-то можно все, что он пожелает, дело в стоимости и сроках исполнения.
— — Спросите, кто будет мониторить и обновлять подобные функции?
— Имеет ли заказчик неординарные требования к безопасности?
— — Как и где будет хоститься сайт?
— — Существуют ли какие-либо исключения?
— — Кто будет обновлять и поддерживать ресурс?
— — Какие у заказчика планы на будущее, касательно Веб-сайта?
6. Технические спецификации будут служить основой всех скриптов, css, графики, html, java и других технических элементов сайта. Определите, какое программное обеспечение потребуется пользователям для просмотра ресурса, а также общий технический подход к разработке и поддержке сайта. Хотелось бы знать резолюцию монитора посетителя, скорость их модема, сколько памяти в его системе, количество воспроизводимых цветов, какие плагинсы (программные модули) имеют и т.д. Подобную информацию можно найти в уже существующей у заказчика базе данных пользователей, из интервью, опросов клиентов заказчика, или обычных логических предположений.
7. Вы должны договориться с заказчиком о бюджете проекта, сроках исполнения
(если важно) и расписании. Одновременно стоит подумать над тем, какие специалисты вам понадобятся. Возможно, вас не затруднит создать небольшой сайт своими силами, но для серьезного проекта лучше воспользоваться знаниями и опытом професcионалов.
Успех Веб-ресурса покоится на равновесии между достижением желаемых результатов и затраченных в процессе средств. Не стоит пытаться прыгнуть выше головы; потеря времени и денег — результат суперожиданий и нереальных запросов. При планировании, в первую очередь, стоит принимать во внимание нужды будущих посетителей, а не последние достижения технологии и эгоцентричный энтузиазм разработчиков. Мы не создаем сайты для себя, мы создаем их для наших посетителей.

Тактическое планирование сайта. Разработка структуры.

Карта сервера
Подготовка контекста, создание и эдитирование
Обозрение материалов
Технические спецификации (тактическая сторона)
Навигация и разметка страниц

Имея на руках результаты опросов заказчика и профили будущих посетителей, пришло время шевелить мозгами в поисках идей, которые помогут веб-сайту достичь поставленных перед ним задач.
Первый ваш шаг — набросок «карты сайта». Это графическая диаграмма, показывающая путь продвижения посетителя по сайту. Ваша карта должна включать в себя каждую его страницу и то, в какой зависимости они находится относительно других страниц и материалов. Очень важно получить «добро» заказчика на «карту», и отметить любые изменения в структуре, такие как удаление или добавление страниц, что может повлиять на бюджет проекта.
Планирование контекста происходит в тесном сотрудничестве с заказчиком.
Возможно, у него уже есть готовые материалы, другие должны быть модифицированы, переписаны или созданы с нуля. Необходимо четко разграничить обязанности между вами. Кто будет ответственен за что? Если заказчик поставляет весь материал, составьте ему расписание. Передача текстов вечно занимает больше времени, чем мы рассчитываем и часто именно заказчик виновен в растягивании сроков проекта. Определитесь с текстом для каждой страницы до начала работы над дизайном. Навигация сайта будет напрямую зависеть от количества и глубины содержания, а его стиль и тон окажут влияние на визуальный язык композиции.
Тактическую сторону технических спецификаций можно отразить в коротком документе, определяющим подход и используемые технологии при кодировании страниц и визуальной разметке.
— Будут ли страницы генерироваться «на лету» из датабазы?
— — Будут ли использованы Cascading Style Sheets (CSS)?
— — Потребуется ли наличие модуля (plug-in) или специального контроля на машине пользователя?
— — Под какой минимум необходимо оптимизировать цветовую палитру?
— — Вы будете писать код сами или использовать WYSIWYG «Что вижу, то и получаю» эдитор (Dreamweaver, к примеру)?
— — Будут ли использованы DHTML, Channels, Push технологии?
Затем вы должны определиться с навигацией. Как будет посетитель продвигаться по сайту? Какая связь существует между страницами, куда можно попасть от куда и т.д. Для большинства проектов нет нужды придумывать новые навигационные схемы. Учитесь на сайтах, которые вам нравятся больше всего: проще — лучше. Подгоните существующую удачную модель под нужды своего проекта и используйте ее. Людям необходима возможность легко передвигаться по сайту, только и всего.

Дизайн интерфейса.

Творческие поиски и разработка стиля
Создание прототипов
Утверждение заказчиком
Графическое производство: дизайн датабаз и форм, анимации, графика в
GIF/Jpeg, обработка в html.

Вы изучили своего заказчика, представляете содержание каждой будущей страницы и вовсю идет работа над текстами. Самое время заняться интерфейсом. Начните с самой важной страницы, работайте над ней до тех пор, пока у вас не будет как минимум 15 набросков различных вариантов, из которых 5 можно развить дальше. Когда страничка начнет дымиться, поработайте над другими. Продолжайте искать идеи, рисовать и думать.
Попробуйте поэксперементировать с различными эффектами: real audio/vidio, динамическое html, необычное использование тегов и т.д.
Пусть ваш альбом наполнится зарисовками для входного экрана, навигационных элементов, ключевой графики и второстепенных, украшающих элементов.
Используйте коллаж. Проанимируйте частицу большого изображения. Поиграйте со шрифтами, слоями, текстурами, эмоциями. Как только вы найдете удачную тему, проработайте ее как можно глубже, потом отложите в сторону и примитесь за новую.
Вообразите себя пользователем и попробуйте смотреть на окружающий мир,
Интернет его глазами. Походите по сайтам, где он может бывать, полистайте его журналы, пообщайтесь с его возможным окружением…
Используйте графический редактор. Очень удобно скопировать окно браузера
(F13 или Print Scrn, далее Ctrl+double click в окне графического редактора, затем Ctrl+V в новый файл) в Фотошоп или Иллюстратор и накладывать слои композиции прямо на него.
Выберите 3 законченных варианта: ваш любимый, несколько экстравагантный и консервативный, который, вы уверены, понравится заказчику. Создайте для них прототипы, которые он сможет посмотреть и одобрить. Прототип — черновой вариант слинкованных между собой основных страниц сайта. Не обязательно писать код для этих страниц, вы прекрасно можете обойтись image-maps.
Пореже страницы на части и пролинкуйте графику между собой. Не тратьте время на ее оптимизацию, и объясните заказчику, что она немного потеряет в качестве при дальнейшей обработке. Задача прототипов — хорошо смотреться в окне браузера и понравится заказчику.

Программирование.

Создание: CGI, Javascript, Java, формы, датабазы
HTML: кодирование
Валидация: содержания, грамматических ошибок, работы линков
Тестирование в различных браузерах.

После того как вы разработали дизайн и сверстали модели основных страниц, можно приниматься за техническую работу — HTML кодирование, CGI формы, датабазы и прочее программирование.
Несколько советов:
1. Когда над сайтом работают несколько человек, обязательно стоит договорится об общей логической системе наименований. Если каждый будет скидывать свои творения куда захочется, это будет существенно затруднять поиск коллегам, и в конце все равно приведет к переименованию.
2. Рассортируйте ваши графические файлы по классам в зависимости от их размера. Старайтесь держать количество таких классов минимальным. Например: заголовки, подзаголовки, «ноготки», полная графика и т.д. Графические размеры от 1 до 5.
3. Подберите оптимальную палитру для графики в одном отдельно взятом классе и используйте ее на всех файлах данного класса. Работая над большим сайтом удобно использoвать DeBabelizer (http://www.equilibrium.com), сценарии которого позволяют очень быстро и точно процессить большое кол-во файлов.
Так же, он, в отличие от Photoshop (http://www.adobe.com), не сдвигает цвета «безопасной веб-палитры» в сторону при оптимизации.
4. Используйте в своем коде, оставляя пояснения для программистов и создателей текстов.
5. Используйте абсолютно схожий код на различных страницах, для облегчения глобального поиска и изменений.
6. Если на странице очень много текста и других материалов, удалите все
«возвраты каретки» и коменты из кода, что существенно снизит размер файла.
7. Потратьте время на изучение тех программ, с которыми работаете, ваша продуктивность резко повысится. Следите за выходом новых версий и обновляйте свои инструменты регулярно.
8. Делайте копии (Back up?) того, что сделали каждый день по окончанию работы.
9. Проверяйте свою работу на разных браузерах и основных ОС. Поменяйте настройки в браузерах выставив большие или маленькие размеры шрифтов, изменив цветовые настройки, откройте все меню и бары которые имеются.
10. Проверяйте:
— Грамматику
— — Правильное название файлов
— — Работу линков
— — Название страниц в поле Титул
— — Фоновые цвета
— — Целостность и тегов
— — Визуальное выравнивание
— — Что получится при изменении размеров окна браузера, шрифтов, цветов?
— — Различия резолюций. А как оно будет смотреться в монохроме?
11. Тестируйте, тестируйте и еще раз тестируйте. Подключайте как можно больше людей к этому процессу. Для заказчика это отличная возможность
«поучаствовать» в проекте. Если есть возможность проверить на будущих посетителях, не упускайте ее. Внимательно следите как люди со свежим взглядом на сайт реагируют на вашу навигацию и систему наименований. Не пытайтесь помочь им «найти» что-либо, но попросите комментировать каждый шаг. Например, куда они ожидают попасть при клике на ту или иную кнопку?
Часто бывает очень удобно распечатать весь сайт на бумаге и проверять стилистические и грамматические ошибки таким образом.
Сравнительная таблица популярности браузеров (по данным StatMarket за
Январь 2001)
Microsoft 68.94% Netscape 29.09% Other 1.96

Публикация и Маркетинг.

Публикация:
Выбор хост-провайдера, покупка или регистрация имени домейна
FTP веб-сайта на сервер: создание дерикторий, установка permissions
Последние проверки и валидации
Маркетинг:
Регистрация сервера в основных поисковиках
Раскрутка
Поддержка: страница новостей, автоматические обновления
Презентация сервера и Празднование столь знаменательного события

Последние работы над сайтом могут включать следующее:
— Создание банеров/заголовков про запас
— — Добaвление последнего контекста
— — Запуск CGI сценариев
— — обновление линков (старайтесь всегда давать условные пути к документам, а не полный URL. К примеру, ../images/dot.gif вместо http://www.yoursite.ru/images/dot.gif Таким образом вам не придется менять данные во всех ссылках при переносе сайта на сервер нового провайдера, если в будущем возникнет подобная необходимость.)
— — написание мета-тегов
— — добавление авторских прав и предупреждений
— — убедитесь, что графика везде имеет атрибуты width и height, соответствует основной цветовой палитре, имеет «Alt» пояснения.
При выборе имени домейна, старайтесь выбирать простые и легко запоминающиеся слова. Следуйте следующим правилам:
— Краткость и Простота. Короткие адреса легче запоминаются, в них сложнее сделать ошибку: Gazeta.ru, Pupkin.com
— — Описание. Хорошо, когда по адресу можно догадаться о содержании сайта.

Имя компании не всегда является достаточным пояснением: beerclub.com тумана не напустит
— Запоминаемость. Лучшие адреса добавляют к простоте элемент интереса — частенько игру слов, как в www.anekdotov.net — который поможет посетителям помнить это название через часы, дни и месяцы. Идеально, когда адрес можно запомнить, услышав в разговоре или по радио. Скопируйте структуру сайта со своей машины на сервер заказчика и еще раз протестируйте каждую страничку в брaузере. Конфигурация чужого сервера может потребовать изменений в сценариях или расширениях файлов (htm вместо html). Убедитесь все работает так, как вы предполагали.
Проведите хорошую рекламную компанию своему сайту.

Веб-страницы и веб-приложения.

Классификация веб-объектов.

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

Согласно спецификации W3C минимальный html-документ обязательно должен содержать всего два тега, без которых вообще не является никаким документом. Это теги !DOCTYPE (DTD) и TITLE. Почему настолько важен тег содержащий DTD? Именно тег !DOCTYPE определяет то, что документ является
HTML, а не, например, XML-файлом.
Пример:

DTD – Document Type Definition – определяет тип и принадлежность документа, а так же его версия и некоторые другие параметры, как например, в спецификации DTD полностью описаны все теги HTML 4.2 менее чем на 20 страницах.

Ортогональность содержания и представления информации подразумевает собой независимость содержания информации от способа ее представления. Говоря упрощенным языком, это ситуация, когда информативность или информативная часть документа не зависит от способа ее отображения, дизайна, размещения, стилей, шрифтов и т.п. К сожалению, практически ни один из существующих на данный момент языков разметки не обладает в чистом виде таким свойством, за исключением XML, который наиболее близок к этому, но все равно еще в значительной мере остается на стадии разработки. Например, в том же языке
HTML таблица может использоваться для предоставления информации именно как таблица, но может быть использована так же для размещения элементов дизайна в необходимом порядке и относительном расположении на странице.

Веб-страницы. Языки разметки. (HTML, XML)

Основы HTML

В HTML 4.2 включены механизмы поддержки таблиц стилей, скриптов, внедрения объектов, улучшена поддержка направления текста справа налево и смешанного текста, а также внесены изменения в формы с целью обеспечения удобства работы пользователей с физическими недостатками.

HTML-документ имеет достаточно строго структурирован:

Untitled

…

СПИСОК ЭЛЕМЕНТОВ HTML базисные элементы (все документы на HTML должны содержать их) определение структуры (вид задается параметрами программы-просмотрщика) внешний вид (автор определяет внешний вид текста) ссылки и графика разделители списки фон и цвета специальные символы формы таблицы фреймы (frames) язык Java разное
Внимание: Если вам не ясна разница между HTML 2.0, HTML 3.0, HTML 3.2, и дополнениями Netscape, я советую прочитать комментарии W3C о развитии языка
HTML.
УПОТРЕБЛЯЕМЫЕ СИМВОЛЫ
URL URL (адрес) внешнего файла (или просто имя файла в том же каталоге)
? Любое число (т.е. значит , , , и т.д.)
% Любой процент (т.е. » значит «, и т.д.)
*** Любой текст (т.е. ALT=»***» значит заполните текст)
$$$$$$ Любое 16ричное число (т.е. BGCOLOR=»#$$$$$$» значит
BGCOLOR=»#00FF1C», и т.д.)
,,, Разделенное запятыми (т.е. COORDS=»,,,» значит COORDS=»0,0,50,50″, и т.д.)
| Альтернативы (т.е. ALIGN=LEFT|RIGHT|CENTER значит один из них)
СОВМЕСТИМОСТЬ
(помните, HTML эволюционирует и просмотрщики бывают разные)

(без отметки) Включено в HTML 3.2; должно работать с последними версиями просмотрщиков
N1.0 дополнение Netscape, введенное в Navigator’е версии 1.0
N1.1 дополнение Netscape, введенное в Navigator’е версии 1.1
N2.0 дополнение Netscape, введенное в Navigator’е версии 2.0
N3.0b дополнение Netscape, введенное в Navigator’е версии 3.0 бета

|БАЗИСНЫ| | | |
|Е | | | |
|ЭЛЕМЕНТ| | | |
|Ы | | | |
| |Тип документа | |(начало и конец файла) |
| |Имя документа | |(должно быть в заголовке) |
| |Заголовок | |(описание документа, |
| | | |например его имя) |
| |Тело | |(содержимое страницы) |

|ОПРЕДЕ| | | |
|ЛЕНИЕ | | | |
|СТРУКТ| | | |
|УРЫ | | | |
| |Заглавие | |(стандарт |
| | | |определяет |
| | | |6 уровней) |
| |с выравниванием | | |
| |Секция | | |
| |с выравниванием || |
| |Цитата | |(обычно |
| | | |выделяется |
| | | |отступом) |
| |Выделение | |(обычно |
| | | |изображаетс|
| | | |я курсивом)|
| |Дополнительное | |(обычно |
| |выделение | |изображаетс|
| | | |я жирным |
| | | |шрифтом) |
| |Отсылка, цитата | |(обычно |
| | | |курсив) |
| |Код | |(для |
| | | |листингов |
| | | |кода) |
| |Пример вывода | | |
| |Ввод с клавиатуры | | |
| |Переменная | | |
| |Определение | |(часто не |
| | | |поддерживае|
| | | |тся) |
| |Адрес автора | | |
| |Большой шрифт | | |
| |Маленький шрифт | | |

|ВНЕШ| | | |
|НИЙ | | | |
|ВИД | | | |
| |Жирный | | |
| |Курсив | | |
|N3.0|Подчеркнутый | |(часто не |
|b | | |поддерживается) |
| |Перечеркнутый | |(часто не |
| | | |поддерживается) |
|N3.0|Перечеркнутый | |(часто не |
|b | | |поддерживается) |
| |Верхний индекс | | |
| |Нижний индекс | | |
| |Печатная машинка | |(изображается |
| | | |как шрифт |
| | | |фиксированной |
| | | |ширины) |
| |Форматированый | |(сохранить |
| | | |формат текста |
| | | |как есть) |
| |Ширина | |(в символах) |
| |Центрировать | > |(как текст, так |
| | | |и графика) |
|N1.0|Мигающий | |(наиболее |
| | | |осмеянный |
| | | |элемент) |
| |Размер шрифта | |(от 1 до 7) |
| |Изменить размер | | |
| |шрифта | | |
|N1.0|Базовый размер | |(от 1 до 7; по |
| |шрифта | |умолчанию 3) |
| |Цвет шрифта | | |
|N3.0|Выбор шрифта | | |
|b | | | |
|N3.0|Многоколоночный || |
|b |текст | | |
|N3.0|Пробел между | |точек) |
|N3.0|Ширина колонки | | |
|N3.0|Пустой блок | | |
|b | | | |
|N3.0|Тип пустого блока | | |
|N3.0|Величина пустого | | |
|b |блока | | |
|N3.0|Размеры пустого | | |
|b |блока | | |
|N3.0|Выравнивание | | |

|ССЫЛК| | | |
|И И | | | |
|ГРАФИ| | | |
|КА | | | |
| |Ссылка | | |
| |Ссылка на закладку | |(в другом |
| | | |документе) |
| | | |(в том же |
| | | |документе) |
|N2.0 |На другое окно | | |
| |Определить закладку | | |
| |Отношение | |(часто не |
| | | |поддерживается|
| | | |) |
| |Обратное отношение | |(часто не |
| | | |поддерживается|
| | | |) |
| |Графика | | |
| |Выравнивание | | |
|N1.0 |Выравнивание | | |
| |Альтернатива | |(выводится |
| | | |если картинка |
| | | |не |
| | | |изображается) |
| |Карта | |(нужна также |
| | | |программа) |
| |Локальная карта | | |
| |Определение карты | | |
| |Области карты | | |
| |Размеры | | |
| |Окантовка | |(в точках) |
| |Отступ | | |
|N1.0 |Заменитель в низком | | |
|N1.1 |Обновить | | |
|N2.0 |Включить объект | |(вставить |
| | | |объект в |
| | | |страницу) |
|N2.0 |Размер объекта | | |

|РАЗД| | | |
|ЕЛИТ| | | |
|ЕЛИ | | | |
| |Параграф | |(закрывать |
| | | |элемент часто |
| | | |не обязательно)|
| |Выравнивание | | |
| |Новая строка | |(одиночный |
| | | |перевод строки)|
| |Убрать выравнивание| | |
| |Горизонтальный | | |
| |разделитель | | |
| |Выравнивание | | |
| |Толщина | |(в точках) |
| |Ширина | |(в точках) |
|N1.0|Ширина в процентах | |(в процентах от|
| | | |ширины |
| | | |страницы) |
| |Сплошная линия | |(без трехмерных|
| | | |эффектов) |
|N1.0|Нет разбивки | |(запрещает |
| | | |перевод строки)|
|N1.0|Перенос | |(где разбивать |
| | | |строку для |
| | | |переноса при |
| | | |необходимости) |

|СПИ| | | | |
|СКИ| | | | |
| |Неупорядоченный | |( перед | |
| | | |каждым | |
| | | |элементом) | |
| |Компактный | | | |
| |Тип метки | |(для всего | |
| | | |списка) | |
| | | |(этот и | |
| | | |последующие) | |
| |Нумерованный | |( перед | |
| | | |каждым | |
| | | |элементом) | |
| |Компактный | | | |
| |Тип нумерации | |(для всего | |
| | | |списка) | |
| | | |(этот и | |
| | | |следующие) | |
| |Первый номер | |(для всего | |
| | | |списка) | |
| | | |(этот и | |
| | | |следующие) | |
| |Список определений | |(=термин,| |
| | | |=определе| |
| | | |ние) | |
| |Компактный | | | |
| |Меню | |( перед | |
| | | |каждым | |
| | | |элементом) | |
| |Компактное | | | |
| |Каталог | |(перед | |
| | | |каждым | |
| | | |элементом) | |
| |Компактный | | | |