КулЛиб электронная библиотека 

Операционная система UNIX [Андрей Робачевский] (fb2) читать онлайн


Настройки текста:



Андрей Робачевский Операционная система UNIX

Выражение признательности

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

В первую очередь это заслуга директора издательства "BHV–Санкт-Петербург" Вадима Сергеева и моего коллеги, сотрудника Вузтелекомцентра и автора замечательного справочника "Желтые страницы Internet. Русские ресурсы" Алексея Сигалова. Именно они убедили меня в том, что такая книга окажется полезной и вдохновили взяться за перо.

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

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

Я неоднократно обращался за советом к экспертам по UNIX и прежде всего к моему коллеге Константину Федорову. Его ценные замечания и рекомендации помогли мне довести книгу до ее настоящего вида.

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

Я также хотел бы выразить глубокую признательность рецензентам этой книги — зав. кафедрой "Вычислительная техника" Санкт-Петербургского государственного электротехнического университета д.т.н. профессору Д.В. Пузанкову и зав. кафедрой "Информационные и управляющие системы" Санкт-Петербургского государственного Технического университета д.т.н. профессору И.Г. Черноруцкому за полезные замечания.

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

Я не могу не выразить признательность моим коллегам по работе Владимиру Парфенову, Юрию Гугелю, Юрию Кирчину, Нине Рубиной, дружеская поддержка которых была так кстати.

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

Автор

О книге «Операционная система UNIX»

Посвящается моим близким

Назначение книги

Данная книга не является заменой справочников и различных руководств по операционной системе UNIX. Более того, сведения, представленные в книге, подчас трудно найти в документации, поставляемой с операционной системой. Эти издания насыщены практическими рекомендациями, скрупулезным описанием настроек тех или иных подсистем, форматов вызова команд и т.п. При этом за кадром часто остаются такие вопросы, как внутренняя архитектура отдельных компонентов системы, их взаимодействие и принципы работы. Без знания этой "анатомии" работа в операционной системе превращается в использование заученных команд, а неизбежные ошибки приводят к необъяснимым последствиям. С другой стороны, в данной книге вопросам администрирования UNIX, настройке конкретных подсистем и используемым командам уделено значительно меньше внимания. Цель данной книги заключается в изложении основ организации операционной системы UNIX. Следует иметь в виду, что именем UNIX обозначается значительное семейство операционных систем, каждая из которых имеет свое название и присущие только ей особенности. В этой книге сделана попытка выделить то общее, что составляет "генотип" UNIX, a именно: базовый пользовательский и программный интерфейсы, назначение основных компонентов, их архитектуру и взаимодействие, и на основе этого представить систему в целом. В то же время там, где это имеет значение, приводятся ссылки на конкретную версию UNIX. Для иллюстрации отдельных положений использовались следующие операционные системы: Solaris 2.5 фирмы Sun Microsystems, SCO ODT 5.0 фирмы Santa Cruz Operation, BSDi/386 фирмы Berkeley Software Design.

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

Книга может оказаться полезной при подготовке ряда лекционных программ по операционной системе UNIX и основам организации операционных систем в целом. Материал главы 1 является хорошей основой для вводного курса по UNIX. В нем представлены основные понятия и организация операционной системы в целом. В этой же главе приведены основные сведения о пользовательском интерфейсе и языке программирования командного интерпретатора shell.

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

Главы 3–6 содержат более детальное обсуждение отдельных компонентов UNIX: файловой подсистемы, подсистемы управления процессами и памятью, подсистемы ввода/вывода. Эти сведения подойдут как для углубленного курса по UNIX, так и для курса по принципам организации операционных систем. Отдельные части главы 6 могут быть также включены в курс по компьютерным сетям.

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

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

На кого рассчитана эта книга?

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

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

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

Принятые обозначения

Системные вызовы, библиотечные функции, команды shell выделены в тексте курсивом, например open(2), cat(1) или printf(3S). В скобках указывается раздел электронного справочника man(1) (описание справочника приведено в приложении А).

Структуры данных, переменные и внутренние функции подсистем ядра, исходные тексты программ и примеры работы в командной строке напечатаны шрифтом фиксированной ширины. Например, d_open(), sleep() или пример программы:

int main() {

 exit();

}

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

$ passwd

Enter old password:

Имена файлов выделены полужирным начертанием, например /etc/passwd или <sys/user.h>.

Клавиши клавиатуры показаны курсивом и заключены в угловые скобки, например <Del> или <Ctrl>+<C> (в последнем случае показана комбинация клавиш).

Введение

Скоро исполнится 30 лет с момента создания операционной системы UNIX. Изначально созданная для компьютера PDP-7 с 4 килобайтами оперативной памяти, сегодня UNIX работает на множестве аппаратных платформ, начиная с обыкновенного PC и заканчивая мощными многопроцессорными системами и суперкомпьютерами.

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

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

История создания

В 1965 году Bell Telephone Laboratories (подразделение AT&T) совместно с General Electric Company и Массачусетсским институтом технологии (MIT) начали разрабатывать новую операционную систему, названную MULTICS (MULTiplexed Information and Computing Service). Перед участниками проекта стояла цель создания многозадачной операционной системы разделения времени, способной обеспечить одновременную работу нескольких сотен пользователей. От Bell Labs в проекте приняли участие два сотрудника — Кен Томпсон (Ken Tompson) и Дэннис Ритчи (Dennis Ritchie). Хотя система MULTICS так и не была завершена (в 1969 году Bell Labs вышла из проекта), она стала предтечей операционной системы, впоследствии получившей название UNIX.

Однако Томпсон, Ритчи и ряд других сотрудников продолжили работу над созданием удобной среды программирования. Используя идеи и разработки, появившиеся в результате работы над MULTICS, они создали в 1969 году[1] небольшую операционную систему, включавшую файловую систему, подсистему управления процессами и небольшой набор утилит. Система была написана на ассемблере и применялась на компьютере PDP-7. Эта операционная система получила название UNIX, созвучное MULTICS и придуманное другим членом группы разработчиков, Брайаном Керниганом (Brian Kernighan).

Хотя ранняя версия UNIX много обещала, она не смогла бы реализовать весь свой потенциал без применения в каком-либо реальном проекте. И такой проект нашелся. Когда в 1971 году патентному отделу Bell Labs понадобилась система обработки текста, в качестве операционной системы была выбрана UNIX. К тому времени система UNIX была перенесена на более мощный PDP-11, да и сама немного подросла: 16К занимала собственно система, 8К отводились прикладным программам, максимальный размер файла был установлен равным 64К при 512К дискового пространства.

Вскоре после создания первых ассемблерных версий Томпсон начал работать над компилятором для языка FORTRAN, а в результате разработал язык В. Это был интерпретатор со всеми свойственными интерпретатору ограничениями, и Ритчи переработал его в другой язык, названный С, позволявший генерировать машинный код. В 1973 году ядро операционной системы было переписано на языке высокого уровня С, — неслыханный до этого шаг, оказавший громадное влияние на популярность UNIX. Это означало, что теперь система UNIX может быть перенесена на другие аппаратные платформы за считанные месяцы, кроме того, значительная модернизация системы и внесение изменений не представляли особых трудностей. Число работающих систем в Bell Labs превысило 25, и для сопровождения UNIX была сформирована группа UNIX System Group (USG).

Исследовательские версии UNIX

В соответствии с федеральным законодательством AT&T не имела права коммерческого распространения UNIX и использовала ее для собственных нужд, но начиная с 1974 года операционная система стала передаваться университетам для образовательных целей.

Операционная система модернизировалась, каждая новая версия снабжалась соответствующей редакцией Руководства Программиста, откуда и сами версии системы получили название редакций (Edition). Всего было выпущено 10 версий-редакций, первая из которых вышла в 1971, а последняя — в 1989 году. Первые семь редакций были разработаны в Bell Labs.

Группой компьютерных исследований (Computer Research Group, CRG) и предназначались для компьютеров PDP-11, позже — для VAX. Другая группа, UNIX System Group, отвечала за сопровождение системы. Третья группа (Programmer's WorkBench, PWB) занималась разработкой среды программирования, ей мы обязаны появлением системы SCCS, именованных каналов и других важных идей. Вскоре после выпуска Седьмой редакции разработкой системы стала заниматься USG.

Наиболее важные версии:

Первая редакция 1971 Первая версия UNIX, написанная на ассемблере для PDP-11. Включала компилятор В и много известных команд и утилит, в том числе cat(1), chdir(1), chmod(1), cp(1), ed(1), find(1), mail(1), mkdir(1), mkfs(1M), mount(1M), mv(1), rm(1), rmdir(1), wc(1), who(1). В основном использовалась как инструментальное средство обработки текстов для патентного отдела.
Третья редакция 1973 В системе появилась команда cc(1), запускавшая компилятор С. Число установленных систем достигло 16.
Четвертая редакция 1973 Первая система, в которой ядро написано на языке высокого уровня С.
Шестая редакция 1975 Первая версия системы, доступная за пределами Bell Labs. Система полностью переписана на языке С. С этого времени начинается появление новых версий, разработанных за пределами Bell Labs, и рост популярности UNIX. В частности, эта версия системы была установлена Томпсоном в Калифорнийском университете в Беркли, и на ее основе вскоре была выпущена первая версия BSD (Berkeley Software Distribution) UNIX.
Седьмая редакция 1979 Эта версия включала командный интерпретатор Bourne Shell и компилятор С от Кернигана и Ритчи. Ядро было переписано для упрощения переносимости системы на другие платформы. Лицензия на эту версию была куплена фирмой Microsoft, которая разработала на ее базе операционную систему XENIX.
Популярность UNIX росла, и к 1977 году число работающих систем уже превысило 500. В 1977 году компания Interactive Systems Corporation стала первым VAR (Value Added Reseller) системы UNIX, расширив ее для использования в системах автоматизации. Этот же год стал годом первого портирования UNIX с незначительными изменениями на компьютер, отличный от PDP.

Генеалогия UNIX

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

System V UNIX

Начиная с 1975 года фирма AT&T начала предоставлять лицензии на использование операционной системы как научно-образовательным учреждениям, так и коммерческим организациям. Поскольку основная часть системы поставлялась в исходных текстах, написанных на языке С, опытным программистам не требовалось детальной документации, чтобы разобраться в архитектуре UNIX. С ростом популярности микропроцессоров другие компании переносили UNIX на различные платформы, но простота и ясность операционной системы искушали многих на ее расширение и модификацию, в результате чего появилось много различных вариантов базовой системы.

Не желая терять инициативу, AT&T в 1982 объединила несколько существующих версий UNIX и создала версию под названием System III. В отличие от редакций, предназначавшихся, в первую очередь, для внутреннего использования и не получивших дальнейшего развития, System III была создана для распространения за пределами Bell Labs и AT&T и положила начало мощной ветви UNIX, которая и сегодня жива и развивается.

В 1983 году Bell Labs выпустила новую версию системы — System V. В 1984 году группа USG была трансформирована в лабораторию (UNIX System Development Laboratory, USDL), которая вскоре выпустила новую модификацию системы — System V Release 2 (SVR2). В этой версии были реализованы такие механизмы управления памятью, как замещение страниц и копирование при записи (copy on write), и представлена система межпроцессного взаимодействия (InterProcess Communication, IPC) с разделяемой памятью, очередью сообщений и семафорами.

В 1987 году появилась следующая версия — System V Release 3 (SVR3). За ее разработку отвечало новое подразделение AT&T — Информационные системы AT&T (AT&T Information Systems, ATTIS). Эта версия отличалась большим набором дополнительных возможностей, включавших:

□ Подсистему ввода/вывода, основанную на архитектуре STREAMS.

□ Переключатель файловой системы (File System Switch), обеспечивавший одновременную поддержку различных файловых систем.

□ Разделяемые библиотеки.

□ Программный интерфейс сетевых приложений Transport Layer Interface (TLI).

System V Release 4 (SVR4)

В 1989 году была выпущена новая основная версия — System V Release 4. По существу она объединила возможности нескольких известных версий UNIX: SunOS фирмы Sun Microsystems, BSD UNIX компании Berkeley Software Distribution и предыдущих версий System V.

Новые черты системы включали:

□ Командные интерпретаторы Korn и С (BSD)

□ Символические ссылки

□ Систему терминального ввода/вывода, основанную на STREAMS (System V)

□ Отображаемые в память файлы (SunOS)

□ Сетевую файловую систему NFS и систему вызова удаленной процедуры RPC (SunOS)

□ Быструю файловую систему FFS (BSD)

□ Сетевой программный интерфейс сокетов (BSD)

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

Многие компоненты системы были поддержаны стандартами ANSI, POSIX, X/Open и SVID.

UNIX компании Berkeley Software Distribution

Четвертая редакция UNIX была установлена в Калифорнийском университете в Беркли в 1974 году. С этого момента начинает свою историю ветвь UNIX, известная под названием BSD UNIX. Первая версия этой системы основывалась на Шестой редакции и была выпущена в 1978 году. В 1979 году на базе Седьмой редакции была разработана новая версия UNIX — 3BSD. Она явилась первой версией BSD, перенесенной на ЭВМ VAX. В этой системе, в частности, были реализованы виртуальная память (virtual memory) и страничное замещение по требованию (demand paging).

Важным для развития системы явился 1980 год, когда фирма Bolt, Beranek and Newman (BBN) подписала контракт с Отделом перспективных исследовательских проектов (DARPA) Министерства обороны США на разработку поддержки семейства протоколов TCP/IP в BSD UNIX. Эта работа была закончена в конце 1981 года, а ее результаты интегрированы в 4.2BSD UNIX.

Версия 4.2BSD была выпущена в середине 1983 года и включала поддержку работы в сетях, в частности, в сетях Ethernet. Это способствовало широкому распространению локальных сетей, основанных на этой технологии. Система 4.2BSD также позволяла подключиться к сети ARPANET, быстрый рост которой наблюдается с начала 80-х. Разумеется, такая операционная система не могла не пользоваться большой популярностью. К тому же, в отличие от положения в AT&T, где сетевые разработки обычно не выходили за пределы компании, результаты, полученные в Беркли, были широко доступны. Поэтому 4.2BSD стала наиболее популярной системой в исследовательских кругах.

Однако большое количество нововведений привело к тому, что система получилась сырой, содержала ряд ошибок и имела определенные проблемы с быстродействием. В 1986 году была выпущена следующая версия — 4.3BSD, более надежная и с лучшей производительностью. В период с 1986 по 1990 год в систему было внесено много дополнений, включая сетевую файловую систему NFS, виртуальную файловую систему VFS, отладчик ядра и мощную поддержку сети.

Последними версиями, выпущенными в Беркли, стали системы 4.4BSD и BSD Lite, появившиеся в 1993 году.

OSF/1

В 1988 году AT&T и Sun Microsystems заключили соглашение о сотрудничестве в области разработки будущих версий System V. В ответ на это ряд компаний, производящих компьютеры или имеющих отношение к вычислительной технике, включая IBM, DEC, Hewlett-Packard, создали организацию под названием Open Software Foundation (OSF), целью которой являлась разработка независимой от AT&T версии операционной системы. Результатом деятельности этой организации стала операционная система OSF/1. Хотя ряд коммерческих операционных систем связывают себя с этой ветвью, нельзя сказать, что OSF/1 явилась новым словом в мире UNIX. Скорее, это был политический шаг, призванный снизить доминирующую роль ряда фирм, занимавшихся разработкой UNIX System V.

Версии UNIX, использующие микроядро

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

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

□ Микроядро Mach, разработанное в университете Карнеги-Меллона. Сегодня Mach используется в системе OSF/1 фирмы DEC для серверов с процессорами Alpha, а также в операционной системе Workplace фирмы IBM.

□ Микроядро Chorus. На базе этого микроядра созданы системы Chorus/MiX V.3 и Chorus/MiX V.4, являющиеся "серверизацией" SVR3 и SVR4. При этом ядро UNIX разделено на множество серверов, выполняющихся под управлением микроядра, причем эти серверы могут находиться как на одном компьютере, так и быть распределены в сети.

Свободно распространяемая система UNIX

Достаточно дешевый PC и свободно распространяемая система UNIX делают эту систему сегодня доступной практически каждому.

Очень популярная версия UNIX для PC, называемая Minix, была разработана Энди Тэненбаумом (Andy Tanenbaum) как приложение к его книге по архитектуре UNIX. Книга Тэненбаума содержит полные листинги исходных текстов системы. Дополнительный набор дискет позволяет установить Minix даже на PC с процессором 8086 (если найдется такой компьютер).

В последнее время все большую популярность приобретает свободно распространяемая версия UNIX под названием Linux, разработанная исследователем университета Хельсинки Линусом Торвальдсом (Linus Torvalds). Разработанная "с нуля" для процессора Intel i386, сегодня она перенесена на ряд других аппаратных платформ, включая серверы Alpha фирмы DEC.

Основные стандарты

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

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

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

IEEE и POSIX

В 1980 году была создана инициативная группа под названием /usr/group с целью стандартизации программного интерфейса UNIX, т. е. формального определения услуг, предоставляемых операционной системой приложениям. Решение этой задачи упростило бы переносимость приложений между различными версиями UNIX. Такой стандарт был создан в 1984 году и использовался комитетом ANSI, отвечающим за стандартизацию языка С, при описании библиотек. Однако с ростом числа версий операционной системы эффективность стандарта уменьшилась, и через год, в 1985 году, был создан Portable Operating System Interface for Computing Environment, сокращенно POSIX (переносимый интерфейс операционной системы для вычислительной среды).

В 1988 году группой был разработан стандарт POSIX 1003.1-1988, который определил программный интерфейс приложений (Application Programming Interface, API). Этот стандарт нашел широкое применение во многих операционных системах, в том числе и с архитектурой, отличной от UNIX. Спустя два года стандарт был принят как стандарт IEEE 1003.1-1990. Заметим, что поскольку этот стандарт определяет интерфейс, а не конкретную реализацию, он не делает различия между системными вызовами и библиотечными функциями, называя все элементы программного интерфейса просто функциями.

Другими наиболее значительными стандартами POSIX, относящимися к UNIX, являются:

POSIX 1003.2-1992 Включает определение командного интерпретатора UNIX и набора утилит
POSIX 1003.1b-1993 Содержит дополнения, относящиеся к поддержке приложений реального времени
POSIX 1003.1c-1995 Включает определения "нитей" (threads) POSIX, известных также как pthreads

X/Open

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

Основной задачей организации X/Open являлось согласование и утверждение стандартов для создания общего программного интерфейса и программкой среды для приложений. В 1992 году появился документ, известный под названием X/Open Portability Guide версии 3 или XPG3, который включал POSIX 1003.1-1988 и стандарт на графическую систему X Window System, разработанную в Массачусетсском институте технологии.

В дальнейшем интерфейсы XPG3 были расширены, включив базовые API систем BSD и System V (SVID), в том числе и архитектуру STREAMS. В результате была выпущена спецификация, ранее известная как Spec 11/70, а в 1994 году получившая название XPG4.2.

В 1996 году объединение усилий X/Open и OSF привело к созданию консорциума The Open Group, продолжившего разработки в области открытых систем. В качестве примера можно привести такие направления, как дальнейшая разработка пользовательского интерфейса, Common Desktop Environment (CDE), и его сопряжение со спецификацией графической оболочки Motif. Другим примером является разработка стандартных интерфейсов для распределенной вычислительной среды Distributed Computing Environment (DCE), работа над которой была начата OSF.

SVID

Вскоре после выхода в свет в 1984 году версии SVR2, группа USG выпустила документ под названием System V Interface Definition, SVID, в котором описывались внешние интерфейсы UNIX версий System V. По существу, этот труд (в двух томах) определял соответствие операционной системы версии System V.

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

С появлением SVR4 было выпущено новое издание SVID (уже в четырех томах) и, соответственно, новый SWS.

ANSI

В конце 1989 года Американским национальным институтом стандартов (American National Standards Institute, ANSI) был утвержден стандарт X3.159-1989 языка программирования С. Целью появления этого стандарта являлось улучшение переносимости программ, написанных на языке С, в различные операционные системы (не только UNIX). Стандарт определяет не только синтаксис и семантику языка, но и содержимое стандартной библиотеки.

Некоторые известные версии UNIX

Сегодня существуют десятки различных операционных систем, которые можно называть UNIX. В основном, это коммерческие версии, в которых создатели пытались как можно эффективнее решить вопросы реализации той или иной подсистемы. Во многих случаях, производитель операционной системы является и производителем аппаратной платформы, для которой эта система предназначена. В качестве примеров можно привести операционные системы SunOS и Solaris фирмы Sun Microsystems, HP-UX фирмы Hewlett-Packard, AIX фирмы IBM, IRIX фирмы Silicon Graphics. Вполне естественно, что производитель хочет сделать операционную систему привлекательнее, чем у конкурентов, и не только за счет лучшей производительности, но и за счет расширений и дополнительных возможностей, отсутствующих у других. С другой стороны, производитель желает, чтобы его операционная система оставалась открытой: сегодня закрытые корпоративные решения отпугивают потребителя. Понятно, что в такой ситуации единства и борьбы противоположностей вряд ли найдется система, которую можно назвать "чистой системой UNIX". Да и такое понятие сегодня вряд ли существует. По мнению некоторых разработчиков последней "чистой системой UNIX" являлась Седьмая редакция, сегодня же можно говорить только о наличии в операционной системе черт той или иной ветви — System V, BSD или OSF/1. Можно, например, сказать, что с точки зрения администрирования и набора утилит Digital UNIX представляет смесь System V и BSD UNIX, но с точки зрения интерфейсов и организации системы — это BSD.

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


Таблица 1. К какой генеалогической ветви принадлежит ваша система?

Индикатор Типично для SVRx Типично для xBSD
Имя ядра /unix /vmunix
Терминальная инициализация /etc/inittab /etc/ttys
Файлы инициализации системы каталоги /etc/rc*.d файлы /etc/rc.*
Конфигурация монтируемых файловых систем /etc/mnttab /etc/mtab
Обычный командный интерпретатор sh(1), ksh(1) csh(1)
"Родная" файловая система S5 (размер блока: 512– 2048 байт), имена файлов <= 14 символов UFS (размер блока: 4K–8K), имена файлов < 255 символов
Система печати lp(1), lpstat(1), cancel(1) lpr(1), lpq(1), lprm(1M) (lpd daemon)
Управление терминалами terminfo(4) termcap(4)
Отображение активности процессов ps -ef ps -aux
Ниже приведены краткие характеристики наиболее популярных версий UNIX.

AIX

Версия UNIX фирмы IBM на базе SVR2 со многими чертами SVR4, BSD и OSF/1. Собственная система администрации (SMIT).

HP-UX

Версия UNIX фирмы Hewlett-Packard. В 1996 году компания выпустила новые версии — HP-UX 10.10 и HP-UX 10.20, включающие поддержку симметричных многопроцессорных систем (SMP), файловых систем большого размера (до 128 Гбайт) и расширение виртуального адресного пространства прикладных процессов до 3,75 Гбайт. В середине 1997 года планируется выпустить полностью 64-разрядную версию операционной системы.

IRIX

Версия UNIX фирмы Silicon Graphics, предназначенная для аппаратной платформы этого производителя (MIPS). Ранние версии системы включали много черт BSD UNIX, однако современную систему IRIX (6.x) скорее можно отнести к ветви System V Release 4. Полностью 64-разрядная операционная система.

Digital UNIX

Версия системы OSF/1 фирмы Digital Equipment Corporation (DEC). В прошлом система называлась DEC OSF/1 и по сути являлась BSD UNIX. В то же время в ней есть много черт ветви System V. Полностью 64-разрядная операционная система, разработанная в первую очередь для аппаратной платформы Alpha, содержит все возможности, присущие современным UNIX, — DCE, CDE, современную файловую систему. Поддерживает большинство сетевых интерфейсов, включая Fast Ethernet и ATM.

SCO UNIX

В 1988 году компании Santa Cruz Operation (SCO), Microsoft и Interactive Systems завершили совместную разработку версии System V Release 3.2 для платформы Intel 386. В том же году SCO получила от AT&T лицензию на торговую марку и операционная система стала называться SCO UNIX System V/386. В 1995 году компания SCO выпустила версию системы под названием SCO OpenServer Release 5 (кодовое название Everest) — UNIX версии SVR3.2 со многими чертами SVR4. Новая версия системы поддерживает более 900 аппаратных платформ, включая мультипроцессорные вычислительные системы, и более 2000 периферийных устройств.

Solaris

Версия UNIX SVR4 фирмы Sun Microsystems. Версия 2.5.1 содержит компоненты ядра, использующие 64-разрядную аппаратную архитектуру. Поддерживает распространенные аппаратные платформы, в том числе SPARC, UltraSPARC, Intel 486, Pentium, Pentium Pro и PowerPC. В 1998 году планируется выпустить полностью 64-разрядную версию операционной системы.

Причины популярности UNIX

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

Перечислим основные черты UNIX, позволяющие понять причины долгожительства этой системы:

1. Код системы написан на языке высокого уровня С, что сделало ее простой для понимания, изменений и переноса на другие платформы. По оценкам одного из создателей UNIX, Дэнниса Ритчи, система на языке С имела на 20–40% больший размер, а производительность ее была на 20% ниже аналогичной системы, написанной на ассемблере. Однако ясность и переносимость, а в результате — и открытость системы сыграли решающую роль в ее популярности. Можно смело сказать, что UNIX является одной из наиболее открытых систем. Несмотря на то, что большинство UNIX поставляется сегодня не в исходных текстах, а в виде бинарных файлов, система остается легко расширяемой и настраиваемой.

2. UNIX — многозадачная многопользовательская система с широким спектром услуг. Один мощный сервер может обслуживать запросы большого количества пользователей. При этом необходимо администрирование только одной системы. Ваша система может выполнять различные функции — работать как вычислительный сервер, обслуживающий сотни пользователей, как сервер базы данных, как сетевой сервер, поддерживающий важнейшие сервисы сети (telnet, ftp, электронную почту, службу имен DNS и т.д.), или даже как сетевой маршрутизатор.

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

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

5. Использование единой, легко обслуживаемой иерархической файловой системы. Файловая система — это не только доступ к данным, хранящимся на диске. Через унифицированный интерфейс файловой системы осуществляется доступ к терминалам, принтерам, магнитным лентам, сети и даже к памяти.

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

Общий взгляд на архитектуру UNIX

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

Рис. 1. Модель системы UNIX

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

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

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

Ядро системы

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

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

В приведенном примере программа открывает файл, считывает из него данные и закрывает этот файл. При этом операции открытия (open), чтения (read) и закрытия (close) файла выполняются ядром по запросу задачи, а функции open(2), read(2) и close(2) являются системными вызовами.

main() {

 int fd;

 char buf[80];

 /* Откроем файл — получим ссылку (файловый дескриптор) fd */

 fd = open("file1", O_RDONLY);

 /* Считаем в буфер buf 80 символов */

 read(fd, buf, sizeof(buf));

 /* Закроем файл */

 close(fd);

}

Структура ядра представлена на рис 2.

Рис. 2. Внутренняя структура ядра UNIX

Ядро состоит из трех основных подсистем:

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

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

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

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

Файловая подсистема обеспечивает унифицированный интерфейс доступа к данным, расположенным на дисковых накопителях, и к периферийным устройствам. Одни и те же функции open(2), read(2), write(2) могут использоваться как при чтении или записи данных на диск, так и при выводе текста на принтер или терминал.

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

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

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

Запущенная на выполнение программа порождает в системе один или более процессов (или задач). Подсистема управления процессами контролирует:

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

□ Распределение системных ресурсов (памяти, вычислительных ресурсов) между процессами

□ Синхронизацию процессов

□ Межпроцессное взаимодействие

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

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

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

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

Подсистема ввода/вывода

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

Глава 1. Работа в операционной системе UNIX

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

С точки зрения пользователя в операционной системе UNIX существуют два типа объектов: файлы и процессы. Все данные хранятся в виде файлов, доступ к периферийным устройствам осуществляется посредством чтения/записи в специальные файлы. Когда вы запускаете программу, ядро загружает соответствующий исполняемый файл, создает образ процесса и передает ему управление. Более того, во время выполнения процесс может считывать или записывать данные в файл. С другой стороны, вся функциональность операционной системы определяется выполнением соответствующих процессов. Работа системы печати или обеспечения удаленного доступа зависит от того, выполняются ли те или иные процессы в системе[2].

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

Мы также постараемся ответить на вопрос, что представляет собой пользователь UNIX как с точки зрения самой системы, так и с точки зрения администрирования; изучим сеанс работы в операционной системе и подробно остановимся на командном интерпретаторе shell — базовой рабочей среде пользователя; познакомимся с наиболее часто используемыми утилитами, неразрывно связанными с UNIX. В заключение постараемся сформулировать основные задачи администрирования этой операционной системы.

Файлы и файловая система

Файлы в UNIX играют ключевую роль, что не всегда справедливо для других операционных систем. Трудно отрицать значение файлов для пользователей, поскольку все их данные хранятся в виде файлов. Однако помимо этого, файлы в UNIX определяют привилегии пользователей, поскольку права пользователя в большинстве случаев контролируются с помощью прав доступа к файлам. Файлы обеспечивают доступ к периферийным устройствам компьютера, включая диски, накопители на магнитной ленте, CD-ROM, принтеры, терминалы, сетевые адаптеры и даже память. Для приложений UNIX доступ в дисковому файлу "неотличим" от доступа, скажем, к принтеру. Наконец, все программы, которые выполняются в системе, включая прикладные задачи пользователей, системные процессы и даже ядро UNIX, являются исполняемыми файлами.

Как и во многих современных операционных системах, в UNIX файлы организованы в виде древовидной структуры (дерева), называемой файловой системой (file system). Каждый файл имеет имя, определяющее его расположение в дереве файловой системы. Корнем этого дерева является корневой каталог (root directory), имеющий имя "/". Имена всех остальных файлов содержат путь — список каталогов (ветвей), которые необходимо пройти, чтобы достичь файла. В UNIX все доступное пользователям файловое пространство объединено в единое дерево каталогов, корнем которого является каталог "/". Таким образом, полное имя любого файла начинается с "/" и не содержит идентификатора устройства (дискового накопителя, CD-ROM или удаленного компьютера в сети), на котором он фактически хранится.

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

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

Типы файлов

В UNIX существуют 6 типов файлов, различающихся по функциональному назначению и действиям операционной системы при выполнении тех или иных операций над файлами:

□ Обычный файл (regular file)

□ Каталог (directory)

□ Специальный файл устройства (special device file)

□ FIFO или именованный канал (named pipe)

□ Связь (link)

□ Сокет

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

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

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

Рис. 1.1. Структура каталога

Специальный файл устройства обеспечивает доступ к физическому устройству. В UNIX различают символьные (character) и блочные (block) файлы устройств. Доступ к устройствам осуществляется путем открытия, чтения и записи в специальный файл устройства.

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

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

FIFO или именованный канал — это файл, используемый для связи между процессами. FIFO впервые появились в System V UNIX, но большинство современных систем поддерживают этот механизм. Более подробно мы рассмотрим этот тип файлов при обсуждении системы межпроцессного взаимодействия в главе 3.

Связь. Как уже говорилось, каталог содержит имена файлов и указатели на их метаданные. В то же время сами метаданные не содержат ни имени файла, ни указателя на это имя. Такая архитектура позволяет одному файлу иметь несколько имен в файловой системе. Имена жестко связаны с метаданными и, соответственно, с данными файла, в то время как сам файл существует независимо от того, как его называют в файловой системе[3]. Такая связь имени файла с его данными называется жесткой связью (hard link). Например, с помощью команды ln(1) мы можем создать еще одно имя (second) файла, на который указывает имя first (рис. 1.2).

Рис. 1.2. Структура файловой системы после выполнения команды ln(1). Жесткая связь имен с данными файла

$ pwd

/home/andrei

$ ln first /home/sergey/second

Жесткие связи абсолютно равноправны. В списках файлов каталогов, которые можно получить с помощью команды ls(1), файлы first и second будут отличаться только именем. Все остальные атрибуты файла будут абсолютно одинаковыми. С точки зрения пользователя — это два разных файла. Изменения, внесенные в любой из этих файлов, затронут и другой, поскольку оба они ссылаются на одни и те же данные файла. Вы можете переместить один из файлов в другой каталог — все равно эти имена будут связаны жесткой связью с данными файла. Легко проверить, что удаление одного из файлов (first или second) не приведет к удалению самого файла, т.е. его метаданных и данных (если это не специальный файл устройства).

По определению жесткие связи указывают на один и тот же индексный дескриптор inode. Поэтому проверить, имеют ли два имени файла жесткую связь, можно, вызвав команду ls(1) с ключом -i:

$ ls -i /home/andrei/first /home/sergey/second

12567 first

12567 second

Информацию о наличии у файла нескольких имен, связанных с ним жесткими связями, можно получить, просмотрев подробный листинг файлов с помощью команды /ls -l:

$ ls -l /home/sergey

...

-rw-r--r-- 2 andrei staff 7245 Jan 17 8:05 second

...

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

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

Рис. 1.3. Символическая связь

Проиллюстрируем эти рассуждения на примере. Команда ln(1) с ключом -s позволяет создать символическую связь:

$ pwd

/home/andrei

$ ln -s first /home/sergey/symfirst

$ cd /home/sergey

$ ls -l

...

lrwxrwxrwx 1 andrei staff 15 Jan 17 8:05 symfirst->../andrei/first

Как видно из вывода команды ls(1), файл symfirst (символическая связь) существенно отличается от файла second (жесткая связь). Во-первых, фактическое содержимое файла symfirst отнюдь не то же, что и у файла first или second, об этом говорит размер файла — 15 байт. На самом деле в этом файле хранится не что иное как имя файла, на которую символическая связь ссылается — ../andrei/first — ровно 15 байт. Во-вторых, файл symfirst не содержит никаких ограничений на доступ (символы 2–10 в первой колонке).

Символическая связь является особым типом файла (об этом свидетельствует символ 'l' в первой позиции вывода ls(1)), и операционная система работает с таким файлом не так, как с обычным. Например, при выводе на экран содержимого файла symfirst появятся данные файла /home/andrei/first.

Сокеты

Сокеты предназначены для взаимодействия между процессами. Интерфейс сокетов часто используется для доступа к сети TCP/IP. В системах, ветви BSD UNIX на базе сокетов реализована система межпроцессного взаимодействия, с помощью которой работают многие системные сервисы, например, система печати. Мы подробнее познакомимся с сокетами в разделе "Межпроцессное взаимодействие в BSD UNIX" главы 3.

Структура файловой системы UNIX

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

Рис. 1.4 Типичная файловая система UNIX

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

Корневой каталог

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

/bin

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

/dev

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

Каталог /dev может содержать несколько подкаталогов, группирующих специальные файлы устройств одного типа. Например, каталог /dev/dsk содержит специальные файлы устройств для доступа к гибким и жестким дискам системы.

/etc

В этом каталоге находятся системные конфигурационные файлы и многие утилиты администрирования. Среди наиболее важных файлов — скрипты инициализации системы. Эти скрипты хранятся в каталогах /etc/rc0.d, /etc/rc1.d, /etc/rc2.d и т.д, соответствующих уровням выполнения системы (run level), и управляются скриптами /etc/rc0, /etc/rc1, /etc/rc2 и т.д. Во многих версиях BSD UNIX указанные каталоги отсутствуют, и загрузка системы управляется скриптами /etc/rc.boot, /etc/rc и /etc/rc.local. В UNIX ветви System V здесь находится подкаталог default, где хранятся параметры по умолчанию многих команд (например, /etc/default/su содержит параметры для команды su(1M)). В UNIX System V большинство исполняемых файлов перемещены в каталог /sbin или /usr/sbin.

/lib

В каталоге /lib находятся библиотечные файлы языка С и других языков программирования. Стандартные названия библиотечных файлов имеют вид libx.a (или libx.so), где x — это один или более символов, определяющих содержимое библиотеки. Например, стандартная библиотека С называется libc.a, библиотека системы X Window System имеет имя libX11.a. Часть библиотечных файлов также находится в каталоге /usr/lib.

/lost+found

Каталог "потерянных" файлов. Ошибки целостности файловой системы, возникающие при неправильном останове UNIX или аппаратных сбоях, могут привести к появлению т.н. "безымянных" файлов — структура и содержимое файла являются правильными, однако для него отсутствует имя в каком-либо из каталогов. Программы проверки и восстановления файловой системы помещают такие файлы в каталог /lost+found под системными числовыми именами. Мы коснемся вопроса имен файлов далее в этой главе и, более подробно, в главе 4.

/mnt

Стандартный каталог для временного связывания (монтирования) физических файловых систем к корневой для получения единого дерева логической файловой системы. Обычно содержимое каталога /mnt пусто, поскольку при монтировании он перекрывается связанной файловой системой. Более подробно процесс монтирования и относящиеся к нему структуры данных ядра мы рассмотрим в главе 4.

/u или /home

Общеупотребительный каталог для размещения домашних каталогов пользователей. Например, имя домашнего каталога пользователя andrei будет, скорее всего, называться /home/andrei или /u/andrei. В более ранних версиях UNIX домашние каталоги пользователей размещались в каталоге /usr.

/usr

В этом каталоге находятся подкаталоги различных сервисных подсистем — системы печати, электронной почты и т.д. (/usr/spool), исполняемые файлы утилит UNIX (/usr/bin), дополнительные программы, используемые на данном компьютере (/usr/local), файлы заголовков (/usr/include), электронные справочники (/usr/man) и т.д.

/var

В UNIX System V этот каталог является заменителем каталога /usr/spool, используемого для хранения временных файлов различных сервисных подсистем — системы печати, электронной почты и т.д.

/tmp

Каталог хранения временных файлов, необходимых для работы различных подсистем UNIX. Обычно этот каталог открыт на запись для всех пользователей системы.

Владельцы файлов

Файлы в UNIX имеют двух владельцев: пользователя (user owner) и группу[4] (group owner). Важной особенностью является то, что владелец- пользователь может не являться членом группы, владеющей файлом. Это дает большую гибкость в организации доступа к файлам. Совместное пользование файлами можно организовать практически для любого состава пользователей, создав соответствующую группу и установив для нее права на требуемые файлы. При этом для того чтобы некий пользователь получил доступ к этим файлам, достаточно включить его в группу- владельца, и наоборот — исключение из группы автоматически изменяет для пользователя права доступа к файлам.

Для определения владельцев файла достаточно посмотреть подробный листинг команды ls -l. Третья и четвертая колонки содержат имена владельца-пользователя и владельца-группы, соответственно:

1          2 3    4       5      6      7     8

-rw-r--r-- 1 andy group   235520 Dec 22 19:13 pride.tar

-rw-rw-r-- 1 andy student   3450 Nov 12 19:13 exams.quest

Владельцем-пользователем вновь созданного файла является пользователь, который создал файл. Порядок назначения владельца-группы зависит от конкретной версии UNIX. Например, в SCO UNIX владельцем-группой является первичная группа пользователя, создавшего файл, а в Digital UNIX владелец-группа наследуется от владельца группы — каталога, в котором создается файл.[5]

Для изменения владельца файла используется команда chown(1). В качестве параметров команда принимает имя владельца-пользователя и список файлов, для которых требуется изменить данный атрибут. Например, следующая команда установит пользователя sergey владельцем файлов client.c и server.c:

$ chown sergey client.c server.c

Изменение владельца-группы производится командой chgrp(1). Как и chown(1), в качестве параметров команда принимает имя владельца-группы и список файлов, для которых требуется изменить данный атрибут. Например, для установки группы staff в качестве владельца всех файлов текущего каталога, необходимо задать следующую команду:

$ chgrp staff *

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


Таблица 1.1. Операции изменения владельцев файла

Операция Команда Имеет право выполнять
в системе BSD 4.x в системе SVR4
Изменение владельца-пользователя chown(1) суперпользователь владелец файла
Изменение владельца-группы chgrp(1) суперпользователь владелец файла только для группы, к которой сам принадлежит (в соответствии с POSIX)

Права доступа к файлу

В операционной системе UNIX существуют три базовых класса доступа к файлу, в каждом из которых установлены соответствующие права доступа:

User access (u) Для владельца-пользователя файла
Group access (g) Для членов группы, являющейся владельцем файла
Other access (о) Для остальных пользователей (кроме суперпользователя)
UNIX поддерживает три типа прав доступа для каждого класса: на чтение (read, обозначается символом на запись (write, обозначается символом w) и на выполнение (execute, обозначается символом x).

С помощью команды ls -l можно получить список прав доступа к файлу:

...

-rw-r--r-- 1 andy group 36482 Dec 22 19:13 report.txt.1

drwxr-xr-- 2 andy group    64 Aug 15 11:03 temp

-rwxr-xr-- 1 andy group  4889 Dec 22 15:13 a.out

-rw-r--r-- 1 andy group  7622 Feb 11 09:13 cont.c

...

Права доступа листинга отображаются в первой колонке (за исключением первого символа, обозначающего тип файла). Наличие права доступа обозначается соответствующим символом, а отсутствие — символом '-'. Рассмотрим, например, права доступа к файлу a.out:

Тип файла Права владельца- пользователя Права владельца- группы Права остальных пользователей
- rwx r-x r--
Обычный файл Чтение, запись, выполнение Чтение и выполнение Только чтение
Права доступа могут быть изменены только владельцем файла или суперпользователем (superuser) — администратором системы. Для этого используется команда chmod(1). Ниже приведен общий формат этой команды.

В качестве аргументов команда принимает указание классов доступа — владелец-пользователь, 'g' — владелец-группа, 'о' — остальные пользователи, 'а' — все классы пользователей), права доступа ('r' — чтение, 'w' — запись и 'x' — выполнение) и операцию, которую необходимо произвести ('+' — добавить, '-' — удалить и '=' — присвоить) для списка файлов file1, file2 и т.д. Например, команда

$ chmod g-wx ownfile

лишит членов группы-владельца файла ownfile права на запись и выполнение этого файла.

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

Приведем еще несколько примеров:

$ chmod a+w text Предоставить право на запись для всех пользователей
$ chmod go=r text Установить право на чтение для всех пользователей, за исключением владельца
$ chmod g+x-w runme Добавить для группы право на выполнение файла runme и снять право на запись
$ chmod u+w,og+r-w text1 text2 Добавить право записи для владельца, право на чтение для группы и остальных пользователей, отключить право на запись для всех пользователей, исключая владельца
Последний пример демонстрирует достаточно сложную установку прав доступа. Вы можете установить сразу все девять прав доступа, используя числовую форму команды chmod(1):

$ chmod 754 *

Число определяется следующим образом: нужно представить права доступа в двоичном виде (0 — отсутствие соответствующего права, 1 — его наличие) и каждую триаду, соответствующую классу доступа, в свою очередь преобразовать в десятичное число.

Владелец Группа Остальные
r w x r x r - -
1 1 1 1 0 1 1 0 0
7 5 4
Таким образом, приведенный пример эквивалентен следующей символьной форме chmod(1):

$ chmod u=rwx, g=rx, o=r *

Значение прав доступа различно для разных типов файлов. Для файлов операции, которые можно производить, следуют из самих названий прав доступа. Например, чтобы просмотреть содержимое файла командой cat(1), пользователь должен иметь право на чтение (r). Редактирование файла, т.е. его изменение, предусматривает наличие права на запись (w). Наконец, для того чтобы запустить некоторую программу на выполнение, вы должны иметь соответствующее право (x). Исполняемый файл может быть как скомпилированной программой, так и скриптом командного интерпретатора shell. В последнем случае вам также понадобится право на чтение, поскольку при выполнении скрипта командный интерпретатор должен иметь возможность считывать команды из файла. Все сказанное, за исключением, пожалуй, права на выполнение, имеющего смысл лишь для обычных файлов и каталогов, справедливо и для других типов файлов: специальных файлов устройств, именованных каналов, и сокетов. Например, чтобы иметь возможность распечатать документ, вы должны иметь право на запись в специальный файл устройства, связанный с принтером.[6] Для каталогов эти права имеют другой смысл, а для символических связей они вообще не используются, поскольку контролируются целевым файлом.

Права доступа для каталогов не столь очевидны. Это в первую очередь связано с тем, что система трактует операции чтения и записи для каталогов отлично от остальных файлов. Право чтения каталога позволяет вам получить имена (и только имена) файлов, находящихся в данном каталоге. Чтобы получить дополнительную информацию о файлах каталога (например, подробный листинг команды ls -l), системе придется "заглянуть" в метаданные файлов, что требует права на выполнения для каталога. Право на выполнения также потребуется для каталога, в который вы захотите перейти (т.е. сделать его текущим) с помощью команды cd(1). Это же право нужно иметь для доступа ко всем каталогам на пути к указанному. Например, если вы установите право на выполнения для всех пользователей в одном из своих подкаталогов, он все равно останется недоступным, пока ваш домашний каталог не будет иметь такого же права.

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

$ pwd

Где мы находимся?

/home/andrei

$ mkdir darkroom

Создадим каталог

$ ls -l

Получим его атрибуты

...

-rwxr--r-- 2 andy group 65 Dec 22 19:13 darkroom

$ chmod a-r+x darkroom

Превратим его в "темный" каталог

$ ls -l

Получим его атрибуты

...

--wx--x--x 2 andy group 65 Dec 22 19:13 darkroom

$ cp file1 darkroom

Поместим в каталог darkroom некоторый файл

$ cd darkroom

Перейдем в этот каталог

$ ls -l darkroom

Попытаемся получить листинг каталога

##permission denied

Увы...

$ cat file1

ok

Тем не менее, заранее зная имя файла (file1), можно работать с ним (например, прочитать, если есть соответствующее право доступа)

Особого внимания требует право на запись для каталога. Создание и удаление файлов в каталоге требуют изменения его содержимого, и, следовательно, права на запись в этот каталог. Самое важное, что при этом не учитываются права доступа для самого файла. То есть для того, чтобы удалить некоторый файл из каталога, не обязательно иметь какие-либо права доступа к этому файлу, важно лишь иметь право на запись для каталога, в котором находится этот файл. Имейте в виду, что право на запись в каталог дает большие полномочия, и предоставляйте это право с осторожностью. Правда, существует способ несколько обезопасить себя в случае, когда необходимо предоставить право на запись другим пользователям, — установка флага Sticky bit на каталог. Но об этом мы поговорим чуть позже.

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


Таблица 1.2. Примеры прав доступа

Команда Смысл действия Минимальные права доступа
для обычного файла для каталога, содержащего файл
cd /u/andrei Перейти в каталог /u/andrei - x
ls /u/andrei/*.с Вывести все файлы с суффиксом .c этого каталога - r
ls -s /u/andrei/*.с Вывести дополнительную информацию об этих файлах (размер) - rx
cat report.txt Вывести на экран содержимое файла report.txt r x
cat >> report.txt Добавить данные в файл report.txt w x
runme.sh Выполнить программу runme x x
runme Выполнить скрипт командного интерпретатора runme.sh rx x
rm runme Удалить файл runme в текущем каталоге - xw
Итак, для выполнения операции над файлом имеют значение класс доступа, к которому вы принадлежите, и права доступа, установленные для этого класса. Поскольку для каждого класса устанавливаются отдельные права доступа, всего определено 9 прав доступа, по 3 на каждый класс.

Операционная система производит проверку прав доступа при создании, открытии (для чтения или записи), запуске на выполнение или удалении файла. При этом выполняются следующие проверки:

1. Если операция запрашивается суперпользователем, доступ разрешается. Никакие дополнительные проверки не производятся. Это позволяет администратору иметь неограниченный доступ ко всей файловой системе.

2. Если операция запрашивается владельцем файла, то:

 а) если требуемое право доступа определено (например, при операции чтения файла установлено право на чтение для владельца- пользователя данного файла), доступ разрешается,

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

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

 а) если требуемое право доступа определено, доступ разрешается,

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

4. Если требуемое право доступа для прочих пользователей (other) установлено, доступ разрешается, в противном случае доступ запрещается.

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

----rw-r-- 2 andy group 65 Dec 22 19:13 file1

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

Дополнительные атрибуты файла

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

Дополнительные атрибуты также устанавливаются утилитой chmod(1), но вместо кодов 'r', 'w' или 'x' используются коды из табл. 1.3. Например, для установки атрибута SGID для файла file1 необходимо выполнить команду $ chmod g+s file1.

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


Таблица 1.3. Дополнительные атрибуты для обычных файлов

Код Название Значение
t Sticky bit Сохранить образ выполняемого файла в памяти после завершения выполнения
s Set UID, SUID Установить UID процесса при выполнении
s Set GID, SGID Установить GID процесса при выполнении
1 Блокирование Установить обязательное блокирование файла
Установка атрибута Sticky bit (действительное название — save text mode) редко используется в современных версиях UNIX для файлов. В ранних версиях этот атрибут применялся с целью уменьшить время загрузки наиболее часто запускаемых программ (например, редактора или командного интерпретатора). После завершения выполнения задачи ее образ (т.е. код и данные) оставались в памяти, поэтому последующие запуски этой программы занимали значительно меньше времени.

Атрибуты (или флаги) SUID и SGID позволяют изменить права пользователя при запуске на выполнение файла, имеющего эти атрибуты. При этом привилегии будут изменены (обычно расширены) лишь на время выполнения и только в отношении этой программы[7].

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

В качестве примера использования этого свойства рассмотрим утилиту passwd(1), позволяющую пользователю изменить свой пароль. Очевидно, что изменение пароля должно привести к изменению содержимого определенных системных файлов (файла пароля /etc/passwd или /etc/shadow, или базы данных пользователей, если используется дополнительная защита системы). Понятно, что предоставление права на запись в эти файлы всем пользователям системы является отнюдь не лучшим решением. Установка SUID для программы passwd(1) (точнее, на файл /usr/bin/passwd — исполняемый файл утилиты passwd(1)) позволяет изящно разрешить это противоречие. Поскольку владельцем файла /usr/bin/passwd является суперпользователь (его имя в системе — root), то кто бы ни запустил утилиту passwd(1) на выполнение, во время работы данной программы он временно получает права суперпользователя, т. е. может производить запись в системные файлы, защищенные от остальных пользователей.

$ ls -lFa /usr/bin/passwd

-r-sr-sr-x 3 root sys 15688 Oct 25 1995 /usr/bin/passwd*

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

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

Однако вернемся к обсуждению дополнительных атрибутов для каталогов (табл. 1.4).


Таблица 1.4. Дополнительные атрибуты для каталогов

Код Название Значение
t Sticky bit Позволяет пользователю удалять только файлы, которыми он владеет или имеет права на запись
s Set GID, SGID Позволяет изменить правило установки владельца- группы создаваемых файлов, аналогично реализованному в BSD UNIX
При обсуждении прав доступа отмечалось, что предоставление права на запись в каталог дает достаточно большие полномочия. Имея такое право, пользователь может удалить из каталога любой файл, даже тот, владельцем которого он не является и в отношении которого не имеет никаких прав. Установка атрибута Sticky bit для каталога позволяет установить дополнительную защиту файлов, находящихся в каталоге. Из такого каталога пользователь может удалить только файлы, которыми он владеет, или на которые он имеет явное право доступа на запись, даже при наличии права на запись в каталог. Примером может служить каталог /tmp, который является открытым на запись для всех пользователей, но в котором может оказаться нежелательной возможность удаления пользователем чужих временных файлов.

Атрибут SGID также имеет иное значение для каталогов. При установке этого атрибута для каталога вновь созданные файлы этого каталога будут наследовать владельца-группу по владельцу-группе каталога. Таким образом для UNIX версии System V удается имитировать поведение систем версии BSD, для которых такое правило наследования действует по умолчанию.

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

$ ls -l

...

drwxrwxrwt 5 sys  sys    367 Dec 19 20:29 /tmp

-r-sr-sr-x 3 root root 15688 Oct 25 1995  /usr/bin/passwd

...


Таблица 1.5. Операции изменения атрибутов файла

Операция Команда/системный вызов Кому разрешено
Изменение прав доступа chmod(1) владелец
Изменение дополнительного атрибута Sticky bit chmod(1) суперпользователь
Изменение дополнительного атрибута SGID chmod(1) владелец, причем его GID также должен совпадать с идентификатором группы файла

Процессы

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

Программы и процессы

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

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

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

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

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

В то же время процессы имеют возможность обмениваться друг с другом данными с помощью предоставляемой UNIX системой межпроцессного взаимодействия. В UNIX существует набор средств взаимодействия между процессами, таких как сигналы (signals), каналы (pipes), разделяемая память (shared memory), семафоры (semaphores), сообщения (messages) и файлы, но в остальном процессы изолированы друг от друга.

Типы процессов

Системные процессы

Системные процессы являются частью ядра и всегда расположены в оперативной памяти. Системные процессы не имеют соответствующих им программ в виде исполняемых файлов и запускаются особым образом при инициализации ядра системы. Выполняемые инструкции и данные этих процессов находятся в ядре системы, таким образом они могут вызывать функции и обращаться к данным, недоступным для остальных процессов. Системными процессами являются: shed (диспетчер свопинга), vhand (диспетчер страничного замещения), bdfflush (диспетчер буферного кэша) и kmadaemon (диспетчер памяти ядра). К системным процессам следует отнести ink, являющийся прародителем всех остальных процессов в UNIX. Хотя init не является частью ядра, и его запуск происходит из исполняемого файла (/etc/init), его работа жизненно важна для функционирования всей системы в целом.

Демоны

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

Прикладные процессы

К прикладным процессам относятся все остальные процессы, выполняющиеся в системе. Как правило, это процессы, порожденные в рамках пользовательского сеанса работы. С такими процессами вы будете сталкиваться чаще всего. Например, запуск команды ls(1) породит соответствующий процесс этого типа. Важнейшим пользовательским процессом является основной командный интерпретатор (login shell), который обеспечивает вашу работу в UNIX. Он запускается сразу же после вашей регистрации в системе, а завершение работы login shell приводит к отключению от системы.

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

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

Атрибуты процесса

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

Идентификатор процесса Process ID (PID)

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

Идентификатор родительского процесса Parent Process ID (PPID)

Идентификатор процесса, породившего данный процесс.

Приоритет процесса (Nice Number)

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

Терминальная линия (TTY)

Терминал или псевдотерминал, ассоциированный с процессом, если такой существует. Процессы-демоны не имеют ассоциированного терминала.

Реальный (RID) и эффективный (EUID) идентификаторы пользователя

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

Реальный (RGID) и эффективный (EGID) идентификаторы группы

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

Команда ps(1) (process status) позволяет вывести список процессов, выполняющихся в системе, и их атрибуты:

$ ps -ef | head -20

UID  PID  PPID С STIME  TTY   TIME CMD

root 0    0    0 Dec 17 ?     0:00 sched

root 1    0    0 Dec 17 ?     0:01 /etc/init -

root 2    0    0 Dec 17 ?     0:00 pageout

root 3    0    0 Dec 17 ?     7:00 fsflush

root 164  1    0 Dec 17 ?     0:01 /usr/lib/sendmail -bd -q1h

fed  627  311  0 Dec 17 pts/3 0:27 emiclock

fed  314  304  0 Dec 17 pts/4 0:00 /usr/local/bin/bash

fed  3521 512  0              0:01 <defunct>

Более подробное описание полей вывода команды ps(1) приведено далее в разделе "Основные утилиты UNIX".

Жизненный путь процесса

Процесс в UNIX создается системным вызовом fork(2). Процесс, сделавший вызов fork(2) называется родительским, а вновь созданный процесс — дочерним. Новый процесс является точной копией породившего его процесса. Как это ни удивительно, но новый процесс имеет те же инструкции и данные, что и его родитель. Более того, выполнение родительского и дочернего процесса начнется с одной и той же инструкции, следующей за вызовом fork(2). Единственно, чем они различаются — это идентификатором процесса PID. Каждый процесс имеет одного родителя, но может иметь несколько дочерних процессов.

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

В UNIX запуск на выполнение новой программы часто связан с порождением нового процесса, таким образом сначала процесс выполняет вызов fork(2), порождая дочерний процесс, который затем выполняет exec(2), полностью замещаясь новой программой.

Рассмотрим эту схему на примере.

Допустим, пользователь, работая в командном режиме (в командном интерпретаторе shell) запускает команду ls(1). Текущий процесс (shell) делает вызов fork(2), порождая вторую копию shell. В свою очередь, порожденный shell вызывает exec(2), указывая в качестве параметра имя исполняемого файла, образ которого необходимо загрузить в память вместо кода shell. Код ls(1) замещает код порожденного shell, и утилита ls(1) начинает выполняться. По завершении работы ls(1) созданный процесс "умирает". Пользователь вновь возвращается в командный режим. Описанный процесс представлен на рис. 1.5. Мы также проиллюстрируем работу командного интерпретатора в примере, приведенном в главе 2.

Рис. 1.5. Создание процесса и запуск программы

Если сделать "отпечаток" выполняемых процессов, например командой ps(1), между указанными стадиями, результат был бы следующим:

Пользователь работает в командном режиме:

UID   PID PPID С  STIME    TTY   TIME CMD

user1 745 1    10 10:11:34 ttyp4 0:01 sh

Пользователь запустил команду ls(1), и shell произвел вызов fork(2):

UID   PID PPID С  STIME    TTY   TIME CMD

user1 745 1    10 10:11:34 ttyp4 0:01 sh

user1 802 745  14 11:00:00 ttyp4 0:00 sh

Порожденный shell произвел вызов exec(2):

UID   PID PPID С  STIME    TTY   TIME CMD

user1 745 1    10 10:11:34 ttyp4 0:01 sh

user1 802 745  12 11:00:00 ttyp4 0:00 ls

Процесс ls(1) завершил работу:

UID   PID PPID С  STIME    TTY   TIME CMD

user1 745 1    10 10:11:34 ttyp4 0:01 sh

Описанная процедура запуска новой программы называется fork-and-exec.

Однако бывают ситуации, когда достаточно одного вызова fork(2) без последующего exec(2). В этом случае исполняемый код родительского процесса должен содержать логическое ветвление для родительского и дочернего процессов[9].

Все процессы в UNIX создаются посредством вызова fork(2). Запуск на выполнение новых задач осуществляется либо по схеме fork-and-exec, либо с помощью exec(2). "Прародителем" всех процессов является процесс init(1М), называемый также распределителем процессов. Если построить граф "родственных отношений" между процессами, то получится дерево, корнем которого является init(1M). Показанные на рис. 1.6 процессы sched и vhand являются системными и формально не входят в иерархию (они будут рассматриваться в следующих главах).

Рис. 1.6. Типичное "дерево" процессов в UNIX

Сигналы

Сигналы являются способом передачи от одного процесса другому или от ядра операционной системы какому-либо процессу уведомления о возникновении определенного события. Сигналы можно рассматривать как простейшую форму межпроцессного взаимодействия. В то же время сигналы больше напоминают программные прерывания, — средство, с помощью которого нормальное выполнение процесса может быть прервано. Например, если процесс производит деление на 0, ядро посылает ему сигнал SIGFPE, а при нажатии клавиш прерывания, обычно <Del> или <Ctrl>+<C>, текущему процессу посылается сигнал SIGINT.

Для отправления сигнала служит команда kill(1):

kill sig_no pid

где sig_nо — номер или символическое название сигнала, a pid — идентификатор процесса, которому посылается сигнал. Администратор системы может посылать сигналы любым процессам, обычный же пользователь может посылать сигналы только процессам, владельцем которых он является (реальный и эффективный идентификаторы процесса должны совпадать с идентификатором пользователя[10]). Например, чтобы послать процессу, который вы только что запустили в фоновом режиме, сигнал завершения выполнения SIGTERM, можно воспользоваться командой:

$ long_program &

Запустим программу в фоновом режиме

$ kill $!

По умолчанию команда kill(1) посылает сигнал SIGTERM; переменная $! содержит PID последнего процесса, запущенного в фоновом режиме

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

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

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

3. Наконец, процесс может перехватить сигнал и самостоятельно обработать его. Например, перехват сигнала SIGINT позволит процессу удалить созданные им временные файлы, короче, достойно подготовиться к "смерти". Следует иметь в виду, что сигналы SIGKILL и SIGSTOP нельзя ни перехватить, ни игнорировать.

По умолчанию команда kill(1) посылает сигнал с номером 15 — SIGTERM[11], действие по умолчанию для которого — завершение выполнения процесса, получившего сигнал.

Иногда процесс продолжает существовать и после отправления сигнала SIGTERM. В этом случае можно применить более жесткое средство — послать процессу сигнал SIGKILL с номером (9), — поскольку этот сигнал нельзя ни перехватить, ни игнорировать:

$ kill -9 pid

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

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

□ Процессы, ожидающие недоступные ресурсы NFS (Network File System), например, записывающие данные в файл файловой системы удаленного компьютера, отключившегося от сети. Эту ситуацию можно преодолеть, послав процессу сигнал SIGINT или SIGQUIT.

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

Сигналы могут не только использоваться для завершения выполнения но и иметь специфическое для приложения (обычно для системных демонов) значение (естественно, это не относится к сигналам SIGKILL и SIGSTOP). Например, отправление сигнала SIGHUP серверу имен DNS named(1M) вызовет считывание базы данных с диска. Для других приложений могут быть определены другие сигналы и соответствующие им значения.

Более подробно сигналы мы рассмотрим в главах 2 и 3.

Устройства

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

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

Существует два типа специальных файлов устройств:

□ Файлы блочных устройств

□ Файлы символьных устройств

Файлы блочных устройств

Файлы блочных устройств служат интерфейсом к устройствам, обмен данными с которыми происходит большими фрагментами, называемыми блоками. При этом ядро операционной системы обеспечивает необходимую буферизацию. Примером физических устройств, соответствующих этому типу файлов, являются жесткие диски. Приведем фрагмент подробного списка файлов каталога /dev системы Digital UNIX, отражающий файлы для доступа к первому и второму разделам первого диска SCSI:

brw------- 1 root system 8, 1 Apr 18 11:03 /dev/rz0a

brw------- 1 root system 8, 1 Apr 18 13:15 /dev/rz0b

Файлы символьных устройств

Файлы символьных устройств используются для доступа к устройствам, драйверы которых обеспечивают собственную буферизацию и побайтную передачу данных. В качестве примера устройств с символьным интерфейсом можно привести терминалы, принтеры и накопители на магнитной ленте. Заметим, что одно и то же физическое устройство может иметь как блочный, так и символьный интерфейсы. Для блочных устройств такой интерфейс также называют интерфейсом доступа низкого уровня (raw interface). Так, для побайтного доступа к разделам диска, приведенным в предыдущем примере, используются соответствующие файлы:

crw------- 1 root system   8, 1 Apr 18 11:04 /dev/rrz0a

crw------- 1 root system   8, 1 Apr 18 13:15 /dev/rrz0b

crw-r----- 1 root system   13,1 Apr 18 18:08 /dev/kmem

crw-rw-rw- 1 root system   7, 0 Apr 18 15:30 /dev/ptyp0

crw-rw-rw- 1 root system   7, 1 Apr 18 15:20 /dev/ptyp1

crw-rw-rw- 1 bill terminal 3, 2 Apr 18 16:10 /dev/tty02

crw-rw-rw- 1 bin  terminal 3, 3 Apr 18 16:10 /dev/tty03

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

В поле размера файла (пятая колонка вывода команды ls(1)) у специальных файлов устройств выводятся два числа. Это так называемые старшее (major) и младшее (minor) числа. Часто драйвер обслуживает более одного устройства. При этом старшее число указывает ядру на конкретный драйвер (например, драйвер псевдо-терминалов), а младшее передается драйверу и указывает на конкретное устройство (например, конкретный псевдотерминал).

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

Рис. 1.7. Взаимодействие с устройством

Мнемоника названий специальных файлов устройств в файловой системе UNIX

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

В качестве примера рассмотрим специальный файл устройства для доступа к разделу диска в операционной системе Solaris:

/dev/dsk/c0t4d0s2

Данный файл предоставляет блочный интерфейс, а соответствующий ему символьный (или необработанный) файл имеет имя:

/dev/rdsk/c0t4d0s2

Файлы доступа к дисковым устройствам располагаются в специальных подкаталогах — /dev/dsk (для блочных устройств) и /dev/rdsk (для символьных устройств). Такая структура хранения специальных файлов характерна для систем UNIX версии System V.

Имя файла, характерное для систем версии SVR4, можно представить в общем виде:

cktldmsn

где k — номер контроллера, l — номер устройства (для устройств SCSI это идентификатор устройства ID), m — номер раздела, а n — логический номер устройства (LUN) SCSI.

Таким образом файл устройства /dev/rdsk/c0t4d0s2 обеспечивает доступ к первому разделу (нумерация разделов начинается с 0) диска с ID=4, LUN=2 первого контроллера.

Такой формат имен файлов в версии SVR4 применяется для всех дисковых устройств и накопителей на магнитной ленте. Иногда для этих стандартных имен в файловой системе имеются символические связи с более простыми названиями. Например, в Solaris имя /dev/sd0a может использоваться вместо /dev/dsk/c0t3d0s, также обеспечивая доступ к устройству:

lrwxrwxrwx 1 root root 12 Oct 31 17:48 /dev/sd0a ->dsk/c0t3d0s

В SCO UNIX имеются специальные файлы с более простыми именами /dev/root, /dev/usr и т.п, которые предоставляют доступ к разделам диска с такими же именами (root, usr).

Более простая мнемоника обнаруживается в именах специальных файлов других устройств. Так, например, параллельный порт в большинстве систем имеет имя /dev/lpn, где n — номер порта (0, 1 и т.д.). Терминальные линии, подключенные к последовательным портам компьютера обозначаются как /dev/ttynn, где nn является идентификатором линии. В табл. 1.6 приведены примеры других специальных файлов устройств.


Таблица 1.6. Имена некоторых специальных файлов устройств

Общий вид имени Пример Описание устройства, доступ к которому обеспечивается через файл
/dev/rmtn /dev/rmt0 Накопитель на магнитной ленте
/dev/nrmtn /dev/nrmt0 Накопитель на магнитной ленте в режиме без перемотки назад по окончании работы
/dev/rstn /dev/rst1 SCSI-накопитель на магнитной ленте
/dev/cdn /dev/cd0 CD-ROM
/dev/cdrom
/dev/ttypn /dev/ttyp12 Псевдотерминал (подчиненный)
/dev/ptypn /dev/ptyp5 Псевдотерминал (мастер)
/dev/console Системная консоль
/dev/tty Синоним терминальной линии управляющего терминала для данного процесса
/dev/mem Физическая оперативная память
/dev/kmem Виртуальная память ядра
/dev/null Нулевое устройство — весь вывод на него уничтожается, а при попытке ввода с этого устройства возвращается 0 байтов
/dev/zero Нулевое устройство — весь вывод на него уничтожается, а ввод приводит к получению последовательности 0

Пользователи системы

Прежде чем вы сможете начать работу в UNIX, вы должны стать пользователем системы, т.е. получить имя, пароль и ряд других атрибутов.

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

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

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

Каждый пользователь системы имеет уникальное имя (или регистрационное имя — login name). Однако система различает пользователей по ассоциированному с именем идентификатору пользователя или UID (User Identifier). Понятно, что идентификаторы пользователя также должны быть уникальными. Пользователь является членом одной или нескольких групп — списков пользователей, имеющих сходные задачи (например пользователей, работающих над одним проектом). Принадлежность к группе определяет дополнительные права, которыми обладают все пользователи группы. Каждая группа имеет уникальное имя (уникальное среди имен групп, имя группы и пользователя могут совпадать), но как и для пользователя, внутренним представлением группы является ее идентификатор GID (Group Identifier). В конечном счете UID и GID определяют, какими правами обладает пользователь в системе.

Вся информация о пользователях хранится в файле /etc/passwd. Это обычный текстовый файл, право на чтение которого имеют все пользователи системы, а право на запись имеет только администратор (суперпользователь). В этом файле хранятся пароли пользователей, правда в зашифрованном виде. Подобная открытость — недостаток с точки зрения безопасности, поэтому во многих системах зашифрованные пароли хранятся в отдельном закрытом для чтения и записи файле /etc/shadow.

Аналогично, информация о группах хранится в файле /etc/group и содержит списки пользователей, принадлежащих той или иной группе.

Атрибуты пользователя

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

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

root:x:0:0000-Admin(0000):/:bin/bash

daemon:x:1:1:0000-Admin(0000):/:

bin:x:2:2:0000-Admin(0000):/usr/bin:

sys:x:3:3:0000-Admin(0000):/:

adm:x:4:4:0000-Admin(0000):/var/adm

lp:x:71:8:0000-lp(0000):/usr/spool/lp:

uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:

nobody:x:60001:60001:uid no body:/:

andy:x:206:101:Andrei Robachevsky:/home/andy:/bin/bash

Каждая строка файла является записью конкретного пользователя и имеет следующий формат:

name:passwd-encod:UID:GID:comments:home-dir:shell

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

Рассмотрим подробнее каждый из атрибутов:

name Регистрационное имя пользователя. Это имя пользователь вводит в ответ на приглашение системы login. Для небольших систем имя пользователя достаточно произвольно. В больших системах, в которых зарегистрированы сотни пользователей, требования уникальности заставляют применять определенные правила выбора имен.
passwd-encod Пароль пользователя в закодированном виде. Алгоритмы кодирования известны, но они не позволяют декодировать пароль. При входе в систему пароль, который вы набираете, кодируется, и результат сравнивается с полем passwd-encod. В случае совпадения пользователю разрешается войти в систему. Даже в закодированном виде доступность пароля представляет некоторую угрозу для безопасности системы. Поэтому часто пароль хранят в отдельном файле, а в поле passwd-encod ставится символ 'х' (в некоторых системах '!'). Пользователь, в данном поле которого стоит символ '*', никогда не сможет попасть в систему. Дело в том, что алгоритм кодирования не позволяет символу '*' появиться в закодированной строке. Таким образом, совпадение введенного и затем закодированного пароля и '*' невозможно. Обычно такой пароль имеют псевдопользователи.
UID Идентификатор пользователя является внутренним представлением пользователя в системе. Этот идентификатор наследуется задачами, которые запускает пользователь, и файлами, которые он создает. По этому идентификатору система проверяет пользовательские права (например, при запуске программы или чтении файла). Суперпользователь имеет UID=0, что дает ему неограниченные права в системе.
GID Определяет идентификатор первичной группы пользователя. Этот идентификатор соответствует идентификатору в файле /etc/group, который содержит имя группы и полный список пользователей, являющихся ее членами. Принадлежность пользователя к группе определяет дополнительные права в системе. Группа определяет общие для всех членов права доступа и тем самым обеспечивает возможность совместной работы (например, совместного использования файлов).
comments Обычно, это полное "реальное" имя пользователя. Это поле может содержать дополнительную информацию, например, телефон или адрес электронной почты. Некоторые программы (например, finger(1) и почтовые системы) используют это поле.
home-dir Домашний каталог пользователя. При входе в систему пользователь оказывается в этом каталоге. Как правило, пользователь имеет ограниченные права в других частях файловой системы, но домашний каталог и его подкаталоги определяют область файловой системы, где он является полноправным хозяином.
shell Имя программы, которую UNIX использует в качестве командного интерпретатора. При входе пользователя в систему UNIX автоматически запустит указанную программу. Обычно это один из стандартных командных интерпретаторов /bin/sh (Bourne shell), /bin/csh (С shell) или /bin/ksh (Korn shell), позволяющих пользователю вводить команды и запускать задачи. В принципе, в этом поле может быть указана любая программа, например, командный интерпретатор с ограниченными функциями (restricted shell), клиент системы управления базой данных или даже редактор. Важно то, что, завершив выполнение этой задачи, пользователь автоматически выйдет из системы. Некоторые системы имеют файл /etc/shells, содержащий список программ, которые могут быть использованы в качестве командного интерпретатора.

Пароли

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

Назначить или изменить пароль можно командой passwd(1). Обычный пользователь может изменить свой пароль, администратор может назначить пароль любому пользователю.

Перед запуском программы passwd(1) стоит держать в голове общее правило выбора пароля: пароль должен хорошо запоминаться и быть трудным для подбора.

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

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

Многие системы требуют, чтобы пароль удовлетворял следующим требованиям:

□ длина пароля не должна быть меньше шести символов;

□ пароль должен включать по крайней мере 2 алфавитных символа и одну цифру или специальный символ;

□ пароль должен содержать хотя бы 3 символа, не встречавшихся в вашем предыдущем пароле.

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

1. В системе не должно существовать незащищенных пользовательских входов. Это относится как к пользовательским входам без пароля, так и ко входам пользователей, покинувших систему. Если пользователь длительное время не работает в системе, удалите его запись или хотя бы защитите его вход символом '*' в поле пароля.

2. Если ваша система допускает, установите минимальную длину пароля. В зависимости от требований безопасности в системе это число может варьироваться от 8 до 12.

3. Всегда меняйте пароль в следующих случаях:

 • если кто-либо узнал ваш пароль.

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

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

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

4. Пароль администратора должен периодически меняться, независимо от обстоятельств.

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

Не преуменьшайте роль паролей в системе.

Стандартные пользователи и группы

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

Имя Пользователь
root Суперпользователь, администратор системы, UID=0. Пользователь с этим именем имеет неограниченные полномочия в системе. Для него не проверяются права доступа, и таким образом он имеет все "рычаги" для управления системой. Для выполнения большинства функций администрирования требуется вход именно с этим именем. Следует отметить, что root — это только имя. На самом деле значение имеет UID. Любой пользователь с UID=0 имеет полномочия суперпользователя
adm Псевдопользователь, владеющий файлами системы ведения журналов
bin Обычно это владелец всех исполняемых файлов, являющихся командами UNIX
cron Псевдопользователь, владеющий соответствующими файлами, от имени которого выполняются процессы подсистемы запуска программ по расписанию
lp или lpd Псевдопользователь, от имени которого выполняются процессы системы печати, владеющий соответствующими файлами
news Псевдопользователь, от имени которого выполняются процессы системы телеконференций
nobody Псевдопользователь, используемый в работе NFS
uucp Псевдопользователь подсистемы UNIX-to-UNIX copy (uucp), позволяющей передавать почтовые сообщения и файлы между UNIX-хостами
Новая система также содержит ряд предустановленных групп. Поскольку группы, как правило, менее значимы, приведем лишь две категории:

Имя Группа
root или wheel Административная группа, GID=0
user или users или staff Группа, в которую по умолчанию включаются все обычные пользователи UNIX

Пользовательская среда UNIX

Сегодня характер работы в UNIX существенно отличается от того, каким он был, скажем, пятнадцать лет назад. Графический многооконный интерфейс, миллионы цветов, системы меню, техника drag-and-drop, — все это, казалось бы, стирает различия в работе с UNIX и, например, с Windows NT. Но взгляните внимательнее на экран монитора — и вы обязательно найдете хотя бы одно окно простого алфавитно-цифрового терминала.

Это — базовая пользовательская среда. Интерфейс командной строки может показаться безнадежно устаревшим, но в случае с UNIX это — самый непосредственный способ выполнения множества небольших задач администрирования. И программа, с которой вы рано или поздно столкнетесь, — командный интерпретатор shell. Поэтому здесь мы рассмотрим базовый пример работы в UNIX — использование командной строки интерпретатора shell.

Командный интерпретатор shell

Все современные системы UNIX поставляются по крайней мере с тремя командными интерпретаторами: Bourne shell (/bin/sh), С shell (/bin/csh) и Korn shell (/bin/ksh). Существует еще несколько интерпретаторов, например Bourne-Again shell (bash), со сходными функциями.

Командный интерпретатор занимает важное место в операционной системе UNIX, прежде всего, благодаря следующим обстоятельствам:

1. Первая программа, с которой по существу начинается работа пользователя, — shell. В UNIX реализуется следующий сценарий работы в системе (рис. 1.8):

 • При включении терминала активизируется процесс getty(1M), который является сервером терминального доступа и запускает программу login(1)[12], которая, в свою очередь, запрашивает у пользователя имя и пароль.

 • Если пользователь зарегистрирован в системе и ввел правильный пароль, login(1) запускает программу, указанную в последнем поле записи пользователя в файле /etc/passwd. В принципе это может быть любая программа, но в нашем случае — это командный интерпретатор shell.

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

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

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

Рис. 1.8. Процессы, обеспечивающие вход пользователя в систему

2. Командный интерпретатор является удобным средством программирования. Синтаксис языка различных командных интерпретаторов несколько отличается, в качестве базового мы рассмотрим командный интерпретатор Bourne. С помощью shell вы можете создавать сложные программы, конструируя их, как из кирпичиков, из существующих утилит UNIX. Программы на языке shell часто называют скриптами или сценариями (script). Интерпретатор считывает строки из файла- скрипта и выполняет их, как если бы они были введены пользователем в командной строке.

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

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

Командный интерпретатор Скрипт инициализации
Bourne shell (sh) .profile
С shell (csh) .login и .cshrc
Korn shell (ksh) .profile и .kshrc
Bourne-Again shell (bash) .profile и .bashrc
Скрипты .profile и .login выполняются при первом входе в систему.

Скрипты .cshrc, .kshrc и .bashrc выполняются при каждом запуске интерпретатора.

4. Наконец, основная инициализация операционной системы происходит в результате выполнения скриптов shell. Если вам понадобится модифицировать процесс инициализации (например, добавить новый системный сервис), то придется заглянуть в эти скрипты.

Синтаксис языка Bourne shell

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

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

Общий синтаксис скрипта

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

Безусловно, как и в случае любого другого языка программирования, применение комментариев существенно облегчает последующее использование и модификацию написанной программы. В Bourne shell комментарии начинаются с символа '#':

# Этот скрипт выполняет поиск "мусора" (забытых временных

# файлов, файлов core и т.п.) в каталогах пользователей

Комментарии могут занимать не всю строку, а следовать после команды:

find /home -name core -print # Выполним поиск файлов core

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

#!/bin/sh

В данном случае последующий текст скрипта будет интерпретироваться Bourne shell. Заметим, что при запуске скрипта из командной строки (для этого он должен обладать правом на выполнение — x), будет запущен новый командный интерпретатор, ввод команд для которого будет выполняться из файла скрипта.

Переменные

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

var=value

где var — имя переменной, a value — ее значение.

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

$ echo $name

Так же можно присвоить другой переменной (name1) значение переменной name:

$ name1=$name

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

var=`command`

Так, например, где var — имя переменной, a command — название команды, команда pwd(1) выводит строку со значением текущего каталога:

$ pwd

/usr/home/andrei/test

Можно присвоить переменной cdir значение текущего каталога, которое сохранится в ней:

$ cdir=`pwd`

$ echo $cdir

/usr/home/andrei/test

$ cd /usr/bin

$ pwd

/usr/bin

$ cd $cdir

$ pwd

/usr/home/andrei/test

При использовании переменной, например var, командный интерпретатор подставляет вместо $var ее значение. Более сложные синтаксические конструкции получения значения переменной приведены в табл. 1.7.


Таблица 1.7. Способы получения значения переменной

$var Значение var; ничего, если переменная var не определена
${var} То же, но отделяет имя переменной var от последующих символов
${var:-string} Значение var, если определено; в противном случае — string. Значение var при этом не изменяется
${var:=string} То же, но если переменная var не определена, ей присваивается значение строки string
${var:?string} Если переменная var не определена, выводится строка string и интерпретатор прекращает работу. Если строка string пуста, то выводится сообщение var: parameter not set
${var:+string} Строка string, если переменная var определена, в противном случае — ничего
Приведем несколько примеров, используя команду echo:

$ var=user1

$ var1=user2

$ echo $var1

user2

$ echo ${var}l

user11

$ echo ${var1:+"do you want to redefine var?"}

do you want to redefine var?

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

Имя Описание Возможное значение
НОМЕ Каталог верхнего уровня пользователя /usr/'logname'[13]
PATH Поисковый путь /bin:/etc:/usr/bin:.
MAIL Имя почтового ящика /usr/spool/mail/'logname'
TERM Имя терминала ansi
PS1 Первичное приглашение shell #
PS2 Вторичное приглашение shell >
Начальное окружение вашего сеанса устанавливается программой login(1) исходя из записей в файле паролей, и имеет следующий вид:

Переменная окружения Поле файла паролей
HOME=домашний_каталог 6
LOGNAME=зарегистрированное_имя 1
PATH=/usr/bin: -
SHELL=интерпретатор_сеанса 7
MAIL=/var/mail/зарегистрированное_имя 1
TZ=временная_зона определено системой
Переменная НОМЕ в основном используется в команде cd, которая служит для перехода в каталог:

$ pwd

/u/usr

$ cd some/new/directory

$ pwd

/u/usr/some/new/directorу

В результате текущим каталогом (команда pwd(1) выводит на терминал полное имя текущего каталога) становится /u/usr/some/new/directory. Вызов команды cd без параметра эквивалентен следующему вызову:

$ cd $HOME

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

Переменная PATH служит для поиска командным интерпретатором запускаемых на выполнение программ, если их имя не содержит пути. Например, при запуске программы:

$ run

интерпретатор попытается найти файл run в каталогах пути поиска. В то же время при запуске программы run с указанием пути, переменная PATH использоваться не будет:

$ ./run

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

Каталоги поиска в переменной PATH разделены символом ':'. Заметим, что текущий каталог поиска должен быть задан явно ('.'), shell не производит поиск в текущем каталоге по умолчанию.

Поиск запускаемых программ в текущем каталоге таит потенциальную опасность, поэтому для суперпользователя переменная PATH обычно инициализируется без '.'. Рассмотрим следующую ситуацию. Злоумышленник создает программу, наносящую вред системе (удаляющую файл паролей), помещает ее в каталог общего пользования, например в /tmp, открытый на запись всем пользователям системы, с именем ls. Известно, что в UNIX существует стандартная команда ls(1) (она обычно находится в каталоге /bin), выводящая на экран список файлов каталога. Допустим теперь, что администратор системы делает текущим каталог /tmp и хочет вывести список файлов данного каталога. Если текущий каталог ('.') расположен в пути поиска (переменной PATH) раньше каталога /bin, то выполнится программа, "подложенная" злоумышленником. Даже если текущий каталог указан последним в пути поиска, все равно существует вероятность, что вы захотите запустить команду, которая расположена в каталоге, не попавшем в переменную PATH, на самом деле вы можете запустить троянского коня.

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

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

Переменные PS1 и PS2 устанавливают первичное и вторичное приглашения командного интерпретатора. Первичное приглашение указывает на готовность интерпретатора к вводу команд. Значение этой переменной устанавливается при исполнении скрипта (.profile) при входе пользователя в систему, и имеет вид "$" для обычных пользователей и "#" для суперпользователя. Однако вид приглашения легко изменить, соответствующим образом задав значение переменной PS1. Например, если вы хотите, чтобы в приглашении присутствовало имя хоста, на котором вы работаете, задайте значение PS1 следующим образом:

PS1=`uname -n">"

В этом случае, если имя вашей системы, например, telemak, при входе в систему командный интерпретатор выведет следующее приглашение:

telemak>

Вторичное приглашение появляется, если вы нажали клавишу <Enter>, синтаксически не закончив ввод команды. Например:

$ while :      нажатие клавиши <Enter>

> do           нажатие клавиши <Enter>

> echo Привет! нажатие клавиши <Enter>

> done         нажатие клавиши <Enter>

После этого вы увидите слово "Привет!", выводимое на экран в бесконечном цикле. (Если вы все-таки воспроизвели этот пример, нажмите клавиши <Ctrl>+<C> или <Del>.)

Переменные, которые определены, являются внутренними переменными командного интерпретатора и не попадают в его окружение автоматически. Таким образом, они не могут быть использованы другими программами, запускаемыми из shell (окружение наследуется порожденными процессами). Для того чтобы поместить необходимые переменные в окружение shell и тем самым сделать их доступными для других приложений, эти переменные должны быть отмечены как экспортируемые. В этом случае при вызове какой-либо программы они автоматически попадут в ее окружение. Например, программа работы с электронной почтой получает имя файла — почтового ящика через переменную MAIL, программы, работающие с терминалом, например полноэкранный редактор, обращаются к базе данных терминалов, используя переменную TERM. Разработанная вами программа также может получать часть информации через переменные окружения. Для этого она должна использовать соответствующие функции (getenv(3C) и putenv(3C)), которые мы подробнее рассмотрим в следующей главе.

Встроенные переменные

Помимо переменных, определяемых явно, shell имеет ряд внутренних переменных, значения которых устанавливаются самим интерпретатором. Поскольку это внутренние переменные, имя переменной вне контекста получения ее значения не имеет смысла (т.е. не существует переменной #, имеет смысл лишь ее значение $#). Эти переменные приведены в табл. 1.8.


Таблица 1.8. Внутренние переменные shell

$1, $2, ... Позиционные параметры скрипта
$# Число позиционных параметров скрипта
$? Код возврата последнего выполненного процесса
$5 PID текущего shell
$! PID последнего процесса, запушенного в фоновом режиме
$* Все параметры, переданные скрипту. Передаются как единое слово, будучи заключенным в кавычки: "$*" = "$1 $2 $3 ..."
$@ Все параметры, переданные скрипту. Передаются как отдельные слова, будучи заключенным в кавычки: "$*" = "$1" "$2" "$3 ..."
Эти переменные редко используются при работе в командной строке, основная область их применения — скрипты. Рассмотрим несколько примеров.

Текст скрипта test1.sh:

#!/bin/sh

echo скрипт $0

echo $1 $2 $3

shift

echo $1 $2 $3

Запуск скрипта

$ ./test1.sh a1 a2 a3 a4 a5

скрипт ./test.sh

a1 a2 a3

a2 a3 a4

Переменные $1, $2, ... $9 содержат значения позиционных параметров — аргументов запущенного скрипта. В $1 находится первый аргумент (a1), в $2 — a2 и т.д. до девятого аргумента. При необходимости передать большее число аргументов, требуется использовать команду shift n, производящую сдвиг значений аргументов на n позиций (по умолчанию — на одну позицию). Приведенный скрипт иллюстрирует этот прием. В переменной $0 находится имя запущенного скрипта. Здесь наблюдается полная аналогия с массивом параметров argv[], передаваемом программе на языке С.

Значение $# равно числу позиционных параметров. Его удобно использовать при проверке соответствия числа введенных пользователем параметров требуемому.

Текст скрипта test2.sh:

#!/bin/sh

if [ $# -lt 2 ]

then

 echo usage: $0 arg1 arg2

 exit 1

fi

Запуск скрипта

$ test2.sh

usage: test2.sh arg1 arg2

$ test2.sh h1 h2

$

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

Код возврата последней выполненной задачи ($?) удобно использовать в условных выражениях. По правилам успешным завершением задачи считается код возврата, равный 0, ненулевой код возврата свидетельствует об ошибке. Код возврата скриптов генерируется с помощью команды exit n, где n — код возврата (см. предыдущий пример). В приведенном ниже примере определяется, зарегистрирован ли в системе пользователь с именем "sergey". Для этого программой grep(1) производится поиск слова sergey в файле паролей. В случае удачи grep(1) возвращает 0. Если слово не найдено, то grep(1) возвращает ненулевое значение, в данном случае это свидетельствует, что пользователь с именем sergey в системе не зарегистрирован.

Текст скрипта test3.sh:

#!/bin/sh

grep sergey /etc/passwd

if [ $? -ne 0 ]

then

 echo пользователь sergey в системе не зарегистрирован

fi

Каждый активный процесс в UNIX имеет уникальный идентификатор процесса, PID. Запуская скрипт, вы порождаете в системе процесс с уникальным PID. Значение PID сохраняется в переменной $$. Эту переменную удобно использовать в названиях временных файлов, поскольку их имена будут уникальными, например:

Текст скрипта test4.sh:

#!/bin/sh

tmpfile=/usr/tmp/tmp.$$

...

rm $tempfile

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

Каждая запущенная из командного интерпретатора программа получает три открытых потока ввода/вывода:

□ стандартный ввод

□ стандартный вывод

□ стандартный вывод ошибок

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

В табл. 1.9 приведен синтаксис перенаправления ввода/вывода, а на рис. 1.9 схематически показаны примеры перенаправления потоков.


Таблица 1.9. Перенаправление потоков ввода/вывода

>file Перенаправление стандартного потока вывода в файл file
>>file Добавление в файл file данных из стандартного потока вывода
<file Получение стандартного потока ввода из файла file
p1 | p2 Передача стандартного потока вывода программы p1 в поток ввода p2
n>file Переключение потока вывода из файла с дескриптором n в файл file
n>>file To же, но записи добавляются в файл file
n>&m Слияние потоков с дескрипторами n и m
<<str "Ввод здесь": используется стандартный поток ввода до подстроки str. При этом выполняются подстановки метасимволов командного интерпретатора
<<\str To же, но подстановки не выполняются
Рис. 1.9. Пример перенаправления стандартных потоков ввода/вывода

Рассмотрим несколько примеров перенаправления потоков.

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

$ logger >> file.log

При этом вывод программы logger будет записываться в конец файла file.log, сохраняя все предыдущие записи. Если файла file.log не существует, он будет создан. В отличие от этого, использование символа '>' указывает, что сначала следует очистить файл, а затем производить запись.

Стандартным потокам ввода, вывода и вывода ошибок присваиваются дескрипторы — числовые значения, являющиеся указателями на соответствующий поток. Они, соответственно, равны 0, 1 и 2. Перенаправлять потоки можно, используя эти числовые значения. Таким образом, предыдущему примеру эквивалентна следующая запись:

$ logger 1>>file.log

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

$ run 2>/dev/null

где /dev/null является псевдоустройством, удаляющим все введенные в него символы.

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

$ run_long_program >/dev/null 2>&1 &

сообщения об ошибках будут также выводиться в файл /dev/null. Символ '&' перед именем потока необходим, чтобы отличить его от файла с именем 1. Заметим, что изменение порядка двух перенаправлений потоков приведет к тому, что сообщения об ошибках будут по-прежнему выводиться на экран. Дело в том, что Shell анализирует командную строку слева направо, таким образом сначала будет осуществлено слияние потоков и оба будут указывать на терминал пользователя, а затем стандартный поток вывода (1) будет перенаправлен в файл /dev/null.

Передача потока вывода одной программы в поток ввода другой осуществляется с помощью конвейера '|' (программного канала). Программные каналы часто используются для фильтрации вывода некоторой команды:

$ ps - ef | grep myproc

позволяет получить информацию о конкретном процессе myproc. Утилита ps(1) выводит на экран информацию обо всех процессах в системе, программа grep(1) фильтрует этот поток, оставляя лишь строки, в которых присутствует слово myproc.[14]

Можно усложнить задачу и попытаться получить идентификатор процесса myproc. Однако здесь нам не обойтись без других средств системы. В данном случае мы будем использовать интерпретатор awk(1):

$ ps -ef | grep myproc | awk '{ print $2 }'

Идея заключается в фильтрации второго поля записи о процессе myproc, содержащего идентификатор процесса (см. описание утилиты ps(1)).

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

$ at Dec 31 <<!

cat happy.new.year | elm -s"C Новым Годом"

congratulations@everybody.ru

!

По определению, команда at(1) устанавливает вызов команды, полученной ею со стандартного ввода (клавиатуры терминала), на определенное время (в данном случае — на 31 декабря каждого года). С помощью выражения "ввод здесь" мы явно задали вид этой команды, точнее комплекса команд: cat(1) передает текст поздравления программе elm(1), отвечающей за отправление сообщения электронной почты.

Команды, функции и программы

Все команды, которые вводятся в строке приглашения shell, относятся к одной из следующих категорий:

□ встроенные функции

□ функции shell, определенные пользователем

□ внешние программы и утилиты

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

Запуск встроенной функции не требует порождения нового процесса, поскольку эта функция реализована в самой программе shell (например, /bin/sh). Соответственно, встроенные функции shell выполняются быстрее всего. Рассмотрим важнейшие встроенные функции shell.

: Пустая команда. Код возврата всегда 0 (успех). Пустая команда удобна для создания бесконечных циклов, например:   while :   do ...  done
. runme Текущий командный интерпретатор выполняет команды, указанные в файле runme. При этом не происходит порождения нового shell, как в случае запуска на выполнение runme. Например, использование в скрипте команды . /usr/bin/include_script выполнит команды файла include_script, как если бы они являлись частью текущего скрипта.
break [n] Производит выход из цикла for или while. Если параметр n указан, происходит выход из n вложенных циклов  ps -ef | awk '{ print $1 " " $2}' | while read uid pid do if [$pid -eq $PID] then echo pid=$pid user=$uid break fi done
cd [dir] Осуществляет переход в каталог dir. Если параметр не указан, происходит переход в домашний каталог ($HOME)
echo [string] Строка string выводится на стандартное устройство вывода (терминал)
exec runme Выполняет программу runme, заменяя ею текущий командный интерпретатор. Например, если в login shell (командном интерпретаторе, запускаемом при регистрации пользователя в системе) мы вызовем exec ls, то после вывода имен файлов текущего каталога произойдет завершение работы в системе
exit [n] Завершает работу текущего интерпретатора (или скрипта) с кодом возврата n. По умолчанию код возврат равен 0
export [name1], [name2...] Помещает переменные, указанные в качестве аргументов, в окружение текущего shell, делая их тем самым экспортируемыми, т.е. доступными для запускаемых из интерпретатора программ
hash [-r] [command, command...] Для каждой команды, указанной в качестве аргумента, запоминается полный путь. Таким образом, при последующих вызовах этих команд поиск не производится. Ключ -r удаляет все ранее запомненные пути. Если команда hash вызвана без аргументов, то выводится информация о запомненных путях
jobs Если командный интерпретатор поддерживает управление заданиями, данная команда выводит список текущих заданий. См. раздел «Система управления заданиями», далее в этой главе
kill [-sig] pid1 pid2... Посылает сигнал, определённый параметром sig, процессам, указанным параметрами pid. Параметр pid может быть либо идентификатором процесса, либо идентификатором задания, если поддерживается управление заданиями (в этом случае идентификатор должен предваряться символом '%' в соответствии синтаксисом системы управления заданиями). См. раздел «Система управления заданиями далее в этой главе
pwd Выводит имя текущего каталога
read var1 var2 ... Построчно считывает слова (т.е. группы символов, разделённые пробелами) из стандартного потока ввода, последовательно присваивая переменным var, указанным в качестве параметров значения, равные считанным словам. Если число слов в строке превышает число переменных, то последней переменной присваивается значение, равное остатку строки
return [n] Осуществляет выход из функции с кодом возврата n. По умолчанию возвращается код последней команды
set При задании без параметров выводит список определённых переменных
shift [n] Производит сдвиг позиционных параметров, хранящихся в $1, $2 и т.д. на n позиций. По умолчанию сдвиг производится на одну позицию
test Вычисляет условное выражение. Возвращает значение 0 — истина, или 1 — ложно. См раздел условные выражения далее в этой главе
times Выводит суммарное время использования процессора программами, запущенными из текущего командного интерпретатора
trap command sig1 sig2 ... Определяет команду command, которая будет выполнена при получении сигналов, указанных в качестве аргументов sig. См. раздел "Сигналы" ранее в этой главе
type name Показывает, как name будет интерпретироваться командным интерпретатором
ulimit Выводит или устанавливает значение пределов, ограничивающих использование задачей системных ресурсов (времени процессора, памяти, дискового пространства). Ограничения будут рассматриваться в главе 2
umask nnn Устанавливает маску прав доступа для вновь создаваемых файлов равной nnn
unset var1 var2 ... Удаляет переменные, указанные в качестве аргументов, из списка определенных переменных командного интерпретатора. Некоторые переменные, например PATH, PS1, PS2, не могут быть удалены
wait pid Ожидает завершения выполнения процесса с идентификатором pid и возвращает его код возврата
Пользователь может определить функцию командного интерпретатора и использовать ее как встроенную функцию shell. С другой стороны, функции мало отличаются от скриптов, включая синтаксис и передачу аргументов. Однако являясь частью shell, функции работают быстрее.

Синтаксис функции имеет следующий вид:

function() {

 command1

 command2

 ...

}

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

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

mcd() {

 cd $*

 PS=`pwd`

}

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

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

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

2. Производит подстановки, а именно:

 • Заменяет все указанные переменные их значениями. Например, если значение переменной var равно /usr/bin, то при вызове команды find $var -name sh -print переменная $var будет заменена ее значением. Другими словами, фактический запуск команды будет иметь вид:

find /usr/bin -name sh -print

 • Формирует списки файлов, заменяя шаблоны. При этом производится подстановка следующих шаблонов:

  * — соответствует любому имени файла (или его части), кроме начинающихся с символа '.',

  [abc] — соответствует любому символу из перечисленных (а или b или с),

  ? — соответствует любому одиночному символу.

3. Делает соответствующие назначения потоков ввода/вывода. Если в строке присутствуют символы перенаправления (>, <, >>, <<, |), shell производит соответствующее перенаправление потоков. Программный интерфейс ввода/вывода мы рассмотрим в разделе "Работа с файлами" следующей главы.

4. Выполняет команду, передавая ей аргументы с выполненными подстановками. При этом:

 • Если команда является функцией, определенной пользователем, вызывается функция.

 • В противном случае, если команда является встроенной командой shell, запускается встроенная команда.

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

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

$ ls                   Вывести список файлов каталога

a.out client client.с

server server.с shmem.h

$ rm *                 Удалить файлы

$ ls

$                      Каталог пуст

Команда rm(1) без колебаний выполнит свою функцию, поскольку в качестве аргументов она получит обычный список файлов. Замену символа '*' на список всех файлов каталога произведет shell, и rm(1) трудно догадаться, что вы собираетесь удалить все файлы. Реальный же вызов rm(1) будет иметь вид:

rm a.out client client.с server server.с shmem.h

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

Запуск команд

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

Если необходимо запустить сразу несколько команд, это можно сделать в одной строке, разделив команды символом ';'. Например:

$ pwd; date

Apr 18 1997 21:07

Заметим, что команды будут выполнены последовательно: сначала выполнится команда pwd(1), которая выведет имя текущего каталога, а затем date(1), которая покажет дату и время.

Можно запустить программу в фоновом режиме. В этом случае shell не будет ожидать завершения выполнения программы, а сразу выведет приглашение, и вы сможете продолжить работу в командном интерпретаторе. Для этого строку команды необходимо завершить символом '&':

$ find -name myfile.txt.1 -print >/tmp/myfile.list 2>/dev/null &

$

Пока утилита find(1) производит поиск файла с именем myfile.txt.1, сканируя файловую систему, вы сможете выполнить еще массу полезных дел, например, отправить почту или распечатать документ на принтере. Мы вернемся к этой схеме запуска программ далее в этой главе при обсуждении системы управления заданиями.

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

cmd1 && cmd2

В качестве примера рассмотрим поиск имени пользователя в файле паролей, и в случае успеха — поиск его имени в файле групп:

$ grep sergey /etc/passwd && grep sergey /etc/group

Успехом считается нулевой код возврата программы, неудачей — все другие значения.

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

$ cmd1 || echo Команда завершилась неудачно

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

Условные выражения

Язык Bourne shell позволяет осуществлять ветвление программы, предоставляя оператор if. Приведем синтаксис этого оператора:

if условие

then

 command1

 command2

 ...

fi

Команды command1, command2 и т.д. будут выполнены, если истинно условие. Условие может генерироваться одной или несколькими командами. По существу, ложность или истинность условия определяется кодом возврата последней выполненной команды. Например:

if grep sergey /etc/passwd >/dev/null 2>&1

then

 echo пользователь sergey найден в файле паролей

fi

Если слово sergey будет найдено программой grep(1) в файле паролей (код возврата grep(1) равен 0), то будет выведено соответствующее сообщение.

Возможны более сложные формы оператора if.

set `who -r`

Установим позиционные параметры равными значениям полей вывода программы who(1)

if [ "$9" = "S" ]

Девятое поле вывода — предыдущий уровень выполнения системы; символ 'S' означает однопользовательский режим

then

 echo Система загружается

elif [ "$7" = "2" ]

Седьмое поле — текущий уровень

 echo Переход на уровень выполнения 2

else

 echo Переход на уровень выполнения 3

fi

Данный фрагмент скрипта проверяет уровень выполнения, с которого система совершила переход, и текущий уровень выполнения системы. Соответствующие сообщения выводятся на консоль администратора. В этом фрагменте условие генерируется командой test, эквивалентной (и более наглядной) формой которой является "[]". Команда test является наиболее распространенным способом генерации условия для оператора if.

Команда test

Команда test имеет следующий синтаксис:

test выражение

или

[ выражение ]

Команда вычисляет логическое выражение (табл. 1.10) и возвращает 0, если выражение истинно, и 1 в противном случае.


Таблица 1.10. Выражения, используемые в команде test

Выражения с файлами
-s file Размер файла file больше 0
-r file Для файла file разрешен доступ на чтение
-w file Для файла file разрешен доступ на запись
-x file Для файла file разрешено выполнение
-f file Файл file существует и является обычным файлом
-d file Файл file является каталогом
file Файл file является специальным файлом символьного устройства
-b file Файл file является специальным файлом блочного устройства
file Файл file является поименованным каналом
-u file Файл file имеет установленный флаг SUID
-g file Файл file имеет установленный флаг SGID
-k file Файл file имеет установленный флаг sticky bit
Выражения со строками
-z string Строка string имеет нулевую длину
-n string Длина строки string больше 0
string1 = string2 Две строки идентичны
string1 != string2 Две строки различны
Сравнение целых чисел
i1 -eq i2 i1 равно i2
i1 -ne i2 i1 не равно i2
i1 -lt i2 i1 строго меньше i2
i1 -le i2 i1 меньше или равно i2
i1 -gt i2 i1 строго больше i2
i1 -ge i2 i1 больше или равно i2
Более сложные выражения могут быть образованы с помощью логических операторов:

!выражение Истинно, если выражение ложно (оператор NOT)
выражение1выражение2 Истинно, если оба выражения истинны (оператор AND)
выражение1 -o выражение2 Истинно, если хотя бы одно из выражений истинно (оператор OR)
Приведем несколько примеров использования выражений.

Фрагмент скрипта, используемый при регистрации нового пользователя. Скрипт проверяет наличие в домашнем каталоге инициализационного скрипта .profile и в случае его отсутствия копирует шаблон:

if [ ! -f $НОМЕ/.profile ]

then

 echo "файла .profile не существует - скопируем шаблон"

 cp /usr/lib/mkuser/sh/profile $НОМЕ/.profile

fi

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

if [ -s $MAIL ]

then

 echo "Пришла почта"

fi

Фрагмент скрипта инициализации системы — запуска "суперсервера" Internet inetd(1M). Если исполняемый файл /etc/inetd существует, он запускается на выполнение.

if [ -х /etc/inetd ]

then

 /etc/inetd

 echo "запущен сервер inetd"

fi

Фрагмент скрипта, анализирующий ввод пользователя, сохраненный в переменной ANSW. Если пользователь ввел 'N' или 'n', скрипт завершает свою работу.

if [ "$ANSW" = "N" -о "$ANSW" = "n" ]

then

 exit

fi

Циклы

Язык программирования Bourne shell имеет несколько операторов цикла. Приведем их синтаксис:

1) while условие

do

 command1

 command2

 ...

done

2) until условие

do

 command1

 command2

 ...

done

3) for var in список

do

 command1

 command2

 ...

done

С помощью оператора while команды command1, command2 и т.д. будут выполняться, пока условие не станет ложным. Как и в случае с оператором if, условие генерируется кодом возврата команды, например, test.

В случае оператора until команды command1, command2 и т.д. будут выполняться, пока условие не станет истинным.

Оператор for обеспечивает выполнение цикла столько раз, сколько слов в списке. При этом переменная var последовательно принимает значения, равные словам из списка. Список может формироваться различными способами, например как вывод некоторой команды (`имя_команды_формирующей_список`) или с помощью шаблонов shell.

В другой форме for, когда список отсутствует, переменная var принимает значения позиционных параметров, переданных скрипту.

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

Например, скрипт монтирования всех файловых систем /etc/mounall для системы Solaris 2.5 включает в себя их проверку, исходя из данных, указанных в файле /etc/vfsck. При этом используется оператор while.

#

cat /etc/vfsck |

while read special fsckdev mountp fstype fsckpass automnt mntopts

# Построчно считывает записи файла vfsck и присваивает переменным spe-

# cial, fsckdev и т.д. значения соответствующих конфигурационных полей.

do

 case $special in

 '# ' * | '' ) # Игнорируем комментарии

  continue ;;

 '-') # Игнорируем строки, не требующие действия

  continue ;;

 esac

 # Последовательно проверяем файловые системы с помощью утилиты

 # /usv/sbin/fsck

 /usr/sbin/fsck -m -F $fstype $fsckdev >/dev/null 2>&1

 ...

done

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

for dir in /tmp /usr/tmp /home/tmp

do

 find $dir ! -type d -atime +7 -exec rm {} \;

done

При этом удаляются все файлы в указанных каталогах (/tmp, /usr/tmp и /home/tmp), последний доступ к которым осуществлялся более недели назад.

Селекторы

Оператор case предоставляет удобную форму селектора:

case слово in

шаблон1)

 command

 ...

 ;;

шаблон2)

 command

 ...

 ;;

*)

 command

 ...

 ;;

esac

Значение слово сравнивается с шаблонами, начиная с первого. Если совпадение найдено, то выполняются команды соответствующего раздела, который заканчивается двумя символами ';'. Шаблоны допускают наличие масок, которые были рассмотрены нами в разделе "Подстановки, выполняемые командным интерпретатором". Раздел с шаблоном '*' аналогичен разделу default в синтаксисе селектора switch языка С: если совпадения с другими шаблонами не произошло, то будут выполняться команды раздела '*)'. В качестве примера использования селектора приведем скрипт запуска и останова системы печати в SCO UNIX.

state=$1

set `who -r`

case $state in

'start')

 if [ $9 = "2" -o $9 = "3" ]

 then

  exit

 fi

 [ -f /usr/lib/lpshed ] && /usr/lib/lpshed

 ;;

'stop')

 [ -f /usr/lib/lpshut ] && /usr/lib/lpshut

 ;;

*)

 echo "usage $0 start|stop"

 ;;

esac

В случае, когда скрипт вызван с параметром start, будет произведен запуск системы печати. Если параметр скрипта — stop, то система печати будет остановлена. Запуск скрипта с любым другим параметром приведет к выводу сообщения об ошибке.

Ввод

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

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

Текст скрипта test5.sh:

#!/bin/sh

echo "input: "

while read var1 var2 var3

do

 echo var1=$var1

 echo var2=$var2

 echo var3=$var3

 echo "input: "

done

Запуск скрипта

$ test5.sh

input: пример работы команды read

var1=пример

var2=работы

var3=команды read

input: еще пример

var1=еще

var2=пример

var3=

input: ^D

$

В приведенном примере read в цикле считывает пользовательский ввод. Цикл завершается, когда достигнут конец файла (что эквивалентно пользовательскому вводу <Ctrl>+<D>), поскольку при этом read возвращает неудачу (код возврата равен 1) и while завершает работу. В первом цикле число введенных слов превышает количество переменных, поэтому значение переменной var3 состоит из двух слов. Во втором цикле значение var3 пусто.

Система управления заданиями

Командный интерпретатор может поддерживать управление заданиями. Для Bourne shell (/bin/sh), который мы рассматриваем, систему управления заданиями включает парный ему интерпретатор /bin/jsh. В остальном этот интерпретатор имеет те же возможности.

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

Состояние задания Характеристики
Выполняется в текущем режиме Задание может считывать данные и выводить данные на терминал пользователя
Выполняется в фоновом режиме Заданию запрещен ввод с терминала. Возможность вывода на терминал определяется дополнительными установками
Приостановлено Задание не выполняется
Каждое задание при запуске получает уникальный идентификатор, называемый номером задания, который используется в командах системы управления. Синтаксис номера задания, применяемый в командах:

%jobid

где jobid может принимать следующие значения:

% или + Текущее задание — самое последнее запущенное или вновь запущенное задание
- Предыдущее задание (по отношению к текущему)
?строка Задание, для которого строка присутствует в командной строке запуска
n Задание с номером n
pref Задание, на которое можно уникально указать префиксом pref, например, команда ls(1), запущенная в фоновом режиме, адресуется заданием %ls
Система управления заданиями позволяет использовать следующие дополнительные команды:

bg [%jobid] Продолжает выполнение остановленного задания в фоновом режиме. Без параметра относится к текущему заданию.
fg [%jobid] Продолжает выполнение остановленного задания в текущем режиме. Если задание jobid выполнялось в фоновом режиме, команда перемещает его в текущий режим.
jobs [-p | -l] [%jobid ... ] Выводит информацию об остановленных и фоновых заданиях с указанными номерами. Если последний аргумент опущен, выводится информация обо всех остановленных и фоновых заданиях. Приведенные ниже опции изменяют формат вывода: -l Вывести идентификатор группы процессов и рабочий каталог.  Вывести только идентификатор группы процессов.
kill [-signo] %jobid Обеспечивает те же возможности, что и команда kill(1), но по отношению к заданиям.
stop %jobid Останавливает выполнения фонового задания.
wait %jobid Ожидает завершения выполнения задания jobid и возвращает его код возврата.
Приведенный ниже пример иллюстрирует использование команд управления заданиями и не нуждается в комментариях:

$ inf.j &

[1] 9112

$ comm1 &

[2] 9113

$ jobs

[1] - Running inf.j

[2] + Running comm1

$ stop %1

$ jobs

[1] - Stopped (signal) inf.j

[2] + Running comm1

$ stop %%

$ jobs -1

[1] - 9112 Stopped (signal) inf.j (wd: /home/andy/SH//JOB)

[2] + 9113 Stopped (signal) comm1 (wd: /home/andy/SH/JOB)

$ bg %1

[1] inf.j &

$ jobs

[1] + Running inf.j

[2] - Stopped (signal) comm1

$ kill %1 %2

$ jobs

[1] + Done(208) inf.j

[2] - Done (208) comm1

$

Основные утилиты UNIX

В предыдущих разделах мы использовали некоторые утилиты UNIX. Ниже приводятся краткие характеристики утилит, выпавших из поля нашего зрения. Более подробно с различными утилитами можно познакомиться в электронном справочнике man(1).

Утилиты для работы с файлами

Поле [opt] содержит конкретные опции каждой утилиты.

cd [dir] Изменяет текущий каталог. При задании без параметра — производит переход в домашний каталог пользователя.
cmp [opt] file1 file2 Утилита cmp(1) сравнивает два файла, указанных в качестве аргументов. Если файлы одинаковы, никакого сообщения не выводится. В противном случае выводятся данные о первом несоответствии между этими файлами (в данном примере первое различие найдено в 13-м символе 4-й строки): cat file1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 $ cat file2 1 2 3 4 5 6 diff1 7 8 9 10 11 12 13 14 15 diff2 $ cmp file1 file2 file1 file2 differ: char 13, line 4
diff [opt] file1 file2 Утилита diff(1) также сравнивает два файла и выводит список изменений, которые необходимо внести в содержимое этих файлов для того, чтобы преобразовать первый файл во второй. По существу, вывод утилиты diff(1) представляет собой команды редактора ed(1), необходимые для преобразования file1 в file2: $ diff file1 file2 3a4 > diff1 5c6, 7 < 11 12 13 14 15 ... > 11 12 13 14 15 diff2
cp [opt] file1 file2 cp [opt] file1 ... dir Утилита cp(1) служит для копирования файлов. При этом создается не жесткая связь, а новый файл: cp file1 file2ls -li file1 file2 261425 -rw-r--r-- 1 andy user 49 Dec 24 12:58 file1 261427 -rw-r--r-- 1 andy user 49 Dec 24 13:13 file2
mv [opt] file1 file2 mv [opt] file1 ... dir Утилита mv(1) изменяет имя файла. Если последний параметр является каталогом, то число аргументов утилит cp(1) или mv(1) может превышать 2. В этом случае будет производиться копирование или перемещение указанных файлов в каталог.
rm [opt] file1... rmdir dir1... Утилиты удаления файлов и каталогов. При этом удаляются только записи имен файлов в соответствующих каталогах, фактическое содержимое файла (метаданные и дисковые данные) будет удалено, если число жестких связей для файла станет равным 0.
ls [opt] [file1 file2 ...] Без параметров утилита ls(1) выводит имена файлов текущего каталога. В качестве параметров можно задать имена каталогов, содержимое которых необходимо вывести, или имена файлов, информацию о которых нужно получить. Опции утилиты позволяют получить список различной информативности и формата.
ln [opt] source target Утилита ln(1) создает жесткую связь имени source с файлом, адресуемым именем target. При использовании опции -s будет создана символическая связь.
mkdir [-m mode] [-p] dir1... Создать каталог.
pwd Вывести имя текущего каталога.
fgrep [opt] <подстрока> file1... Утилиты поиска фрагментов текста в файлах. Могут использоваться в качестве фильтров в программных каналах. Для поиска подстроки в файлах можно использовать самую простую из утилит fgrep(1) (fast grep). Если подстрока поиска содержит пробелы или знаки табуляции, ее необходимо заключить в кавычки. Если подстрока уже содержит кавычки, их надо экранировать, поместив символ '\' непосредственно перед кавычками: fgrep "рассмотрим в разделе \"Создание процесса\"" chap* Если вы хотите сделать поиск нечувствительным к заглавным/строчным символам, используйте ключ . Для поиска строк, не содержащих указанную подстроку, используется ключ -v.
grep [opt] <рег_выражение> file1... egrep [opt]  <рег_выражение> file1... Утилиты grep(1) и egrep(1) позволяют производить более сложный поиск, например, когда вы не уверены в написании искомого слова, или хотите найти слова, расположенные в определенных местах файла. В этом случае в качестве подстроки поиска указывается регулярное выражение (рег_выражение). Например, чтобы произвести поиск слова "центр" в американском (center) и британском (centre) написании, можно задать следующую команду: grep "cent[er]" file или grep "cent[er][er]" file [er] является регулярным выражением, соответствующим либо символу 'е', либо 'r'. Регулярное выражение должно быть заключено в кавычки для предотвращения интерпретации специальных символов командным интерпретатором shell.
cat [opt] file Утилиты просмотра содержимого файла. Команда cat file выводит содержимое файла file на экран терминала. Если у вас есть подозрение, что файл не текстовый, т.е. содержит "непечатные" символы, лучше запустить cat(1) с ключом -v. В этом случае вывод таких символов (которые, кстати, могут нарушить настройки вашего терминала) будет подавлен.
more [opt] file pg [opt] file Если размер файла велик и его содержимое не помещается в терминальном окне, удобнее будет воспользоваться утилитами pg(1) и more(1), позволяющими выводить файл порциями.
head [-n] file tail [opt] file Посмотреть только начало (первые n строк) или конец (последние n строк) файла можно с помощью утилит head(1) и tail(1), соответственно.
sort Для сортировки строк файла используется утилита sort(1). Например, для сортировки текста в алфавитном порядке необходимо ввести следующую команду: sort -d file >sorted file Вы можете указать номер слова строки, по которому необходимо произвести сортировку (точнее, номер поля записи; по умолчанию записью является строка, а поля разделены пробелами). Например, для сортировки строк файла file Андрей Май Борис Январь Владимир Март по месяцам, можно использовать команду sort -M +1 file в результате получим: Борис Январь Владимир Март Андрей Май Опция -M определяет сортировку по месяцам (не по алфавиту), опция +1 указывает, что сортировку необходимо проводить по второму полю каждой строки.
cut Позволяет отфильтровать указанные поля строк файла. Разделитель полей указывается опцией -d<sep>. Например, чтобы получить реальные имена пользователей системы (пятое поле файла паролей), можно использовать следующую команду: $ cat /etc/passwd | cut -f5 -d: ... WWW Administrator Yuri Korenev Serge Smirnoff W3 group Konstantin Fedorov Andrei Robachevsky Sergey Petrov
wc file Позволяет вывести число строк, слов и символов текста файла.
find dir [opt] Выполняет поиск файла в файловой системе UNIX, начиная с каталога dir. Например, для вывода полного имени исполняемого файла командного интерпретатора Bourne shell введите команду: find / -name sh -print 2>/dev/null /usr/bin/sh /usr/xpg4/bin/sh /sbin/sh С помощью опции -name указывается имя искомого файла, а с помощью опции -print — действие (вывести полное имя). С помощью find(1) можно производить поиск файлов по другим критериям, например, размеру, последнему времени модификации и т.д. Например, чтобы найти файлы с именем core (образ процесса, создаваемый при неудачном его завершении и используемый в целях отладки), последнее обращение к которым было, скажем, более месяца назад (скорее всего такие файлы не нужны пользователям и только "засоряют" файловую систему), можно задать команду: find / -name core -atime +30 -print /u/local/lib/zircon/lib/core /u/local/etc/httpd/data/zzmaps/core /home/amd/WORK/novosti/core /home/amd/WORK/access/core /home/guests/snell/core Если вы сторонник жесткого администрирования, то можно применить следующую команду: find / -name core -atime +30 -exec rm {} \; которая автоматически удалит все найденные файлы.
chown user file ... Изменяет владельца-пользователя указанных файлов.
chgrp group file ... Изменяет владельца-группу указанных файлов.
chmod mode file ... Изменяет права доступа и дополнительные атрибуты файлов.
file file1 ... Сканирует начало файла и пытается определить его тип. Если это текстовый файл (ASCII), file(1) пытается определить его синтаксис (текст, программа на С и т.д.). Если это бинарный файл, то классификация ведется по так называемому magic number, определения которого находятся в файле /etc/magic. file * nlc-2.2d.tar: tar archive report.doc: ascii text work: directory runme.c: с program text runme: ELF 32-bit MSB executable figure.gif: data

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

nice -[[-]n] command Утилита nice(1) применяется для запуска программы на выполнение с относительным приоритетом (nice number), отличным от принятого по умолчанию. Например, ввод команды: nice -10 big program приведет к запуску big program с большим значением nice. В UNIX чем больше значение nice number, тем меньший приоритет имеет процесс. Таким образом, при планировании выполнения процессов вероятность того, что ядро операционной системы выберет именно big_program для запуска, уменьшится. Как следствие, big_program станет выполняться дольше, но будет менее интенсивно потреблять процессорные ресурсы. Только администратор системы может повысить приоритет процесса (уменьшить значение nice number): nice - -10 job1
renice new_nice pid Утилита renice(1) позволяет изменять приоритет процесса во время его выполнения. Например, команда $ renice 5 1836 устанавливает значение nice number процесса с идентификатором 1836 равным 5. Как и в случае команды nice(1), увеличить приоритет процесса может только администратор системы.
ps Утилита ps(1) выводит информацию о существующих процессах. При использовании различных опций она позволяет получить следующую информацию:
F статус процесса (системный процесс, блокировки в памяти и т.д.)
S состояние процесса (О — выполняется процессором, S — находится в состоянии сна, R — готов к выполнению, I — создается, Z — зомби)
UID идентификатор (имя) пользователя — владельца процесса
PID идентификатор процесса
PPID идентификатор родительского процесса
PRI текущий динамический приоритет процесса
NI значение nice number процесса
TTY управляющий терминал процесса ('?' — означает отсутствие управляющего терминала)
TIME суммарное время выполнения процесса процессором
STIME время создания процесса (может отличаться от времени запуска команды)
COMMAND имя команды, соответствующей процессу
kill [signo] pid1, pid2... Посылает процессам с идентификаторами pid1, pid2 и т.д. сигнал signo. Сигнал signo может быть указан как в числовой, так и в символьной форме. Команда kill -l выводит таблицу соответствия между символьными именами сигналов и их числовыми значениями: kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGIOT 7) SIGEMT 8) SIGFPE 9) SIGKILL 10) SIGBUS 11) SIGSEGV 12) SIGSYS 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGUSR1 ... Таким образом, следующие две команды эквивалентны: $ kill -9 18793kill -SIGKILL 18793
at [opt] время_запуска Утилита at(1) считывает команды стандартного потока ввода и группирует их в задание at, которое будет выполнено в указанное пользователем время. Для выполнения задания будет запущен командный интерпретатор, в среде которого и будут исполнены команды. Например, следующая команда, позволит вам поздравить друга с днем рождения в назначенное время: at May 30 <<! cat birthday.txt | elm -s"C Днем Рождения!" andy@cool.com ! Вы можете добавить опцию -m, и после выполнения задания вам будет отправлено уведомление по электронной почте.

Об администрировании UNIX

Достаточно открыть оглавление любого "Руководства системного администратора" для UNIX, чтобы оценить то многообразие задач и проблем, с которыми приходится сталкиваться при обслуживании системы:

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

□ Регистрация пользователей. Каждый новый пользователь добавляет "забот" администратору системы, но какой же UNIX без пользователей!

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

□ Настройка производительности системы.

□ Обучение, наставление, "ссоры" и "примирения" с пользователями операционной системы, которую вы обслуживаете.

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

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

Можно выделить четыре типа системных администраторов UNIX:

□ Технический бандит. Обычно в прошлом системный программист, вынужденный заниматься системным администрированием. Пишет скрипты на смеси языков интерпретатора Bourne shell, sed, С, awk, perl и APL.

□ Администратор-фашист. Обычно это законченный тунеядец (реже — бывшая ведьма-секретарша), вынужденный заниматься системным администрированием.

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

□ Идиот. Полный кретин или старый программист на Коболе, выбранный в системные администраторы комитетом, состоящим из таких же кретинов или старых программистов на Коболе.

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

Ситуация 1. Нехватка дискового пространства

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

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

Маньяк:

# cd /home

# rm -rf `du -s * | sort -rn | head -1 | awk '{print $2}'`

Идиот:

# cd /home

# cat `du -s * | sort -rn | head -1 | awk '{ printf "%s/*\n", $2}'` | compress

Ситуация 2. Избыточная загрузка процессора

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

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

Маньяк:

# kill -9 `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'`

Идиот:

# compress -f `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'`

Ситуация 3. Регистрация новых пользователей

Технический бандит. Пишет скрипт на языке Perl, создающий домашний каталог пользователя, определяющий непонятное окружение и помещающий записи в файлы /etc/passwd, /etc/shadow и /etc/group. Устанавливает на скрипт бит SUID и обязывает секретаршу обеспечить регистрацию новых пользователей. Поскольку обычно секретарша так и не может разобраться в разнице между <Enter> и <Return>, ни один новый пользователь не зарегистрирован.

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

Маньяк. "Если ты настолько глуп, что не можешь взломать машину и самостоятельно зарегистрироваться, тебе нечего делать в моей системе. В этом ящике и так слишком много придурков".

Идиот:

# cd /home; mkdir "Bob's home directory"

# echo "Bob Simon:gandalf:0:0::/dev/tty:compress -f" > /etc/passwd

Ситуация 4. Авария загрузочного диска

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

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

Маньяк. Извлекает диск. С помощью кузнечного молота пытается подогнать отдельные пластины. Звонит производителю. Во время установки нового диска и операционной системы наносит оскорбления присланному инженеру.

Идиот. Не замечает ничего необычного.

Ситуация 5. Слабая производительность сети

Технический бандит. Пишет скрипт для мониторинга сети, переписывает программное обеспечение, чем повышает производительность на 2%. Пожимает плечами, говорит: "Я сделал все, что мог", и отправляется в поход в горы.

Администратор-фашист. Помещает правила работы в сети в сообщение дня motd. Звонит в Беркли и в AT&T, приставая к ним, как установить сетевые квоты. Пытается уволить поклонников игры в xtrek.

Маньяк. Каждые два часа размыкает кабель Ethernet и ждет тайм-аута на сетевых соединениях.

Идиот:

# compress -f /dev/en0

Ситуация 6. "Глупые" вопросы пользователей

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

Администратор-фашист. Блокирует вход пользователя в систему, пока тот не представит веские доказательства своей квалификации.

Маньяк:

# cat >> ~luser/.cshrc

alias vi 'rm \!*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z;

mv -f ~/.z ~/~/cshrc'

^D

Идиот. Отвечает на все вопросы в меру своего понимания. Приглашает пользователя в группу администрирования системы.

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

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

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

Маньяк:

# uptime

1:33pm up 19 days, 22:49, 167 users, load average: 6.49, 6.45, 6.31

# wall

Итак, настало время установки новой версии. Займет несколько часов, и если нам повезет - управимся к 5-00. Мы работаем для вас!

^D

Идиот:

# dd if=/dev/rmt8 of=/vmunix

Ситуация 8. Пользователям необходима электронная телефонная книга

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

Администратор-фашист. Устанавливает Oracle. Отчаявшиеся пользователи возвращаются к использованию записных книжек.

Маньяк. Предлагает пользователям хранить данные в едином сплошном файле и применять grep(1) для поиска телефонных номеров.

Идиот:

% dd ibs=80 if=/dev/rdisk001s7 | grep "Fred"

Заключение

Эта глава знакомит с пользовательской средой UNIX, а также с основными подсистемами этой операционной системы — файловой подсистемой, подсистемой управления процессами и памятью, и с подсистемой ввода/вывода.

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

Глава 2 Среда программирования UNIX

Одной из целей, которые изначально ставились перед разработчиками UNIX, являлось создание удобной среды программирования. Во многом это справедливо и сегодня.

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

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

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

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

Программный интерфейс UNIX

Системные вызовы и функции стандартных библиотек

Все версии UNIX предоставляют строго определенный ограниченный набор входов в ядро операционной системы, через которые прикладные задачи имеют возможность воспользоваться базовыми услугами, предоставляемыми UNIX. Эти точки входа получили название системных вызовов (system calls). Системный вызов, таким образом, определяет функцию, выполняемую ядром операционной системы от имени процесса, выполнившего вызов, и является интерфейсом самого низкого уровня взаимодействия прикладных процессов с ядром. Седьмая редакция UNIX включала около 50 системных вызовов, современные версии, например, SVR4, предлагают более 120.

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

Помимо системных вызовов программисту предлагается большой набор функций общего назначения. Эти функции не являются точками входа в ядро операционной системы, хотя в процессе выполнения многие из них выполняют системные вызовы. Например, функция printf(3S) использует системный вызов write(2) для записи данных в файл, в то время как функции strcpy(3C) (копирование строки) или atoi(3C) (преобразование символа в его числовое значение) вообще не прибегают к услугам операционной системы. Функции, о которых идет речь, хранятся в стандартных библиотеках С и наряду с системными вызовами составляют основу среды программирования в UNIX. Подробное описание этих функций приведено в разделе 3 электронного справочника.

Таким образом, часть библиотечных функций является "надстройкой" над системными вызовами, обеспечивающей более удобный способ получения системных услуг. В качестве примера рассмотрим процесс получения текущей даты и времени. Соответствующий системный вызов time(2) возвращает время в секундах, прошедшее с момента Epoch: 1 января 1970 года. Дополнительная интерпретация этого значения, такая как преобразование в вид, удобный для восприятия (дата и время) с учетом временной зоны, осуществляется библиотечными функциями (ctime(3C), localtime(3C) и т.д.). К этим функциям можно отнести функции библиотеки ввода/вывода, функции распределения памяти, часть функций управления процессами и т.д.

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

Рис. 2.1. Системные вызовы и библиотечные функции

Обработка ошибок

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

Обычно в случае возникновения ошибки системные вызовы возвращают и устанавливают значение переменной errno, указывающее причину возникновения ошибки. Так, например, существует более десятка причин завершения вызова open(2) с ошибкой, и все они могут быть определены с помощью переменной errno. Файл заголовков <errno.h> содержит коды ошибок, значения которых может принимать переменная errno, с краткими комментариями.

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

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

Переменная errno определена следующим образом:

external int errno;

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

Стандарт ANSI С определяет две функции, помогающие сообщить причину ошибочной ситуации: strerror(3C) и perror(3C).

Функция strerror(3C) имеет вид:

#include <string.h>


char *strerror(int errnum);

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

Функция perror(3C) объявлена следующим образом:

#include <errno.h>

#include <stdio.h>


void perror(const char *s);

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

Следующий пример иллюстрирует использование этих двух функций:

#include <errno.h>

#include <stdio.h>


main(int argc, char *argv[]) {

 fprintf(stderr, "ENOMEM: %s\n", strerror(ENOMEM));

 errno = ENOEXEC;

 perror(argv[0]);

}

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

$ a.out

ENOMEM: Not enough space

a.out: Exec format error

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

$ rm does_not_exist

does_not_exist: No such file or directory ошибка ENOENT

$ pg do_not_read

do_not_read: Permission denied            ошибка EACCESS

$

В табл. 2.1 приведены наиболее общие ошибки системных вызовов, включая сообщения, которые обычно выводят функции strerror(3C) и perror(3C), а также их краткое описание.


Таблица 2.1. Некоторые ошибки системных вызовов

Код ошибки и сообщение Описание
E2BIG Arg list too long Размер списка аргументов, переданных системному вызову exec(2), плюс размер экспортируемых переменных окружения превышает ARG_MAX байт
EACCESS Permission denied Попытка доступа к файлу с недостаточными правами для данного класса (определяемого эффективным UID и GID процесса и соответствующими идентификаторами файла)
EAGAIN Resource temporarily unavailable Превышен предел использования некоторого ресурса, например, переполнена таблица процессов или пользователь превысил ограничение по количеству процессов с одинаковым UID. Причиной также может являться недостаток памяти или превышение соответствующего ограничения (см. раздел "Ограничения" далее в этой главе)
EALREADY Operation already in progress Попытка операции с неблокируемым объектом, уже обслуживающим некоторую операцию
EBADF Bad file number Попытка операции с файловым дескриптором, не адресующим никакой файл; также попытка операции чтения или записи с файловым дескриптором, полученным при открытии файла на запись или чтение, соответственно
EBADFD File descriptor in bad state Файловый дескриптор не адресует открытый файл или попытка операции чтения с файловым дескриптором, полученным при открытии файла только на запись
EBUSY Device busy Попытка монтирования устройства (файловой системы), которое уже примонтировано; попытка размонтировать файловую систему, имеющую открытые файлы; попытка обращения к недоступным ресурсам (семафоры, блокираторы и т.п.)
ECHILD No child processes Вызов функции wait(2) процессом, не имеющим дочерних процессов или процессов, для которых уже был сделан вызов wait(2)
EDQUOT Disk quota exceeded Попытка записи в файл, создание каталога или файла при превышении квоты пользователя на дисковые блоки, попытка создания файла при превышении пользовательской квоты на число inode
EEXIST File exists Имя существующего файла использовано в недопустимом контексте, например, сделана попытка создания символической связи с именем уже существующего файла
EFAULT Bad address Аппаратная ошибка при попытке использования системой аргумента функции, например, в качестве указателя передан недопустимый адрес
EFBIG File too large Размер файла превысил установленное ограничение RLIMIT_FSIZE или максимально допустимый размер для данной файловой системы (см. раздел "Ограничения" далее в этой главе)
EINPROGRESS Operation now in progress Попытка длительной операции (например, установление сетевого соединения) для неблокируемого объекта
EINTR Interrupted system call Получение асинхронного сигнала, например, сигнала SIGINT или SIGQUIT, во время обработки системного вызова. Если выполнение процесса будет продолжено после обработки сигнала, прерванный системный вызов завершится с этой ошибкой
EINVAL Invalid argument Передача неверного аргумента системному вызову. Например, размонтирование устройства (файловой системы), которое не было примонтировано. Другой пример — передача номера несуществующего сигнала системному вызову kill(2)
EIO I/O error Ошибка ввода/вывода физического устройства
EISDIR Is a directory Попытка операции, недопустимой для каталога, например, запись в каталог с помощью вызова write(2)
ELOOP Number of symbolic links encountered during path name traversal exceeds MAXSYMLINKS При попытке трансляции имени файла было обнаружено недопустимо большое число символических связей, превышающее значение MAXSYMLINKS
EMFILE Too many open files Число открытых файлов для процесса превысило максимальное значение OPEN_MAX
ENAMETOOLONG File name too long Длина полного имени файла (включая путь) превысила максимальное значение PATH_MAX
ENFILE File table overflow Переполнение файловой таблицы
ENODEV No such device Попытка недопустимой операции для устройства. Например, попытка чтения устройства только для записи или операция для несуществующего устройства
ENOENT No such file or directory Файл с указанным именем не существует или отсутствует каталог, указанный в полном имени файла
ENOEXEC Exec format error Попытка запуска на выполнение файла, который имеет права на выполнение, но не является файлом допустимого исполняемого формата
ENOMEM Not enough space При попытке запуска программы (exec(2)) или размещения памяти (brk(2)) размер запрашиваемой памяти превысил максимально возможный в системе
ENOMSG No message of desired type Попытка получения сообщения определенного типа, которого не существует в очереди (см. раздел "Сообщения" в главе 3)
ENOSPC No space left on device Попытка записи в файл или создания нового каталога при отсутствии свободного места на устройстве (в файловой системе)
ENOSR Out of stream resources Отсутствие очередей или головных модулей при попытке открытия устройства STREAMS. Это состояние является временным. После освобождения соответствующих ресурсов другими процессами операция может пройти успешно
ENOSTR Not a stream device Попытка применения операции, определенной для устройств типа STREAMS (например системного вызова putmsg(2) или getmsg(2)), для устройства другого типа
ENOTDIR Not a directory В операции, предусматривающей в качестве аргумента имя каталога, было указано имя файла другого типа (например, в пути для полного имени файла)
ENOTTY Inappropriate ioctl for device Попытка системного вызова ioctl(2) для устройства, которое не является символьным
EPERM Not owner Попытка модификации файла, способом, разрешенным только владельцу и суперпользователю и запрещенным остальным пользователям. Попытка операции, разрешенной только суперпользователю
EPIPE Broken pipe Попытка записи в канал (pipe), для которого не существует процесса, принимающего данные. В этой ситуации процессу обычно отправляется соответствующий сигнал. Ошибка возвращается при игнорировании сигнала
EROFS Read-only file system Попытка модификации файла или каталога для устройства (файловой системы), примонтированного только на чтение
ESRCH No such process Процесс с указанным PID не существует в системе

Создание программы

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

В этом разделе рассмотрен процесс создания приложения, написанного на языке С и разработанного для операционной системы UNIX. Предвидя обвинения в архаизме, мы все-таки остановимся на добротном ANSI С и базовой среде разработки UNIX, во-первых, полагая, что старый друг лучше новых двух, а во-вторых потому, что объектом нашего обсуждения все же является UNIX, а не современные средства создания приложений. Заметим также, что язык программирования С является "родным" языком UNIX, поскольку ядро операционной системы написано на этом языке[15]. Это, безусловно, не ограничивает возможности других языков и технологий программирования, которые сегодня, наверное, используются даже чаще, чем обсуждаемый нами традиционный подход.

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

Исходный текст

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

В этом (за исключением, пожалуй, четвертого совета) вам помогут электронный справочник man(1), ваш опыт, и, надеюсь, эта книга.

Заголовки

Использование системных функций обычно требует включения в текст программы файлов заголовков, содержащих определения функций — число передаваемых аргументов, типы аргументов и возвращаемого значения. Большинство системных файлов заголовков расположены в каталогах /usr/include или /usr/include/sys. Если вы планируете использовать малознакомую системную функцию, будет нелишним изучить соответствующий раздел электронного справочника man(1). Там же, помимо описания формата функции, возвращаемого значения и особых ситуаций, вы найдете указание, какие файлы заголовков следует включить в программу.

Файлы заголовков включаются в программу с помощью директивы #include. При этом, если имя файла заключено в угловые скобки (<>), это означает, что поиск файла будет производиться в общепринятых каталогах хранения файлов заголовков. Если же имя файла заголовка заключено в кавычки, то используется явно указанное абсолютное или относительное имя файла.

Например, системный вызов creat(2) служащий для создания обычного файла, объявлен в файле <fcntl.h> следующим образом:

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>


int creat(const char *path, mode_t mode);

Включение в исходный текст прототипа системного вызова creat(2) позволяет компилятору произвести дополнительную проверку правильности использования этой функции, а именно — числа аргументов и их типов. Можно заметить, что наряду со стандартными типами языка С, например char, для второго аргумента creat(2) используется производный тип — mode_t. В ранних версиях UNIX большинство системных вызовов использовали стандартные типы, например, creat(2) для второго аргумента охотно принимала тип int. Производные типы переменных, имеющие окончание _t, которые вы в большом количестве встретите при программировании в UNIX, получили название примитивов системных данных. Большинство этих типов определены в файле <sys/types.h>, а их назначение заключается в улучшении переносимости написанных программ. Вместо конкретных типов данных, каковыми являются int, char и т.п., приложению предлагается набор системных типов, гарантированно неизменных в контексте системных вызовов. Другими словами, во всех версиях UNIX сегодня и спустя десять лет, системный вызов creat(2) в качестве второго аргумента будет принимать переменную типа mode_t. Фактический размер переменных этого типа может быть разным для различных версий системы, но это отразится в изменении соответствующего файла заголовков и потребует только перекомпиляции вашей программы.

Среда программирования UNIX определяется несколькими стандартами, обсуждавшимися во введении, и может незначительно различаться для разных версий системы. В частности, стандарты ANSI С, POSIX. 1 и XPG4, определяют названия и назначения файлов заголовков, приведенных в табл. 2.2.


Таблица 2.2. Стандартные файлы заголовков

Файл заголовка Назначение
<assert.h> Содержит прототип функции assert(3C), используемой для диагностики
<cpio.h> Содержит определения, используемые для файловых архивов cpio(1)
<ctype.h> Содержит определения символьных типов, а также прототипы функций определения классов символов (ASCII, печатные, цифровые и т.д.) — isascii(3C), isprint(3C), isdigit(3C) и т.д.
<dirent.h> Содержит определения структур данных каталога, а также прототипы функций работы с каталогами opendir(3C), readdir(3C) и т.д.
<errno.h> Содержит определения кодов ошибок (см. раздел "Обработка ошибок" в начале главы)
<fcntl.h> Содержит прототипы системных вызовов fcntl(2), open(2) и creat(2), а также определения констант и структур данных, необходимых при работе с файлами
<float.h> Содержит определения констант, необходимых для операций с плавающей точкой
<ftw.h> Содержит прототипы функций, используемых для сканирования дерева файловой системы (file tree walk) ftw(3C) и nftw(3C), a также определения используемых констант
<grp.h> Содержит прототипы функций и определения структур данных, используемых для работы с группами пользователей: getgrnam(3C), getgrent(3C), getgrgid(3C) и т.д.
<langinfo.h> Содержит определения языковых констант: дни недели, названия месяцев и т.д., а также прототип функции langinfo(3C)
<limits.h> Содержит определения констант, определяющих значения ограничений для данной реализации: минимальные и максимальные значения основных типов данных, максимальное значение файловых связей, максимальная длина имени файла и т.д.
<locale.h> Содержит определения констант, используемых для создания пользовательской среды, зависящей от языковых и культурных традиций (форматы дат, денежные форматы и т.д.), а также прототип функции setlocale(3C)
<math.h> Содержит определения математических констант (π, е, √2 и т.д.)
<nl_types.h> Содержит определения для каталогов сообщений (message catalog), а также прототипы функций catopen(3C) и catclose(3C)
<pwd.h> Содержит определение структуры файла паролей /etc/passwd, а также прототипы функций работы с ним: getpwnam(3C), getpwent(3C), getpwuid(3C) и т.д.
<regex.h> Содержит определения констант и структур данных, используемых в регулярных выражениях, а также прототипы функций для работы с ними: regcomp(3C), regexec(3C) и т.д.
<search.h> Содержит определения констант и структур данных, а также прототипы функций, необходимых для поиска: hsearch(3C), hcreate(3C), hdestroy(3C)
<setjmp.h> Содержит прототипы функций перехода setjmp(3C), sigsetjmp(3C), longjmp(3C), siglongjmp(3C), а также определения связанных с ними структур данных
<signal.h> Содержит определения констант и прототипы функций, необходимых для работы с сигналами: sigsetops(3C), sigemptyset(3C), sigaddset(3C) и т.д. (см. раздел "Сигналы" далее в этой главе)
<stdarg.h> Содержит определения, необходимые для поддержки списков аргументов переменной длины
<stddef.h> Содержит стандартные определения (например size_t)
<stdio.h> Содержит определения стандартной библиотеки ввода/вывода
<stdlib.h> Содержит определения стандартной библиотеки
<string.h> Содержит прототипы функций работы со строками string(3C), strcasecmp(3C), strcat(3C), strcpy(3C) и т.д.
<tar.h> Содержит определения, используемые для файловых архивов tar(1)
<termios.h> Содержит определения констант, структур данных и прототипы функций для обработки терминального ввода/вывода
<time.h> Содержит определения типов, констант и прототипы функций для работы со временем и датами: time(2), ctime(3C), localtime(3C), tzset(3C), а также определения, относящиеся к таймерам getitimer(2), setitimer(2). Таймеры будут рассмотрены в главе 3
<ulimit.h> Содержит определения констант и прототип системного вызова ulimit(2) для управления ограничениями, накладываемыми на процесс. См. также раздел "Ограничения" далее в этой главе
<unistd.h> Содержит определения системных символьных констант, а также прототипы большинства системных вызовов
<utime.h> Содержит определения структур данных и прототип системного вызова utime(2) для работы с временными характеристиками файла (временем доступа и модификации)
<sys/ipc.h> Содержит определения, относящиеся к системе межпроцессного взаимодействия (IPC), которые рассматриваются в главе 3
<sys/msg.h> Содержит определения, относящиеся к (сообщениям) подсистеме IPC. См. также раздел "Сообщения" главы 3
<sys/resource.h> Содержит определения констант и прототипы системных вызовов управления размерами ресурсов, доступных процессу: getrlimit(2) и setrlimit(2). Более подробно ограничения на ресурсы обсуждаются в разделе "Ограничения" далее в этой главе
<sys/sem.h> Содержит определения, относящиеся к (семафорам) подсистеме IPC. См. также раздел "Семафоры" главы 3
<sys/shm.h> Содержит определения, относящиеся к (разделяемой памяти) подсистеме IPC. См. также раздел "Разделяемая память" главы 3
<sys/stat.h> Содержит определения структур данных и прототипы системных вызовов, необходимых для получения информации о файле: stat(2), lstat(2), fstat(2). Подробнее эти системные вызовы рассмотрены в разделе "Метаданные файла" далее в этой главе
<sys/times.h> Содержит определения структур данных и прототипа системного вызова times(2), служащего для получения статистики выполнения процесса (времени выполнения в режиме ядра, задачи и т.д.)
<sys/types.h> Содержит определения примитивов системных данных
<sys/utsname.h> Содержит определения структур данных и прототип системного вызова uname(2), используемого для получения имен системы (компьютера, операционной системы, версии и т.д.)
<sys/wait.h> Содержит определения констант и прототипы системных вызовов wait(2), waitpid(2), используемых для синхронизации выполнения родственных процессов

Компиляция

Процедура создания большинства приложений является общей и приведена на рис. 2.2.

Рис. 2.2. Схема компиляции программы

Первой фазой является стадия компиляции, когда файлы с исходными текстами программы, включая файлы заголовков, обрабатываются компилятором cc(1). Параметры компиляции задаются либо с помощью файла makefile (или Makefile), либо явным указанием необходимых опций компилятора в командной строке. В итоге компилятор создает набор промежуточных объектных файлов. Традиционно имена созданных объектных файлов имеют суффикс ".o".

На следующей стадии эти файлы с помощью редактора связей ld(1) связываются друг с другом и с различными библиотеками, включая стандартную библиотеку по умолчанию и библиотеки, указанные пользователем в качестве параметров. При этом редактор связей может выполняться в двух режимах: статическом и динамическом, что задается соответствующими опциями. В статическом, наиболее традиционном режиме связываются все объектные модули и статические библиотеки (их имена имеют суффикс ".а"), производится разрешение всех внешних ссылок модулей и создается единый исполняемый файл, содержащий весь необходимый для выполнения код. Во втором случае, редактор связей по возможности подключает разделяемые библиотеки (имена этих библиотек имеют суффикс ".so"). В результате создается исполняемый файл, к которому в процессе запуска на выполнение будут подключены все разделяемые объекты. В обоих случаях по умолчанию создается исполняемый файл с именем a.out.

Для достаточно простых задач все фазы автоматически выполняются вызовом команды:

$ make prog

или эквивалентной ей

$ cc -о prog prog.c

которые создают исполняемый файл с именем prog. В этом случае умалчиваемое имя исполняемого файла (a.out) изменено на prog с помощью опции -о.

Впрочем, указанные стадии можно выполнять и раздельно, с использованием команд cc(1) и ld(1). Заметим, что на самом деле команда cc(1) является программной оболочкой и компилятора и редактора связей, которую и рекомендуется использовать при создании программ.

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

$ cc -с file1.c file2.c

$ cc -о prog

Создадим промежуточные объектные файлы file1.o и file2.o

$ cc -o prog file1.o file2.o -lnsl

Создадим исполняемый файл с именем prog, используя промежуточные объектные файлы и библиотеку libnsl.a или libnsl.so

Форматы исполняемых файлов

Виртуальная память процесса состоит из нескольких сегментов или областей памяти. Размер, содержимое и расположение сегментов в памяти определяется как самой программой, например, использованием библиотек, размером кода и данных, так и форматом исполняемого файла этой программы. В большинстве современных операционных систем UNIX используются два стандартных формата исполняемых файлов — COFF (Common Object File Format) и ELF (Executable and Linking Format).

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

□ Какие части программы необходимо загрузить в память?

□ Как создается область для неинициализированных данных?

□ Какие части процесса должны быть сохранены в дисковой области свопинга (специальной области дискового пространства, предназначенной для временного хранения фрагментов адресного пространства процесса), например, при замещении страниц, а какие могут быть при необходимости считаны из файла, и таким образом не требуют сохранения?

□ Где в памяти располагаются инструкции и данные программы?

□ Какие библиотеки необходимы для выполнения программы?

□ Как связаны исполняемый файл на диске, образ программы в памяти и дисковая область свопинга?

На рис. 2.3 приведена базовая структура памяти для процессов, загруженных из исполняемых файлов форматов COFF и ELF, соответственно. Хотя расположение сегментов различается для этих двух форматов, основные компоненты одни и те же. Оба процесса имеют сегменты кода (text), данных (data), стека (stack). Как видно из рисунка, размер сегментов данных и стека может изменяться, а направление этого изменения определяется форматом исполняемого файла. Размер стека автоматически изменяется операционной системой, в то время как управление размером сегмента данных производится самим приложением. Эти вопросы мы подробно обсудим в разделе "Выделение памяти" далее в этой главе.

Рис. 2.3. Исполняемые образы программ форматов COFF и ELF

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

Формат ELF

Формат ELF имеет файлы нескольких типов, которые до сих пор мы называли по-разному, например, исполняемый файл или объектный файл. Тем не менее стандарт ELF различает следующие типы:

1. Перемещаемый файл (relocatable file), хранящий инструкции и данные, которые могут быть связаны с другими объектными файлами. Результатом такого связывания может быть исполняемый файл или разделяемый объектный файл.

2. Разделяемый объектный файл (shared object file) также содержит инструкции и данные, но может быть использован двумя способами. В первом случае, он может быть связан с другими перемещаемыми файлами и разделяемыми объектными файлами, в результате будет создан новый объектный файл. Во втором случае, при запуске программы на выполнение операционная система может динамически связать его с исполняемым файлом программы, в результате чего будет создан исполняемый образ программы. В последнем случае речь идет о разделяемых библиотеках.

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

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

Рис. 2.4. Структура исполняемого файла в формате ELF

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

Поскольку заголовок ELF-файла определяет его структуру, рассмотрим его более подробно (табл. 2.4).


Таблица 2.3. Поля заголовка ELF-файла

Поле Описание
е_ident[] Массив байт, каждый из которых определяет некоторую общую характеристику файла: формат файла (ELF), номер версии, архитектуру системы (32-разрядная или 64-разрядная) и т.д.
e_type Тип файла, поскольку формат ELF поддерживает несколько типов
e_machine Архитектура аппаратной платформы, для которой создан данный файл. В табл. 2.4 приведены возможные значения этого поля
e_version Номер версии ELF-формата. Обычно определяется как EV_CURRENC (текущая), что означает последнюю версию
e_entry Виртуальный адрес, по которому системой будет передано управление после загрузки программы (точка входа)
e_phoff Расположение (смещение от начала файла) таблицы заголовков программы
е_shoff Расположение таблицы заголовков секций
е_ehsize Размер заголовка
e_phentsize Размер каждого заголовка программы
e_phnum Число заголовков программы
e_shentsize Размер каждого заголовка сегмента (секции)
е_shnum Число заголовков сегментов (секций)
e_shstrndx Расположение сегмента, содержащего таблицу строк

Таблица 2.4. Значения поля e_machine заголовка ELF-файла

Значение Аппаратная платформа
ЕМ_М32 AT&T WE 32100
ЕМ_SPARC Sun SPARC
ЕМ_386 Intel 80386
ЕМ_68K Motorola 68000
EM_88K Motorola 88000
ЕМ_486 Intel 80486
ЕМ_860 Intel i860
ЕМ_MIPS MIPS RS3000 Big-Endian
EM_MIPS_RS3_LE MIPS RS3000 Little-Endian
EM_RS6000 RS6000
EM_PA_RISC PA-RISC
EM_nCUBE nCUBE
EM_VPP500 Fujitsu VPP500
EM_SPARC32PLUS Sun SPARC 32+
Информация, содержащаяся в таблице заголовков программы, указывает ядру, как создать образ процесса из сегментов. Большинство сегментов копируются (отображаются) в память и представляют собой соответствующие сегменты процесса при его выполнении, например, сегменты кода или данных.

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

□ Тип сегмента и действия операционной системы с данным сегментом

□ Расположение сегмента в файле

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

□ Размер сегмента в файле

□ Размер сегмента в памяти

□ Флаги доступа к сегменту (запись, чтение, выполнение)

Часть сегментов имеет тип LOAD, предписывающий ядру при запуске программы на выполнение создать соответствующие этим сегментам структуры данных, называемые областями, определяющие непрерывные участки виртуальной памяти процесса и связанные с ними атрибуты. Сегмент, расположение которого в ELF-файле указано в соответствующем заголовке программы, будет отображен в созданную область, виртуальный адрес начала которой также указан в заголовке программы. К сегментам такого типа относятся, например, сегменты, содержащие инструкции программы (код) и ее данные. Если размер сегмента меньше размера области, неиспользованное пространство может быть заполнено нулями. Такой механизм, в частности используется при создании неинициализированных данных процесса (BSS). Подробнее об областях мы поговорим в главе 3.

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

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

Мы еще вернемся к формату ELF в главе 3 при обсуждении организации виртуальной памяти процесса, а пока перейдем к следующему распространенному формату — COFF.

Формат COFF

На рис. 2.5 приведена структура исполняемого файла формата COFF. Исполняемый файл содержит два основных заголовка — заголовок COFF и стандартный заголовок системы UNIX — a.out. Далее следуют заголовки разделов и сами разделы файла, в которых хранятся инструкции и данные программы. Наконец, в файле также хранится символьная информация, необходимая для отладки.

Рис. 2.5. Структура исполняемого файла в формате COFF

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

Символьная информация состоит из таблицы символов (symbol table) и таблицы строк (string table). В первой таблице хранятся символы, их адреса и типы. Например, мы можем определить, что символ locptr является указателем и его виртуальный адрес равен 0x7feh0. Далее, используя этот адрес, мы можем выяснить значение символа для выполняющегося процесса. Записи таблицы символов имеют фиксированный размер. Если длина символа превышает восемь знаков, его имя хранится во второй таблице — таблице строк. Обычно обе эти таблицы присутствуют в объектных и исполняемых файлах, если они явно не удалены, например, командой strip(1).

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


Таблица 2.5. Поля заголовка COFF-файла

Поле Описание
f_magic Аппаратная платформа, для которой создан файл
f_nscns Количество разделов в файле
f_timdat Время и дата создания файла
f_symptr Расположение таблицы символов в файле
f_nsyms Количество записей в таблице символов
f_opthdr Размер заголовка
f_flags Флаги, указывающие на тип файла, присутствие символьной информации и т.д.
Заголовок COFF присутствует в исполняемых файлах, промежуточных объектных файлах и библиотечных архивах. Каждый исполняемый файл кроме заголовка COFF содержит заголовок a.out, хранящий информацию, необходимую ядру системы для запуска программы[16] (табл. 2.6).


Таблица 2.6. Поля заголовка a.out

Поле Описание
vstamp Номер версии заголовка
tsize Размер раздела инструкций (text)
dsize Размер инициализированных данных (data)
bsize Размер неинициализированных данных (bss)
entry Точка входа программы
text_start Адрес в начала сегмента инструкций виртуальной памяти
data_start Адрес в начала сегмента данных виртуальной памяти
Все файлы формата COFF имеют один или более разделов, каждый из которых описывается своим заголовком. В заголовке хранится имя раздела (.text, .data, .bss или любое другое, установленное соответствующей директивой ассемблера), размер раздела, его расположение в файле и виртуальной адрес после запуска программы на выполнение. Заголовки разделов следуют сразу за заголовком файла.

Таблицы символов и строк являются основой системы отладки. Символом является любая переменная, имя функции или метка, определенные в программе.

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

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

Выполнение программы в операционной системе UNIX

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

Запуск C-программы

Функция main() является первой функцией, определенной пользователем (т. е. явно описанной в исходном тексте программы), которой будет передано управление после создания соответствующего окружения запускаемой на выполнение программы. Традиционно функция main() определяется следующим образом:

main(int argc, char *argv[], char *envp[]);

Первый аргумент (argc) определяет число параметров, переданных программе, включая ее имя.

Указатели на каждый из параметров передаются в массиве argv[], таким образом, через argv[0] адресуется строка, содержащая имя программы, argv[1] указывает на первый параметр и т.д.. до argv[argc-1].

Массив envp[] содержит указатели на переменные окружения, передаваемые программе. Каждая переменная представляет собой строку вида имя_переменной=значение_переменной. Мы уже познакомились с переменными окружения в главе 1, когда обсуждали командный интерпретатор. Сейчас же мы остановимся на их программной "анатомии".

Стандарт ANSI С определяет только два первых аргумента функции main()argc и argv. Стандарт POSIX.1 определяет также аргумент envp, хотя рекомендует передачу окружения программы производить через глобальную переменную environ, как это показано на рис. 2.6:

extern char *environ;

Рекомендуется следовать последнему формату передачи для лучшей переносимости программ на другие платформы UNIX.

Рис. 2.6. Передача переменных окружения

Приведем пример программы, соответствующую стандарту POSIX.1, которая выводит значения всех аргументов, переданных функции main(): число переданных параметров, сами параметры и значения первых десяти переменных окружения.

#include <stddef.h>


extern char **environ;


main(int argc, char *argv[]) {

 int i;

 printf("число параметров, переданных программе %s равно %d\n",

  argv[0], argc-1);

 for (i=1; i<argc; i++)

  if (environ[i] != NULL)

   printf("environ[%d] : %s\n", i, environ[i]);

}

В результате компиляции будет создан исполняемый файл программы (по умолчанию a.out). Запустив его, мы увидим следующую информацию:

$ a.out first second 3

число параметров, переданных программе a.out равно 3

argv[1] = first

argv[2] = second

argv[3] = 3

environ[0] : LOGNAME=andy

environ[1] : MAIL=/var/mail/andy

environ[2] : LD_LIBRARY_PATH=/usr/openwin/lib:/usr/ucblib

environ[3] : PAGER=/usr/bin/pg

environ[4] : TERM=vt100

environ[5] : PATH=/usr/bin:/bin:/etc:/usr/sbin:/sbin:/usr/ccs/bin:/usr/local/bin

environ[6] : HOME=/home/andy

environ[7] : SHELL=/usr/local/bin/bash

Максимальный объем памяти для хранения параметров и переменных окружения программы ограничен величиной ARG_MAX, определенной в файле <limits.h>. Это и другие системные ограничения могут быть получены с помощью функции sysconf(2).

Для получения и установки значений конкретных переменных окружения используются две функции: getenv(3C) и putenv(3C):

#include <stdlib.h>

char *getenv(const char *name);

возвращает значение переменной окружения name, a

int putenv(const char *string);

помещает переменную и ее значение (var_name=var_value) в окружение программы.

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

#include <stddef.h>

#include <stdlib.h>

#include <stdio.h>


main(int argc, char *argv[]) {

 char *term;

 char buf[200], var[200];

 /* Проверим, определена ли переменная TERM */

 if ((term = getenv("TERM")) == NULL)

  /* Если переменная не определена, получим от пользователя ее значение и

     поместим переменную в окружение программы */

 {

  printf("переменная TERM не определена, введите значение: ");

  putenv(var);

 } else

  /* Если переменная TERM определена, предоставим пользователю возможность

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

 {

  printf("TERM=%s. Change? [N]", getenv("TERM"));

  gets(buf);

  if (buf[0] == 'Y' || buf[0] == 'y') {

   printf("TERM=");

   gets{buf);

   sprintf(var, "TERM=%s", buf);

   putenv(var);

   printf("new %s\n", var);

  }

 }

}

Сначала программа проверяет, определена ли переменная TERM. Если переменная TERM не определена, пользователю предлагается ввести ее значение. Если же переменная TERM определена, пользователю предлагается изменить ее значение, после чего новое значение помещается в окружение программы.

Запуск этой программы приведет к следующим результатам:

$ а.out

TERM=ansi. Change? [N]y

TERM=vt100

new TERM=vt100

$

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

$ echo $TERM

ansi

$

Наследование окружения программы мы обсудим в разделе "Создание и управление процессами" далее в этой главе.

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

Обычно при запуске программы на выполнение из командной строки shell автоматически устанавливает для нее три стандартных потока ввода/вывода: для ввода данных, для вывода информации и для вывода сообщений об ошибках. Начальную ассоциацию этих потоков (их файловых дескрипторов) с конкретными устройствами производит терминальный сервер (в большинстве систем это процесс getty(1M)), который открывает специальный файл устройства, связанный с терминалом пользователя, и получает соответствующие дескрипторы. Эти потоки наследует командный интерпретатор shell и передает их запускаемой программе. При этом shell может изменить стандартные направления (по умолчанию все три потока связаны с терминалом пользователя), если пользователь указал на это с помощью специальных директив перенаправления потока (>, <, >>, <<) см. главу 1, раздел "Пользовательская среда UNIX"). Раздел "Группы и сеансы" внесет окончательную ясность в этот вопрос при описании управляющего терминала.

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

Завершая разговор о запуске программ, заметим, что при компиляции программы редактор связей устанавливает точку входа в программу, указывающую на библиотечную функцию _start(). Эта функция инициализирует процесс, создавая кадр стека, устанавливая значения переменных и, в конечном итоге, вызывая функцию main().

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

Существует несколько способов завершения программы. Основными являются возврат из функции main()[17] и вызов функций exit(2), оба приводят к завершению выполнения задачи. Заметим, что процесс может завершиться по не зависящим от него обстоятельствам, например, при получении сигнала, действие по умолчанию для большинства из которых приводит к завершению выполнения процесса[18] (см. раздел "Сигналы" далее в этой главе). В этом случае функция exit(2) будет вызвана ядром от имени процесса.

Системный вызов exit(2) выглядит следующим образом:

#include <unistd.h>


void exit(int status);

Аргумент status, передаваемый функции exit(2), возвращается родительскому процессу и представляет собой код возврата программы. По соглашению программа возвращает 0 в случае успеха и другую величину в случае неудачи. Значение кода неудачи может иметь дополнительную трактовку, определяемую самой программой. Например, программа grep(1), выполняющая поиск заданных подстрок в файлах, определяет следующие коды возврата:

0 совпадение было найдено
1 совпадений найдено не было
2 синтаксическая ошибка или недоступны файлы поиска
Наличие кода возврата позволяет программам взаимодействовать друг с другом. Например, следующая программа (назовем ее fail) может являться условием неудачи и использоваться в соответствующих синтаксических конструкциях shell:

main() {

 exit(1);

}

$ fail

$ echo $?           Выведем код возврата программы fail

1

$ fail || echo fail Конструкция shell, использующая условие неудачи fail

fail

Помимо передачи кода возврата, функция exit(2) производит ряд действий, в частности выводит буферизованные данные и закрывает потоки ввода/вывода. Альтернативой ей является функция _exit(2), которая не производит вызовов библиотеки ввода/вывода, а сразу вызывает системную функцию завершения ядра. Более подробно о процедурах завершения процесса см. раздел "Создание и управление процессами".

Задача может зарегистрировать обработчики выхода (exit handler), — функции, которые вызываются после вызова exit(2), но до окончательного завершения процесса. Эти обработчики, вызываемые по принципу LIFO (последний зарегистрированный обработчик будет вызван первым), запускаются только при "добровольном" завершении процесса. Например, при получении процессом сигнала обработчики выхода вызываться не будут. Для обработки таких ситуаций следует использовать специальные функции — обработчики сигналов (см. раздел "Сигналы" далее в этой главе).

Обработчики выхода регистрируются с помощью функции atexit(3C):

#include <stdlib.h>


int atexit(void(*func)(void));

Функцией atexit(1) может быть зарегистрировано до 32 обработчиков.

На рис. 2.7 проиллюстрированы возможные варианты запуска и завершения программы, написанной на языке С.

Рис. 2.7. Запуск и завершение C-программы

Работа с файлами

В среде программирования UNIX существуют два основных интерфейса для файлового ввода/вывода:

1. Интерфейс системных вызовов, предлагающий системные функции низкого уровня, непосредственно взаимодействующие с ядром операционной системы.

2. Стандартная библиотека ввода/вывода, предлагающая функции буферизованного ввода/вывода.

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

В следующих разделах будут рассмотрены:

□ оба интерфейса, и особенно первый, поскольку именно он представляет набор базовых услуг ядра;

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

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

□ метаданные файла;

□ пример программы, выводящей на экран наиболее существенную информацию о файле, подобно тому, как это делает утилита ls(1).

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

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

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


Таблица 2.7. Основные системные функции работы с файлами

Системная функция Описание
open(2) Служит для получения доступа на чтение и/или запись к указанному файлу. Если файл существует, он открывается, и процессу возвращается файловый дескриптор, адресующий дальнейшие операции с файлом. Если файл не существует, он может быть создан
creat(2) Служит для создания файла
close(2) Закрывает файловый дескриптор, связанный с предварительно открытым файлом
dup(2) Возвращает дубликат файлового дескриптора
dup2(2) Возвращает дубликат файлового дескриптора, но позволяет явно указать его значение
lseek(2) Устанавливает файловый указатель на определенное место файла. Дальнейшие операции чтения/записи будут производиться, начиная с этого смещения
read (2) Производит чтение указанного количества байтов из файла
readv(2) Производит несколько операций чтения указанного количества байтов из файла
write(2) Производит запись указанного количества байтов в файл
writev(2) Производит несколько операций записи указанного количества байтов в файл
pipe(2) Создает коммуникационный канал, возвращая два файловых дескриптора
fcntl(2) Обеспечивает интерфейс управления открытым файлом
Кратко рассмотрим каждую из этих функций.

Функция open(2)

Открывает указанный файл для чтения или записи и имеет следующий вид:

#include <fcntl.h>


int open(const char *path, int oflag, mode_t mode);

Первый аргумент (path) является указателем на имя файла. Это имя может быть как абсолютным (начинающимся с корневого каталога /), так и относительным (указанным относительно текущего каталога). Аргумент oflag указывает на режим открытия файла и представляет собой побитное объединение флагов, приведенных в табл. 2.8, с помощью операции ИЛИ. Напомним, что если права доступа к файлу не разрешают указанного режима работы с файлом, операция открытия файла будет запрещена, и функция open(2) завершится с ошибкой (errno=EACCESS). Аргумент mode, определяющий права доступа к файлу, используется только при создании файла (как показано в табл. 2,8, функция open(2) может использоваться и для создания файла) и рассматривается при описании функции creat(2) в разделе "Права доступа" этой главы.


Таблица 2.8. Флаги, определяющие режим открытия файла

Флаг Описание
O_RDONLY Открыть файл только для чтения
O_WRONLY Открыть файл только для записи
O_RDWR Открыть файл для чтения и записи
O_APPEND Производить добавление в файл, т.е. устанавливать файловый указатель на конец файла перед каждой записью в файл
O_CREAT Если указанный файл уже существует, этот флаг не принимается во внимание. В противном случае, создается файл, атрибуты которого установлены по умолчанию (см. разделы "Владельцы файлов" и "Права доступа к файлу" в главе 1), или с помощью аргумента mode
O_EXCL Если указан совместно с O_CREAT, то вызов open(2) завершится с ошибкой, если файл уже существует
O_NOCTTY Если указанный файл представляет собой терминал, не позволяет ему стать управляющим терминалом
O_SYNC Все записи в файл, а также соответствующие им изменения в метаданных файла будут сохранены на диске до возврата из вызова write(2)
O_TRUNC Если файл существует и является обычным файлом, его длина будет установлена равной 0
O_NONBLOCK Изменяет режим выполнения операций read(2) и write(2) для этого файла на неблокируемый. При невозможности произвести запись или чтение, например, если отсутствуют данные, соответствующие вызовы завершатся с ошибкой EAGAIN
Если операция открытия файла закончилась удачно, то будет возвращен файловый дескриптор — указатель на файл, использующийся в последующих операциях чтения, записи и т.д. Значение файлового дескриптора определяется минимальным свободным слотом в таблице дескрипторов процесса. Так, если дескрипторы 0 и 2 уже заняты (указывают на открытые файлы), вызов open(2) возвратит значение 1. Это свойство может быть использовано в коде командного интерпретатора при перенаправлении потоков ввода-вывода.

$ runme >/home/andrei/run.log

Фрагмент кода

...

/* Закроем ассоциацию стандартного потока вывода (1)

   с файлом (терминалом) */

close(1);

/* Назначим стандартный поток вывода в файл /home/andrei/run.log.

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

   на его получение. */

fd = open("/home/andrei/run.log",

 O_WRONLY | O_CREATE | O_TRUNC);

...

В случае неудачи open(1) возвратит -1, а глобальная переменная errno будет содержать код ошибки (см. раздел "Обработка ошибок").

Заметим, что только один из флагов O_RDONLY, O_WRONLY и O_RDWR может быть указан в аргументе oflag.

Флаг O_SYNC гарантирует, что данные, записанные в файл и связанные с операцией записи изменения метаданных файла, будут сохранены на диске до возврата из функции write(2). Ядро кэширует данные, считываемые или записываемые на дисковое устройство, для ускорения этих операций. Обычно запись данных в файл ограничивается записью в буферный кэш ядра операционной системы, данные из которого впоследствии записываются на диск. По умолчанию возврат из функции write(2) происходит после записи в буферный кэш, не дожидаясь записи данных на диск. Более подробно работу буферного кэша мы рассмотрим в главе 4.

Флаг O_NONBLOCK изменяет стандартное поведение функций чтения/записи файла. При указании этого флага возврат из функций read(2) и write(2) будет происходить немедленно с кодом ошибки и установленным значением errno = EAGAIN, если ядро не может передать данные при чтении, например, ввиду их отсутствия, или процессу требуется перейти в состояние сна при записи данных.

Функция creat(2)

Функция служит для создания обычного файла или изменения его атрибутов и имеет следующий вид:

#include <fcntl.h>


int creat(const char *path, mode_t mode);

Как и в случае open(2), аргумент path определяет имя файла в файловой системе, a mode — устанавливаемые права доступа к файлу. При этом выполняется ряд правил:

□ Если идентификатор группы (GID) создаваемого файла не совпадает с эффективным идентификатором группы (EGID) или идентификатором одной из дополнительных групп процесса, бит SGID аргумента mode очищается (если он был установлен).

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

□ Очищается флаг Sticky bit.

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

Если файл уже существует, его длина сокращается до 0, а права доступа и владельцы сохраняются прежними. Вызов creat(2) эквивалентен следующему вызову функции open(2):

open(path, O_WRONLY | O_CREAT | O_TRUNC, mode);

Функция close(2)

Функция close(2) разрывает связь между файловым дескриптором и открытым файлом, созданную функциями creat(2), open(2), dup(2), pipe(2) или fcntl(2). Функция имеет вид:

#include <unistd.h>


int close(int fildes);

В случае успеха close(2) возвращает нулевое значение, в противном случае возвращается -1, а значение переменной errno указывает на причину неудачи.

Многие программы явно не используют close(2) при завершении выполнения. Дело в том, что функция exit(2), вызываемая явно или неявно при завершении выполнения программы, автоматически закрывает открытые файлы.

Функции dup(2) и dup2(2)

Функция dup(2) используется для дублирования существующего файлового дескриптора:

int dup(int fildes);

Файловый дескриптор fildes должен быть предварительно получен с помощью функций open(2), creat(2), dup(2), dup2(2) или pipe(2). В случае успешного завершения функции dup(2) возвращается новый файловый дескриптор, свойства которого идентичны свойствам дескриптора fildes. Оба указывают на один и тот же файл, одно и то же смещение, начиная с которого будет производиться следующая операция чтения или записи (файловый указатель), и определяют один и тот же режим работы с файлом. Правило размещения нового файлового дескриптора аналогично используемому в функции open(2).

Функция dup2(2) делает то же самое, однако позволяет указать номер файлового дескриптора, который требуется получить после дублирования:

int dup2(int fildes, int fildes2);

Файловый дескриптор, подлежащий дублированию, передается в первом аргументе (fildes), а новый дескриптор должен быть равен fildes2. Если дескриптор fildes2 уже занят, сначала выполняется функция close(fildes2).

В качестве примера использования системного вызова dup2(2) рассмотрим вариант реализации слияния потоков в командном интерпретаторе shell:

$ runme >/tmp/file1 2>&1

Фрагмент кода

...

/* Закроем ассоциацию стандартного потока вывода (1)

   с файлом (терминалом) */

close(1);

/* Назначим стандартный поток вывода в файл

   /tmp/file1 (fd==1) */

fd = open("/tmp/file1", O_WRONLY | O_CREAT | O_TRUNC);

/* Выполним слияние потоков */

dup2(fd, 2);

...

Функция lseek(2)

С файловым дескриптором связан файловый указатель, определяющий текущее смещение в файле, начиная с которого будет произведена последующая операция чтения или записи. В свою очередь каждая операция чтения или записи увеличивают значение файлового указателя на число считанных или записанных байт. При открытии файла, файловый указатель устанавливается равным 0 или, если указан флаг O_APPEND, равным размеру файла. С помощью функции lseek(2) можно установить файловый указатель на любое место файла и тем самым обеспечить прямой доступ к любой части файла. Функция имеет следующий вид:

#include <unistd.h>

off_t lseek(int fildes, off_t offset, int whence);

Интерпретация аргумента offset зависит от аргумента whence, который может принимать следующие значения:

SEEK_CUR Указатель смещается на offset байт от текущего положения
SEEK_END Указатель смещается на offset байт от конца файла
SEEK_SET Указатель устанавливается равным offset
В случае успеха функция возвращает положительное целое, равное текущему значению файлового указателя.

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

Функция read(2) и readv(2)

Функции read(2) и readv(2) позволяют считывать данные из файла, на который указывает файловый дескриптор, полученный с помощью функций open(2), creat(2), dup(2), dup2(2), pipe(2) или fcntl(2). Функции имеют следующий вид:

#include <unistd.h>


ssize_t read(int fildes, void *buf, size_t nbyte);


#include <sys/types.h>

#include <sys/uio.h>


ssize_t readv(int fildes, struct iovec *iov, int iovcnt);

Аргументы, передаваемые функции read(2), указывают, что следует считать nbyte байт из файла, связанного с дескриптором fildes, начиная с текущего значения файлового указателя. Считанные данные помещаются в буфер приложения, указатель на который передается в аргументе buf. После завершения операции значение файлового указателя будет увеличено на nbyte.

Функция readv(2) позволяет выполнить iovcnt последовательных операций чтения за одно обращение к readv(2). Аргумент iov указывает на массив структур, каждый элемент которого имеет вид:

struct {

 void *iov_base; Указатель на начало буфера

 size_t iov_len; Размер буфера

} iovec;

Функция readv(2) считывает данные из файла и последовательно размещает их в нескольких буферах, определенных массивом iov. Такой характер работы, проиллюстрированный на рис. 2.8, получил название scatter read (от scatter (англ.) — разбрасывать). Общее число считанных байт в нормальной ситуации равно сумме размеров указанных буферов.

Рис. 2.8. Чтение файла с использованием нескольких буферов

Функции write(2) и writev(2)

Функции write(2) и writev(2) очень похожи на функции read(2) и readv(2), но используются для записи данных в файл. Функции имеют следующий вид:

#include <unistd.>


ssize_t write(int fildes, void *buf, size_t nbyte);


#include <sys/types.h>

#include <sys/uio.h>


ssize_t writev(int fildes, struct iovec *iov, int iovcnt);

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

Аналогично функции readv(2), функция writev(2) позволяет выполнить iovcnt последовательных операций записи за одно обращение к writev(2).

Такая операция ввода/вывода получила название gather (собирать), а функции ввода/вывода, использующие набор буферов, — общее название scatter-gather.

Функция pipe(2)

Функция pipe(2) служит для создания однонаправленного (симплексного) канала (также называемого анонимным каналом) обмена данными между двумя родственными процессами. Дело в том, что только родственные процессы (например, родительский и дочерний) имеют возможность получить доступ к одному и тому же каналу. Этот аспект станет более понятным в ходе обсуждения в разделе "Создание и управление процессами" далее в этой главе. Функция имеет вид:

#include <unistd.h>


int pipe(int fildes[2]);

Функция возвращает два файловых дескриптора в массиве fildes[], причем fildes[0] служит для чтения данных из канала, a fildes[1] — для записи данных в канал.

Каналы являются одним из способов организации межпроцессного взаимодействия и будут подробно рассмотрены в главе 3. В качестве примера использования pipe(2) можно привести возможность командного интерпретатора — создание программных каналов, рассмотренное в главе 1.

Отметим, что буферизация данных в канале стандартно осуществляется путем выделения дискового пространства в структуре файловой системы. Таким образом, чтение и запись в канал связаны с дисковым вводом/выводом, что, безусловно, сказывается на производительности этого механизма. Современные операционные системы наряду с более совершенными средствами межпроцессного взаимодействия предлагают и более эффективные механизмы каналов. Так, например, SCO UNIX (OpenServer 5.0) обеспечивает работу каналов через специальную файловую систему — HPPS (High Performance Pipe System). С помощью HPPS данные буферизуются в оперативной памяти, что существенно ускоряет операции записи и чтения.

Функция fcntl(2)

После открытия файла и получения ссылки на него в виде файлового дескриптора процесс может производить различные файловые операции. Функция fcntl(2) позволяет процессу выполнить ряд действий с файлом, используя его дескриптор, передаваемый в качестве первого аргумента:

#include <fcntl.h>


int fcntl (int fildes, int cmd, ...);

Функция fcntl(2) выполняет действие cmd с файлом, а возможный третий аргумент зависит от конкретного действия:

F_DUPFD Разместить новый файловый дескриптор, значение которого больше или равно значению третьего аргумента. Новый файловый дескриптор будет указывать на тот же открытый файл, что и fildes. Действие аналогично вызову функции dup(2) или dup2(2): fddup = fcntl(fd, F_DUPFD, fildes2)
F_GETFD Возвратить признак сохранения дескриптора при запуске новой программы (выполнении системного вызова exec(2)) — флаг close-on-exec (FD_CLOEXEC). Если флаг установлен, то при вызове exec(2) файл, ассоциированный с данным дескриптором, будет закрыт
F_SETFD Установить флаг close-on-exec согласно значению, заданному третьим аргументом
F_GETFL Возвратить режим доступа к файлу, ассоциированному с данным дескриптором. Флаги, установленные в возвращаемом значении, полностью соответствуют режимам открытия файла, задаваемым функции open(2). Их значения приведены в табл. 2.8. Рассмотрим пример: oflags = fcntl(fd, F_GETFL, 0); /* Выделим биты, определяющие режим доступа */ accbits = oflags & O_ACCMODE; if (accbits == O_RDONLY) printf("Файл открыт только для чтения\n"); else if (accbits == O_WRONLY) printf("Файл открыт только для записи\n"); else if (accbits == O_RDWR) printf("Файл открыт для чтения и записи\n");
F_SETFL Установить режим доступа к файлу согласно значению, переданному в третьем аргументе. Могут быть изменены только флаги O_APPEND, O_NONBLOCK, O_SYNC и O_ASYNC.
F_GETLK Проверить существование блокирования записи файла. Блокирование записи, подлежащее проверке, описывается структурой flock, указатель на которую передается в качестве третьего аргумента. Если существующие установки не позволяют выполнить блокирование, определенное структурой flock, последняя будет возвращена с описанием текущего блокирования записи. Данная команда не устанавливает блокирование, а служит для проверки его возможности. Более подробно блокирование записей описано в главе 4, в разделе "Блокирование доступа к файлу".
F_SETLK Установить блокирование записи файла. Структура flock описывает блокирование, и указатель на нее передается в качестве третьего аргумента. При невозможности блокирования fcntl(2) возвращается С ошибкой EACCESS или EAGAIN.
F_SETLKW Аналогично предыдущему, но при невозможности блокирования по причине уже существующих блокировок, процесс переходит в состояние сна, ожидая, пока последние будут освобождены. Последняя буква W в названии действия означает wait (ждать).

Стандартная библиотека ввода/вывода

Функции, которые мы только что рассмотрели представляют интерфейс ввода/вывода между приложениями и ядром операционной системы. Хотя их использование напоминает использование библиотечных функций С, по существу они представляют собой лишь "обертки" к функциям ядра UNIX, фактически выполняющим операции ввода/вывода.

Однако программисты редко используют этот интерфейс низкого уровня, предпочитая возможности, предоставляемые стандартной библиотекой ввода/вывода. Функции этой библиотеки обеспечивают буферизованный ввод/вывод и более удобный стиль программирования. Для использования функций этой библиотеки в программу должен быть включен файл заголовков <stdio.h>. Эти функции входят в стандартную библиотеку С (libc.so или libc.a), которая, как правило, подключается по умолчанию на этапе связывания.

Вместо использования файлового дескриптора библиотека определяет указатель на специальную структуру данных (структура FILE), называемый потоком или файловым указателем. Стандартные потоки ввода/вывода обозначаются символическими именами stdin, stdout, stderr соответственно для потоков ввода, вывода и сообщений об ошибках. Они определены следующим образом:

extern FILE *stdin;

extern FILE *stdout;

extern FILE *stderr;

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


Таблица 2.9. Стандартные потоки и их дескрипторы

Файловый дескриптор Поток (указатель) Описание
0 stdin Стандартный ввод
1 stdout Стандартный вывод
2 stderr Сообщения об ошибках

Таблица 2.10. Наиболее употребительные функции стандартной библиотеки ввода/вывода

Функция Назначение
fopen(3S) Открывает файл с указанным именем и возвращает файловый указатель, ассоциированный с данным файлом
fclose(3S) Закрывает поток, освобождая буферы
fflush(3S) Очищает буфер потока, открытого на запись
getc(3S) Считывает символ из потока
putc(3S) Записывает символ в поток
gets(3S) Считывает строку из потока
puts(3S) Записывает строку в поток
fread(3S) Считывает указанное число байтов из потока (бинарный ввод)
fwrite(3S) Записывает указанное число байтов в поток (бинарный вывод)
fseek(3S) Позиционирует указатель в потоке
printf(3S) Производит форматированный вывод
scanf(3S) Производит форматированный ввод
fileno(3S) Возвращает файловый дескриптор данного потока
Выбор между функциями интерфейса системных вызовов и стандартной библиотеки зависит от многих факторов, в частности, степени контроля ввода/вывода, переносимости программы, простоты. Взгляните, например, на следующие эквивалентные строки программы:

write (1, "Здравствуй, Мир!\n", 16);

printf("Здравствуй, Мир!\n");

В первой строке сообщение выводится с использованием системной функции write(2), во второй — с помощью библиотечной функции printf(3S). Помимо того, что второй вариант кажется более лаконичным, отметим еще ряд особенностей. В первом варианте пришлось сделать предположение о том, что файловый дескриптор стандартного вывода равен 1, что может оказаться несправедливым для некоторых систем. Также пришлось явно указать число символов в строке, т.к. write(2) не делает никаких предположений о формате вывода, трактуя его как последовательность байтов. В отличие от wite(2), printf(3S) распознает строки, представляющие собой последовательность символов, заканчивающихся нулем. Функция printf(3S) также позволяет отформатировать выводимые данные для представления их в требуемом виде.

Но основным достоинством функций библиотеки является буферизация ввода/вывода, позволяющая минимизировать число системных вызовов read(2) и write(2). При открытии файла и создании потока функции библиотеки автоматически размещают необходимые буферы, позволяя приложению не заботиться о них.

Библиотека предоставляет три типа буферизации:

□ Полная буферизация. В этом случае операция чтения или записи завершается после того, как будет заполнен буфер ввода/вывода. Ввод/вывод для дисковых файлов, как правило, полностью буферизуется. Буфер размещается с помощью функции malloc(3C) при первом обращении к потоку для чтения или записи и заполняется системными вызовами read(2) или write(2). Это означает, что последующие вызовы getc(3S), gets(3S), putc(3S), puts(3S) и т.д. не инициируют обращений к системным функциям, а будут производить чтение или запись из буфера библиотеки. Содержимое буфера очищается (т.е. данные сохраняются на диске) автоматически, либо при вызове функции fflush(3S).

□ Построчная буферизация. В этом случае библиотека выполняет фактический ввод/вывод (т.е. производит системные вызовы read(2) или write(2)) построчно при обнаружении конца строки (символа перевода каретки). Такой тип буферизации обычно используется для ассоциированных с терминальными устройствами потоков, которыми, как правило являются стандартные потоки ввода и вывода.

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

Характер буферизации может быть изменен с помощью функций:

#include <stdio.h>


void setbuf(FILE *stream, char *buf);

int setvbuf(FILE *stream, char *buf, int type, size_t size);

Функция setbuf(3S) позволяет включить или отключить буферизацию для потока stream. В первом случае buf должен указывать на буфер размером BUFSIZ, во втором его значение должно быть равно NULL.

Функция setvbuf(3S) позволяет производить более тонкое управление буферизацией, явно указывая, какой ее тип мы хотим установить. Для этого используется аргумент type, который может принимать следующие значения:

_IOFBF Полная буферизация
_IOLBF Построчная буферизация
_IONBF Отсутствие буферизации
В случае полной или построчной буферизации аргумент size определяет размер буфера, адресованного указателем buf.

Каждый поток стандартной библиотеки представлен указателем на структуру FILE, показанную на рис. 2.9, в которой хранится указатель на буфер _base, указатель на следующий символ, подлежащий чтению или записи _ptr, число байт в буфере _cnt, указатель на файловый дескриптор _file, с которым ассоциирован данный поток, а также флаги состояния потока _flag. При создании буфера библиотека выбирает оптимальный размер для данного потока. Обычно этот размер равен значению поля st_blksize структуры stat, возвращаемой системным вызовом stat(2), рассмотренный в разделе "Метаданные файла" этой главы. Если определить оптимальный размер невозможно, например для каналов или специальных файлов устройств, выбирается стандартное значение BUFSIZ, определенное в файле <stdio.h>.

Рис. 2.9. Структуры данных потока


Связи

В метаданных каждого файла файловой системы UNIX хранится число связей, определяющее количество имен, которое имеет данный файл. Например, файлы /etc/init.d/lp (или /etc/lp), /etc/rc0.d/K201p, /etc/rc2.d/K201p и /etc/rc2.d/S801p имеют различные имена, но ссылаются на один и тот же физический файл (точнее, метаданные файла) и тем самым обеспечивают доступ к одним и тем же данным. В данном случае число связей файла равно 4. Каждый раз, когда одно из имен файла удаляется, число связей соответственно уменьшается. Когда оно достигнет нуля — данные файла будут удалены. Такой тип связи называется жесткой.

Жесткая связь создается с помощью системного вызова link(2):

#include <unistd.h>


int link(const char *existing, const char *new);

При этом будет образована новая запись каталога с именем new и номером inode указывающим на метаданные файла existing. Также будет увеличено число связей. Этим системным вызовом, в частности, пользуется команда ln(1), рассмотренная в главе 1.

Для удаления жесткой связи используется системный вызов unlink(2):

#include <unistd.h>


int unlink(const char *path);

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

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

Символическая связь позволяет косвенно адресовать другой файл файловой системы. Системный вызов symlink(2) служит для создания символической связи. Этим вызовом, кстати, пользуется команда ln -s.

#include <unistd.h>


int symlink (const char *name, const char *synmame);

После создания символической связи, доступ к целевому файлу name может осуществляться с помощью symname. При этом, функция open(2), принимая в качестве аргумента имя символической связи, на самом деле открывает целевой файл. Такая особенность называется следованием символической связи. Не все системные вызовы обладают этим свойством. Например, системный вызов unlink(2), удаляющий запись в каталоге, действует только на саму символическую связь. В противном случае, мы не имели бы возможности удалить ее. В табл. 2.11 показано, как работают с символическими связями различные системные вызовы.


Таблица 2.11. Интерпретация символической связи различными системными вызовами

Системный вызов Следует символической связи Не следует символической связи
access(2) +
chdir(2) +
chmod(2) +
chown(2) +
lchown(2) +
creat(2) +
exec(2) +
link(2) +
mkdir(2) +
mknod(2) +
open(2) +
readlink(2) +
rename(2) +
stat(2) +
lstat(2) +
unlink(2) +
Для чтения содержимого файла — символической связи используется системный вызов readlink(2):

#include <unistd.h>


int readlink(const char *path, void *buf, size_t bufsiz);

Аргумент path содержит имя символической связи. В буфере buf размером bufsiz возвращается содержимое файла — символической связи.

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

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <stdio.h>


#define BUFSZ 256


/* В качестве аргумента программа принимает имя

   символической связи */

main(int argc, char *argv[]) {

 char buf[BUFSZ+1];

 int nread, fd;

 /* Прочитаем содержимое самой символической связи */

 printf("Читаем символическую связь\n");

 nread = readlink(argv[1], buf, BUFSZ);

 if (nread < 0) {

  perror("readlink");

  exit(1);

 }

 /* readlink не завершает строку '\0' */

 printf("Символическая связь:\n %s\n", buf);

 /* Теперь прочитаем содержимое целевого файла */

 printf("Читаем целевой файл\n");

 fd = open(argv[1], O_RDONLY);

 if (fd < 0) {

  perror("open");

  exit(2);

 }

 nread = read(fd, buf, BUFSIZ);

 if (nread < 0) {

  perror("read");

  exit(3);

 }

 buf[nread] = '\0';

 printf("Целевой файл:\n %s\n", buf);

 close(fd);

 exit(0);

}

Перед тем как запустить программу, создадим символическую связь с файлом unix0.txt:

$ ln -s unix0.txt symlink.txt

$ ls -l

lrwxrwxrwx 1 andy user  10 Jan 6 09:54 symlink.txt -> unix0.txt

-rw-r--r-- 1 andy user 498 Jan 6 09:53 unix0.txt

$ a.out symlink.txt

Читаем символическую связь

Символическая связь:

unix0.txt

Читаем целевой файл

Целевой файл:

Начиная с 1975 года фирма AT&T начала предоставлять лицензии на

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

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

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

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

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

популярности микропроцессоров

...

Файлы, отображаемые в памяти

Системный вызов mmap(2) предоставляет механизм доступа к файлам, альтернативный вызовам read(2) и write(2). С помощью этого вызова процесс имеет возможность отобразить участки файла в собственное адресное пространство. После этого данные файла могут быть получены или записаны путем чтения или записи в память. Функция mmap(2) определяется следующим образом:

#include <sys/types.h>

#include <sys/mman.h>


caddr_t mmap(caddr_t addr, size_t len, int prot,

 int flags, int fildes, off_t off);

Этот вызов задает отображение len байтов файла с дескриптором fildes, начиная со смещения off, в область памяти со стартовым адресом addr. Разумеется, перед вызовом mmap(2) файл должен быть открыт с помощью функции open(2). Аргумент prot определяет права доступа к области памяти, которые должны соответствовать правам доступа к файлу, указанным в системном вызове open(2). В табл. 2.12 приведены возможные значения аргумента prot и соответствующие им права доступа к файлу. Возможно логическое объединение отдельных значений prot. Так значение PROT_READ | PROT_WRITE соответствует доступу O_RDWR к файлу.


Таблица 2.12. Права доступа к области памяти

Значение аргумента prot Описание Права доступа к файлу
PROT_READ Область доступна для чтения r
PROT_WRITE Область доступна для записи w
PROT_EXEC Область доступна для исполнения x
PROT_NONE Область недоступна -
Обычно значение addr задается равным 0, что позволяет операционной системе самостоятельно выбрать виртуальный адрес начала области отображения. В любом случае, при успешном завершении возвращаемое системным вызовом значение определяет действительное расположение области памяти.

Операционная система округляет значение len до следующей страницы виртуальной памяти.[19] Например, если размер файла 96 байтов, а размер страницы 4 Кбайт, то система все равно выделит область памяти размером 4096 байтов. При этом 96 байтов займут собственно данные файла, а остальные 4000 байтов будут заполнены нулями. Процесс может модифицировать и оставшиеся 4000 байтов, но эти изменения не отразятся на содержимом файла. При обращении к участку памяти, лежащему за пределами файла, ядро отправит процессу сигнал SIGBUS[20]. Несмотря на то что область памяти может превышать фактический размер файла, процесс не имеет возможности изменить его размер.

Использование права на исполнение (prot = PROT_EXEC) позволяет процессу определить собственный механизм загрузки кода. В частности, такой подход используется редактором динамических связей при загрузке динамических библиотек, когда библиотека отображается в адресное пространство процесса. Значение PROT_NONE позволяет приложению определить собственные механизмы контроля доступа к разделяемым объектам (например, к разделяемой памяти), разрешая или запрещая доступ к области памяти.

Аргумент flags определяет дополнительные особенности управления областью памяти. В табл. 2.13 приведены возможные типы отображения, определяемые аргументом flags.


Таблица 2.13. Типы отображения

Значение аргумента flags Описание
MAP SHARED Область памяти может совместно использоваться несколькими процессами
MAP PRIVATE Область памяти используется только вызывающим процессом
MAP_FIXED Требует выделения памяти, начиная точно с адреса addr
MAP_NORESERVE He требует резервирования области свопинга
В случае указания MAP_PRIVATE, для процесса, определившего этот тип отображения, будет создана собственная копия страницы памяти, которую он пытается модифицировать. Заметим, что копия будет создана только при вызове операции записи, до этого остальные процессы, определившие тип отображения как MAP_SHARED могут совместно использовать одну и ту же область памяти.

Не рекомендуется использовать флаг MAP_FIXED, т.к. это не позволяет системе максимально эффективно распределить память. В случае отсутствия этого флага, ядро пытается выделить область памяти, начиная с адреса наиболее близкого к значению addr. Если же значение addr установлено равным 0, операционная система получает полную свободу в размещении области отображения.

Отображение автоматически снимается при завершении процесса. Процесс также может явно снять отображение с помощью вызова munmap(2). Закрытие файла не приводит к снятию отображения. Следует отметить, что снятие отображения непосредственно не влияет на отображаемый файл, т. е. содержимое страниц области отображения не будет немедленно записано на диск. Обновление файла производится ядром согласно алгоритмам управления виртуальной памятью. В то же время в ряде систем существует функция msync(3C), которая позволяет синхронизировать обновление памяти с обновлением файла на диске.[21]

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

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/mman.h>

#include <unistd.h>

#include <fcntl.h>


main(int argc, char *argv[]) {

 int fd_src, fd_dst;

 caddr_t addr_src, addr_dst;

 struct stat filestat;

 /* Первый аргумент - исходный файл, второй - целевой */

 fd_dst=open(argv[2], O_RDWR | O_CREAT);

 /* Определим размер исходного файла */

 fstat(fd_src, &filestat);

 /* Сделаем размер целевого файла равным исходному */

 lseek(fd_dst, filestat.st_size - 1, SEEK_SET);

 /* Зададим отображение */

 addr_src=mmap((caddr_t)0, filestat.st_size,

  PROT_READ, MAP_SHARED, fd_src, 0);

 addr_dst=mmap((caddr_t)0, filestat.st_size,

  PROT_READ | PROT_WRITE, MAP_SHARED, fd_dst, 0);

 /* Копируем области памяти */

 memcpy(addr_dst, addr_src, filestat.st_size);

 exit(0);

}

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

Владение файлами

Владелец-пользователь и владелец-группа файла могут быть изменены с помощью системных вызовов chown(2), fchown(2) и lchown(2):

#include <unistd.h>

#include <sys/types.h>


int chown(const char *path, uid_t owner, gid_t group);

int fchown(int fildes, uid_t owner, gid_t group);

int lchown(const char *path, uid_t owner, gid_t group);

Все три вызова работают одинаково за исключением ситуации, когда адресуемый файл является символической связью. В последнем случае вызов lchown(2) действует на сам файл — символическую связь, а не на целевой файл (т.е. не следует символической связи). В функциях chown(2) и lchown(2) файл адресуется по имени, а в fchown(2) — по файловому дескриптору. Если значение owner или group установлено равным -1, соответствующий владелец файла не изменяется.

В версиях BSD UNIX только суперпользователь может изменить владение файлом. Это ограничение призвано, в первую очередь, не допустить "скрытие" файлов под именем другого пользователя, например, при установке квотирования ресурсов файловой системы. Владельца-группу можно изменить только для файлов, которыми вы владеете, причем им может стать одна из групп, членом которой вы являетесь. Эти же ограничения определены и стандартом POSIX.1.

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

В случае успешного изменения владельцев файла биты SUID и SGID сбрасываются, если процесс, вызвавший chown(2) не обладает правами суперпользователя.

Права доступа

Как уже обсуждалось в предыдущей главе, каждый процесс имеет четыре пользовательских идентификатора — UID, GID, EUID и EGID. В то время как UID и GID определяют реального владельца процесса, EUID и EGID определяют права доступа процесса к файлам в процессе выполнения. В общем случае реальные и эффективные идентификаторы эквивалентны. Это значит, что процесс имеет те же привилегии, что и пользователь, запустивший его. Однако, как уже обсуждалось выше, возникают ситуации, когда процесс должен получить дополнительные привилегии, чаще всего — привилегии суперпользователя. Это достигается установкой битов SUID и SGID. Примером такого процесса может служить утилита passwd(1), изменяющая пароль пользователя.

Права доступа к файлу могут быть изменены с помощью системных вызовов chmod(2) и fchmod(2):

#include <sys/types.h>

#include <sys/stat.h>


int chmod(const char *path, mode_t mode);

int fchmod(int fildes, mode_t mode);

Значение аргумента mode определяет устанавливаемые права доступа и дополнительные атрибуты (такие как SUID, SGID и Sticky bit), и создается путем логического объединения различных флагов, представленных в табл. 2.14. Вторая колонка таблицы содержит восьмеричные значения для девяти битов прав доступа (чтение, запись и выполнение для трех классов доступа) и трех битов дополнительных атрибутов.


Таблица 2.14. Флаги аргумента mode

Флаг Биты Значение
S_ISUID 04000 Установить бит SUID
S_ISGID 020#0 Установить бит SGID, если # равно 7, 5, 3 или 1. Установить обязательное блокирование файла, если # равно 6, 4, 2 или 0
S_ISVTX 01000 Установить Sticky bit
S_IRWXU 00700 Установить право на чтение, запись и выполнение для владельца-пользователя
S_IRUSR 00400 Установить право на чтение для владельца-пользователя
S_IWUSR 00200 Установить право на запись для владельца-пользователя
S_IXUSR 00100 Установить право на выполнение для владельца-пользователя
S_IRWXG 00070 Установить право на чтение, запись и выполнение для владельца-группы
S_IRGRP 00040 Установить право на чтение для владельца-группы
S_IWGRP 00020 Установить право на запись для владельца-группы
S_IXGRP 00010 Установить право на выполнение для владельца-группы
S_IRWXO 00007 Установить право на чтение, запись и выполнение для остальных пользователей
S_IROTH 00004 Установить право на чтение для остальных пользователей
S_IWOTH 00002 Установить право на запись для остальных пользователей
S_IXOTH 00001 Установить право на выполнение для остальных пользователей
Некоторые флаги, представленные в таблице, уже являются объединением нескольких флагов. Так, например, флаг S_RWXU эквивалентен S_IRUSR | S_IWUSR | S_IXUSR. Значение флага S_ISGID зависит от того, установлено или нет право на выполнение для группы (S_IXGRP). В первом случае, он будет означать установку SGID, а во втором — обязательное блокирование файла.

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

#include <sys/types.h>

#include <sys/stat.h>

#include <stdlib.h>


main() {

 int fd;

 /* Создадим файл с правами rwx------ */

 fd = creat("my_file", S_IRUSR | S_IWUSR | S_IXUSR);

 system("ls -l my_file");

 /*Добавим флаг SUID */

 fchmod(fd, S_IRWXU | S_ISUID);

 /* Установим блокирование записей файла */

 fchmod(fd, S_IRWXU | S_ISUID | S_ISGID);

 system("ls -l my_file");

 /* Теперь установим флаг SGID */

 fchmod(fd, S_IRWXU | S_ISUID | S_ISGID | S_IXGRP);

 system("ls -l my_file");

}

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

$ a.out

-rwx------ 1 andy user 0 Jan 6 19:28 my_file

-rws------ 1 andy user 0 Jan 6 19:28 my_file

-rws--1--- 1 andy user 0 Jan 6 19:28 my_file

-rws--s--- 1 andy user 0 Jan 6 19:28 my_file

Перемещение по файловой системе

Каждый процесс имеет два атрибута, связанных с файловой системой — корневой каталог (root directory) и текущий рабочий каталог (current working directory). Когда некоторый файл адресуется по имени (например, в системных вызовах open(2), creat(2) или readlink(2)), ядро системы производит поиск файла, начиная с корневого каталога, если имя файла задано как абсолютное, либо текущего каталога, если имя файла является относительным. Абсолютное имя файла начинается с символа '/', обозначающего корневой каталог. Все остальные имена файлов являются относительными. Например, имя /usr/bin/sh является абсолютным, в то время как mydir/test1.c или ../andy/mydir/test1.c — относительным, при котором фактическое расположение файла в файловой системе зависит от текущего каталога.

Процесс может изменить свой корневой каталог с помощью системного вызова chroot(2) или fchroot(2).

#include <unistd.h>


int chroot (const char *path);

int fchroot(int fildes);

После этого поиск всех адресуемых файлов с абсолютными именами будет производиться, начиная с нового каталога, указанного аргументом path. Например, после изменения корневого каталога на домашний каталог пользователя абсолютное имя инициализационного скрипта .profile станет /.profile.[22]

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

Процесс также может изменить и текущий каталог. Для этого используются системные вызовы chdir(2) или fchdir(2):

#include <unistd.h>


int chdir(const char* path);

int fchdir(int fildes);

Например, внутренняя команда командного интерпретатора cd может быть реализована следующим кодом:

...

char newdir[PATH_MAX];

...

/* Предположим, что имя нового каталога,

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

   в переменной newdir*/

if (chdir(newdir) == -1) perror("sh: cd");

...

Метаданные файла

Как уже говорилось, каждый файл помимо собственно данных содержит метаданные, описывающие его характеристики, например, владельцев, права доступа, тип и размер файла, а также содержащие указатели на фактическое расположение данных файла. Метаданные файла хранятся в структуре inode. Часть полей этой структуры могут быть получены с помощью системных вызовов stat(2):

#include <sys/types.h>

#include <sys/stat.h>


int stat(const char *path, struct stat *buf);

int lstat (const char *path, struct stat *buf);

int fstat(int fildes, struct stat *buf);

В качестве аргумента функции принимают имя файла или файловый дескриптор (fstat(2)) и возвращают заполненные поля структуры stat, которые приведены в табл. 2.15.


Таблица 2.15. Поля структуры stat

Поле Значение
mode_t st_mode Тип файла и права доступа
ino_t st_ino Номер inode. Поля st_ino и st_dev однозначно определяют обычные файлы
dev_t st_dev Номер устройства, на котором расположен файл (номер устройства файловой системы)
dev_t st_rdev Для специального файла устройства содержит номер устройства, адресуемого этим файлом
nlink_t st_link Число жестких связей
uid_t st_uid Идентификатор пользователя-владельца файла
gid_t st_gid Идентификатор группы-владельца файла
off_t st_size Размер файла в байтах. Для специальных файлов устройств это поле не определено
time_t st_atime Время последнего доступа к файлу
time_t st_mtime Время последней модификации данных файла
time_t st_ctime Время последней модификации метаданных файла
long st_blksize Оптимальный размер блока для операций ввода/вывода. Для специальных файлов устройств и каналов это поле не определено
long st_blocks Число размещенных 512-байтовых блоков хранения данных. Для специальных файлов устройств это поле не определено
Для определения типа файла служат следующие макроопределения, описанные в файле <sys/stat.h>:


Таблица 2.16. Определение типа файла

Макроопределение Тип файла
S_ISFIFO(mode) FIFO
S_ISCHR(mode) Специальный файл символьного устройства
S_ISDIR(mode) Каталог
S_ISBLK(mode) Специальный файл блочного устройства
S_ISREG(mode) Обычный файл
S_ISLNK(mode) Символическая связь
S_ISSOCK(mode) Сокет
Все значения времени, связанные с файлом (время доступа, модификации данных и метаданных) хранятся в секундах, прошедших с 0 часов 1 января 1970 года. Заметим, что информация о времени создания файла отсутствует.

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

#include <sys/types.h>

#include <sys/stat.h>

#include <time.h>


main(int argc, char *argv[]) {

 struct stat s;

 char* ptype;

 lstat(argv[1] , &s); /* Определим тип файла */

 if (S_ISREG(s.st_mode)) ptype = "Обычный файл";

 else if (S_ISDIR(s.st_mode)) ptype = "Каталог";

 else if (S_ISLNK(s.st_mode)) ptype = "Симв. Связь";

 else if (S_ISCHR(s.st_mode)) ptype = "Симв. Устройство";

 else if (S_ISBLK(s.st_mode)) ptype = "Бл.устройство";

 else if (S_ISSOCK(s.st_mode)) ptype = "Сокет";

 else if (S_ISFIFO(s.st_mode)) ptype = "FIFO";

 else ptype = "Неизвестный тип";

 /* Выведем информацию о файле */

 /* Его тип */

 printf("type = %s\n", ptype);

 /* Права доступа */

 printf("perm =%o\n", s.st_mode & S_IAMB);

 /* Номер inode */

 printf("inode = %d\n", s.st_ino);

 /* Число связей */

 printf("nlink = %d\n", s.st_nlink);

 /* Устройство, на котором хранятся данные файла */

 printf("dev = (%d, %d)\n", major(s.st_dev), minor(s.st_dev));

 /* Владельцы файла */

 printf("UID = %d\n", s.st_uid);

 printf("GID = %d\n", s.st_gid);

 /* Для специальных файлов устройств - номера устройства */

 printf("rdev = (%d, %d)\n", major(s.st_rdev),

 minor(s.st_rdev));

 /* Размер файла */

 printf("size = %d\n", s.st_size);

 /* Время доступа, модификации и модификации метаданных */

 printf("atime = %s", ctime(&s.st_atime));

 printf("mtime = %s", ctime(&s.st_mtime));

 printf("ctime = %s", ctime(&s.st_ctime));

}

Программа использует библиотечные функции major(3C) и minor(3C), возвращающие, соответственно, старший и младший номера устройства. Функция ctime(3C) преобразует системное время в удобный формат.

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

$ а.out ftype.c

type = Обычный файл

perm = 644

inode = 13

nlink = 1

dev = (1, 42)

UID = 286

GID = 100

rdev = (0, 0)

size = 1064

atime = Wed Jan 8 17:25:34 1997

mtime = Wed Jan 8 17:19:27 1997

ctime = Wed Jan 8 17:19:27 1997

$ ls -il /tmp/ftype.c

13 -rw-r--r-- 1 andy user 1064 Jan 8 17:19 ftype.c

Процессы

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

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

В этом разделе рассматриваются:

□ Идентификаторы процесса

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

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

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

□ Группы и сеансы; взаимодействие процесса с пользователем.

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

Идентификаторы процесса

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

Однако нельзя не отметить еще четыре идентификатора, играющие решающую роль при доступе к системным ресурсам: идентификатор пользователя UID, эффективный идентификатор пользователя EUID, идентификатор группы GID и эффективный идентификатор группы EGID. Эти идентификаторы определяют права процесса в файловой системе, и как следствие, в операционной системе в целом. Запуская различные команды и утилиты, можно заметить, что порожденные этими командами процессы полностью отражают права пользователя UNIX. Причина проста — все процессы, которые запускаются, имеют идентификатор пользователя и идентификатор группы. Исключение составляют процессы с установленными флагами SUID и SGID.

При регистрации пользователя в системе утилита login(1) запускает командный интерпретатор, — login shell, имя которого является одним из атрибутов пользователя. При этом идентификаторам UID (EUID) и GID (EGID) процесса shell присваиваются значения, полученные из записи пользователя в файле паролей /etc/passwd. Таким образом, командный интерпретатор обладает правами, определенными для данного пользователя.

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

Казалось бы, эту стройную систему могут "испортить" утилиты с установленными флагами SUID и SGID. Но не стоит волноваться — как правило, такие программы не позволяют порождать другие процессы, в противном случае, эти утилиты необходимо немедленно уничтожить!

На рис. 2.10. показан процесс наследования пользовательских идентификаторов в рамках одного сеанса работы.

Рис. 2.10. Наследование пользовательских идентификаторов

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

#include <sys/types.h>

#include <unistd.h>


uid_t getuid(void);

uid_t geteuid(void);

gid_t getgid(void);

gid_t getegid(void);

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

Процесс также может изменить значения этих идентификаторов с помощью системных вызовов:

#include <sys/types.h>

#include <unistd.h>


int setuid(uid_t uid);

int setegid(gid_t egid);

int seteuid(uid_t euid);

int setgid(gid_t gid);

Системные вызовы setuid(2) и setgid(2) устанавливают сразу реальный и эффективный идентификаторы, а системные вызовы seteuid(2) и setegid(2) — только эффективные.

Ниже приведен фрагмент программы login(1), изменяющей идентификаторы процесса на значения, полученные из записи файла паролей. В стандартной библиотеке имеется ряд функций работы с записями файла паролей, каждая из которых описывается структурой passwd, определенной в файле <pwd.h>. Поля этой структуры приведены в табл. 2.17.


Таблица 2.17. Поля структуры passwd

Поле Значение
char *pw_name Имя пользователя
char *pw_passwd Строка, содержащая пароль в зашифрованном виде; из соображения безопасности в большинстве систем пароль хранится в файле /etc/shadow, а это поле не используется
uid_t pw_uid Идентификатор пользователя
gid_t pw_gid Идентификатор группы
char *pw_gecos Комментарий (поле GECOS), обычно реальное имя пользователя и дополнительная информация
char *pw_dir Домашний каталог пользователя
char *pw_shell Командный интерпретатор
Функция, которая потребуется для нашего примера, позволяет получить запись файла паролей по имени пользователя. Она имеет следующий вид:

#include <pwd.h>

struct passwd *getpwnam(const char *name);

Итак, перейдем к фрагменту программы:

...

struct passwd *pw;

char logname[MAXNAME];

/* Массив аргументов при запуске

   командного интерпретатора */

char *arg[MAXARG];

/* Окружение командного интерпретатора */

char *envir[MAXENV];

...

/* Проведем поиск записи пользователя с именем logname,

   которое было введено на приглашение "login:" */

pw = getpwnam(logname);

/* Если пользователь с таким именем не найден, повторить

   приглашение */

if (pw == 0)

 retry();

 /* В противном случае установим идентификаторы процесса

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

    командный интерпретатор */

else {

 setuid(pw->pw_uid);

 setgid(pw->pw_gid);

 execve(pw->pw_shell, arg, envir);

}

...

Вызов execve(2) запускает на выполнение программу, указанную в первом аргументе. Мы рассмотрим эту функцию в разделе "Создание и управление процессами" далее в этой главе.

Выделение памяти

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

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

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

char ptype = "Unknown file type";

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

2. Значение глобальной переменной неизвестно на этапе компиляции, например:

char ptype[32];

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

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

func1() {

 int a;

 char *b;

 static int с = 4;

 ...

}

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

4. Выделение памяти явно запрашивается некоторыми системными вызовами или библиотечными функциями. Например, функция malloc(3C) запрашивает выделение дополнительной памяти, которая в дальнейшем используется для динамического размещения данных. Функция ctime(3C), предоставляющая системное время в удобном формате, также требует выделения памяти для размещения строки, содержащей значения текущего времени, указатель на которую возвращается программе.

Напомним, что дополнительная память выделяется из хипа (heap) — области виртуальной памяти, расположенной рядом с сегментом данных, размер которой меняется для удовлетворения запросов на размещение. Следующий за сегментом данных адрес называется разделительным или брейк-адресом (break address). Изменение размера сегмента данных по существу заключается в изменении брейк-адреса. Для изменения его значения UNIX предоставляет процессу два системных вызова — brk(2) и sbrk(2).

#include <unistd.h>


int brk(void *endds);

void *sbrk(int incr);

Системный вызов brk(2) позволяет установить значение брейк-адреса равным endds и, в зависимости от его значения, выделяет или освобождает память (рис. 2.11). Функция sbrk(2) изменяет значение брейк-адреса на величину incr. Если значение incr больше 0, происходит выделение памяти, в противном случае, память освобождается.[23]


Рис 2.11. Динамическое выделение памяти с помощью brk(2)

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

#include <stdlib.h>


void *malloc(size_t size);

void *calloc(size_t nelem, size_t elsize);

void *realloc(void *ptr, size_t size);

void free(void *ptr);

Функция malloc(3C) выделяет указанное аргументом size число байтов.

Функция calloc(3C) выделяет память для указанного аргументом nelem числа объектов, размер которых elsize. Выделенная память инициализируется нулями.

Функция realloc(3C) изменяет размер предварительно выделенной области памяти (увеличивает или уменьшает, в зависимости от знака аргумента size). Увеличение размера может привести к перемещению всей области в другое место виртуальной памяти, где имеется необходимое свободное непрерывное виртуальное адресное пространство.

Функция free(3C) освобождает память, предварительно выделенную с помощью функций malloc(3C), calloc(3C) или realloc(3C), указатель на которую передается через аргумент ptr.

Указатель, возвращаемый функциями malloc(3C), calloc(3C) и realloc(3C), соответствующим образом выровнен, таким образом выделенная память пригодна для хранения объектов любых типов. Например, если наиболее жестким требованием по выравниванию в системе является размещение переменных типа double по адресам, кратным 8, то это требование будет распространено на все указатели, возвращаемыми этими функциями.

Упомянутые библиотечные функции обычно используют системные вызовы sbrk(2) или brk(2). Хотя эти системные вызовы позволяют как выделять, так и освобождать память, в случае библиотечных функций память реально не освобождается, даже при вызове free(3C). Правда, с помощью функций malloc(3C), calloc(3C) или realloc(3C) можно снова выделить и использовать эту память и снова освободить ее, но она не передается обратно ядру, а остается в пуле malloc(3C).

Для иллюстрации этого положения приведем небольшую программу, выделяющую и освобождающую память с помощью функций malloc(3C) и free(3C), соответственно. Контроль действительного значения брейк-адреса осуществляется с помощью системного вызова sbrk(2):

#include <unistd.h>

#include <stdlib.h>


main() {

 char *obrk;

 char *nbrk;

 char *naddr;

 /* Определим текущий брейк-адрес */

 obrk = sbrk(0);

 printf("Текущий брейк-адрес= 0x%x\n", obrk);

 /* Выделим 64 байта из хипа */

 naddr = malloc(64);

 /* Определим новый брейк-адрес */

 nbrk = sbrk(0);

 printf("Новый адрес области malloc= 0x%x,"

  " брейк-адрес= 0х%x (увеличение на %d байтов)\n",

  naddr, nbrk, nbrk — obrk);

 /* "Освободим" выделенную память и проверим, что произошло

    на самом деле */

 free(naddr);

 printf("free(0x%x)\n", naddr);

 obrk = sbrk(0);

 printf("Новый брейк-адрес= 0x%x (увеличение на %d байтов)\n",

  obrk, obrk — nbrk);

}

Откомпилируем и запустим программу:

$ a.out

Текущий брейк-адрес= 0x20ac0

malloc(64)

Новый адрес области malloc = 0x20ac8, брейк-адрес = 0x22ac0

(увеличение на 8192 байтов)

free(0x20ac8)

Новый брейк-адрес = 0x22ac0 (увеличение на 0 байтов)

$

Как видно из вывода программы, несмотря на освобождение памяти функцией free(3C), значение брейк-адреса не изменилось. Также можно заметить, что функция malloc(3C) выделяет больше памяти, чем требуется. Дополнительная память выделяется для необходимого выравнивания и для хранения внутренних данных malloc(3C), таких как размер области, указатель на следующую область и т.п.

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

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

Новый процесс порождается с помощью системного вызова fork(2):

#include <sys/types.h>

#include <unistd.h>


pid_t fork(void);

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

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

□ переменные окружения,

□ диспозицию сигналов и их обработчики,

□ ограничения, накладываемые на процесс,

□ текущий и корневой каталог,

□ маску создания файлов,

□ все файловые дескрипторы, включая файловые указатели,

□ управляющий терминал.

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

Легче перечислить немногочисленные различия между этими процессами, а именно:

□ дочернему процессу присваивается уникальный идентификатор PID.

□ идентификаторы родительского процесса PPID у этих процессов различны,

□ дочерний процесс свободен от сигналов, ожидающих доставки,

□ значение, возвращаемое системным вызовом fork(2) различно для родителя и потомка.

Последнее замечание требует объяснения. Как уже говорилось, возврат из функции fork(2) происходит как в родительский, так и в дочерний процесс. При этом возвращаемое родителю значение равно PID дочернего процесса, а дочерний, в свою очередь, получает значение, равное 0. Если fork(2) возвращает -1, то это свидетельствует об ошибке (естественно, в этом случае возврат происходит только в процесс, выполнивший системный вызов).

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

main() {

 int pid;

 pid = fork();

 if (pid == -1) {

  perror("fork");

  exit(1);

 }

 if (pid == 0) {

  /* Эта часть кода выполняется дочерним процессом */

  printf("Потомок\n");

 } else {

  /* Эта часть кода выполняется родительским процессом */

  printf("Родитель\n");

 }

}

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

UNIX предлагает системный вызов, предназначенный исключительно для запуска программ, т.е. загрузки другого исполняемого файла. Это системный вызов exec(2), представленный на программном уровне несколькими модификациями:

#include <unistd.h>


int execl(const char *path, const char *arg0, ... ,

 const char *argn, char * /* NULL */);

int execv(const char* path, char* const argv[]);

int execle(const char *path, char *const arg0[], ... ,

 const char *argn, char* /* NULL */, char *const envp[]);

int execve(const char* path, char const argv[],

 char *const envp[]);

int execlp(const char *file, const char *arg0, ... ,

 const char* argn, char * /* NULL */);

int execvp(const char *file, char *const argv[]);

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

Рис. 2.12. Семейство функций exec(2)

В отличие от вызова fork(2), новая программа наследует меньше атрибутов. В частности, наследуются:

□ идентификаторы процесса PID и PPID,

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

□ эффективные идентификаторы пользователя и группы (в случае, если для исполняемого файла не установлен флаг SUID или SGID),

□ ограничения, накладываемые на процесс,

□ текущий и корневой каталоги,

□ маска создания файлов,

□ управляющий терминал,

□ файловые дескрипторы, для которых не установлен флаг FD_CLOEXEC.

Наследование характеристик процесса играет существенную роль в работе операционной системы. Так наследование идентификаторов владельцев процесса гарантирует преемственность привилегий и, таким образом, неизменность привилегий пользователя при работе в UNIX. Наследование файловых дескрипторов позволяет установить направления ввода/вывода для нового процесса или новой программы. Именно так действует командный интерпретатор. Мы вернемся к вопросу о наследовании в главе 3.

В главе 1 уже говорилось о частом объединении вызовов fork(2) и exec(2), получившем специальное название fork-and-exec. Таким образом загружается подавляющее большинство программ, которые выполняются в системе.

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

Операционная система предоставляет процессу ряд функций, позволяющих ему контролировать выполнение потомков. Это функции wait(2), waitid(2) и waitpid(2):

#include <sys/types.h>

#include <sys/wait.h>


pid_t wait(int* stat_loc);

int waitpid(idtype_t idtype, id_t id,

siginfo_t * infop, int options);

pid_t waitpid(pid_t pid, int *stat_loc, int options);

Первый из этих вызовов wait(2) обладает самой ограниченной функциональностью — он позволяет заблокировать выполнение процесса, пока кто-либо из его непосредственных потомков не прекратит существование. Вызов wait(2) немедленно возвратит состояние уже завершившегося дочернего процесса в переменной stat_loc, если последний находится в состоянии зомби. Значение stat_loc может быть проанализировано с помощью следующих макроопределений:

WIFEXITED(status) Возвращает истинное (ненулевое) значение, если процесс завершился нормально.
WEXITSTATUS(status) Если WIFEXITED(status) не равно нулю, определяет код возврата завершившегося процесса (аргумент функции exit(2)).
WIFSIGNALLED(status) Возвращает истину, если процесс завершился по сигналу.
WTERMSIG(status) Если WIFSIGNALLED(status) не равно нулю, определяет номер сигнала, вызвавшего завершение выполнения процесса.
WCOREDUMP(status) Если WIFSIGNALLED(status) не равно нулю, макрос возвращает истину в случае создания файла core.
Системный вызов waitid(2) предоставляет больше возможностей для контроля дочернего процесса. Аргументы idtype и id определяют, за какими из дочерних процессов требуется следить:

Значение аргумента idtype Описание
P_PID waitid(2) блокирует выполнение процесса, следя за потомком, PID которого равен id.
P_PGID waitid(2) блокирует выполнение процесса, следя за потомками, идентификаторы группы которых равны id.
P_ALL waitid(2) блокирует выполнение процесса, следя за всеми непосредственными потомками.
Аргумент options содержит флаги, объединенные логическим ИЛИ, определяющие, за какими изменениями в состоянии потомков следит waitid(2):

Флаги аргумента options Описание
WEXITED Предписывает ожидать завершения выполнения процесса.
WTRAPPED Предписывает ожидать ловушки (trap) или точки останова (breakpoint) для трассируемых процессов.
WSTOPPED Предписывает ожидать останова процесса из-за получения сигнала.
WCONTINUED Предписывает вернуть статус процесса, выполнение которого было продолжено после останова.
WNOHANG Предписывает завершить свое выполнение, если отсутствует статусная информация (т.е. отсутствует ожидаемое событие).
WNOWAIT Предписывает получить статусную информацию, но не уничтожать ее, оставив дочерний процесс в состоянии ожидания.
Аргумент infop указывает на структуру siginfo_t, которая будет заполнена информацией о потомке. Мы рассмотрим эту структуру в следующем разделе.

Функция waitpid(2), как и функции wait(2) и waitid(2), позволяет контролировать определенное множество дочерних процессов.

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

...

/* Вывести приглашение shell*/

write(1, "$ ", 2);

/* Считать пользовательский ввод */

get_input(inputbuf);

/* Произвести разбор ввода: выделить команду cmd

   и ее аргументы arg[] */

parse_input(inputbuf, and, arg);

/* Породить процесс */

pid = fork();

if (pid == 0) {

 /* Запустить программу */

 execvp(cmd, arg);

 /* При нормальном запуске программы эта часть кода

    выполняться уже не будет — можно смело выводить

    сообщение об ошибке */

 pexit(cmd);

} else

 /* Родительский процесс (shell) ожидает завершения

    выполнения потомка */

 wait(&status);

...

Сигналы

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

Сигналы появились уже в ранних версиях UNIX, но их реализация не была достаточно надежной. Сигнал мог быть "потерян", возникали также определенные сложности с отключением (блокированием) сигналов на время выполнения критических участков кода. В последующие версии системы, как BSD, так и System V, были внесены изменения, позволившие реализовать надежные (reliable) сигналы. Однако модель сигналов, принятая в версиях BSD, была несовместима с моделью версий System V. В настоящее время стандарт POSIX.1 вносит определенность в интерфейс надежных сигналов.

Прежде всего, каждый сигнал имеет уникальное символьное имя и соответствующий ему номер. Например, сигнал прерывания, посылаемый процессу при нажатии пользователем клавиши <Del> или <Ctrl>+<C>, имеет имя SIGINT. Сигнал, генерируемый комбинацией <Ctrl>+<\>, называется SIGQUIT. Седьмая редакция UNIX насчитывала 15 различных сигналов, а в современных версиях их число увеличилось вдвое.

Сигнал может быть отправлен процессу либо ядром, либо другим процессом с помощью системного вызова kill(2):

#include <sys/types.h>

#include <signal.h>


int kill(pid_t pid, int sig);

Аргумент pid адресует процесс, которому посылается сигнал. Аргумент sig определяет тип отправляемого сигнала.

К генерации сигнала могут привести различные ситуации:

□ Ядро отправляет процессу (или группе процессов) сигнал при нажатии пользователем определенных клавиш или их комбинаций. Например, нажатие клавиши <Del> (или <Ctrl>+<C>) приведет к отправке сигнала SIGINT, что используется для завершения процессов, вышедших из-под контроля.[24]

□ Аппаратные особые ситуации, например, деление на 0, обращение к недопустимой области памяти и т.д., также вызывают генерацию сигнала. Обычно эти ситуации определяются аппаратурой компьютера, и ядру посылается соответствующее уведомление (например, в виде прерывания). Ядро реагирует на это отправкой соответствующего сигнала процессу, который находился в стадии выполнения, когда произошла особая ситуация.

□ Определенные программные состояния системы или ее компонентов также могут вызвать отправку сигнала. В отличие от предыдущего случая, эти условия не связаны с аппаратной частью, а имеют чисто программный характер. В качестве примера можно привести сигнал SIGALRM, отправляемый процессу, когда срабатывает таймер, ранее установленный с помощью вызова alarm(2).

С помощью системного вызова kill(2) процесс может послать сигнал как самому себе, так и другому процессу или группе процессов. В этом случае процесс, посылающий сигнал, должен иметь те же реальный и эффективный идентификаторы, что и процесс, которому сигнал отправляется. Разумеется, данное ограничение не распространяется на процессы, обладающие привилегиями суперпользователя. Такие процессы имеют возможность отправлять сигналы любым процессам системы.

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

□ игнорировать сигнал,

□ перехватить и самостоятельно обработать

□ позволить действие по умолчанию.

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

Напомним, что сигналы SIGKILL и SIGSTOP невозможно ни игнорировать, ни перехватить. Сигнал SIGKILL является силовым методом завершения выполнения "непослушного" процесса, а от работоспособности SIGSTOP зависит функционирование системы управления заданиями.

Условия генерации сигнала и действие системы по умолчанию приведены в табл. 2.18. Как видно из таблицы, при получении сигнала в большинстве случаев по умолчанию происходит завершение выполнения процесса. В ряде случаев в текущем рабочем каталоге процесса также создается файл core (в таблице такие случаи отмечены как "Завершить+core"), в котором хранится образ памяти процесса. Этот файл может быть впоследствии проанализирован программой-отладчиком для определения состояния процесса непосредственно перед завершением. Файл core не будет создан в следующих случаях:

□ исполняемый файл процесса имеет установленный бит SUID, и реальный владелец-пользователь процесса не является владельцем- пользователем исполняемого файла;

□ исполняемый файл процесса имеет установленный бит SGID, и реальный владелец-группа процесса не является владельцем-группой исполняемого файла;

□ процесс не имеет права записи в текущем рабочем каталоге;

□ размер файла core слишком велик (превышает допустимый предел RLIMIT_CORE, см. раздел "Ограничения" далее в этой главе).


Таблица 2.18. Сигналы

Название Действие по умолчанию Значение
SIGABRT Завершить+core Сигнал отправляется, если процесс вызывает системный вызов abort(2).
SIGALRM Завершить Сигнал отправляется, когда срабатывает таймер, ранее установленный с помощью системных вызовов alarm(2) или setitimer(2).
SIGBUS Завершить+core Сигнал свидетельствует о некоторой аппаратной ошибке. Обычно этот сигнал отправляется при обращении к допустимому виртуальному адресу, для которого отсутствует соответствующая физическая страница. Другой случай генерации этого сигнала упоминался при обсуждении файлов, отображаемых в память (сигнал отправляется процессу при попытке обращения к странице виртуальной памяти, лежащей за пределами файла).
SIGCHLD Игнорировать Сигнал, посылаемый родительскому процессу при завершении выполнения его потомка.
SIGEGV Завершить+core Сигнал свидетельствует о попытке обращения к недопустимому адресу или к области памяти, для которой у процесса недостаточно привилегий.
SIGFPE Завершить+core Сигнал свидетельствует о возникновении особых ситуаций, таких как деление на 0 или переполнение операции с плавающей точкой.
SIGHUP Завершить Сигнал посылается лидеру сеанса, связанному с управляющим терминалом, когда ядро обнаруживает, что терминал отсоединился (потеря линии). Сигнал также посылается всем процессам текущей группы при завершении выполнения лидера. Этот сигнал иногда используется в качестве простейшего средства межпроцессного взаимодействия. В частности, он применяется для сообщения демонам о необходимости обновить конфигурационную информацию. Причина выбора именно сигнала SIGHUP заключается в том, что демон по определению не имеет управляющего терминала и, соответственно, обычно не получает этого сигнала.
SIGILL Завершить+core Сигнал посылается ядром, если процесс попытался выполнить недопустимую инструкцию.
SIGINT Завершить Сигнал посылается ядром всем процессам текущей группы при нажатии клавиши прерывания (<Del> или <Ctrl>+<C>).
SIGKILL Завершить Сигнал, при получении которого выполнение процесса завершается. Этот сигнал нельзя ни перехватить, ни игнорировать.
SIGPIPE Завершить Сигнал посылается при попытке записи в канал или сокет, получатель данных которого завершил выполнение (закрыл соответствующий дескриптор).
SIGPOLL Завершить Сигнал отправляется при наступлении определенного события для устройства, которое является опрашиваемым.
SIGPWR Игнорировать Сигнал генерируется при угрозе потери питания. Обычно он отправляется, когда питание системы переключается на источник бесперебойного питания (UPS).
SIGQUIT Завершить+core Сигнал посылается ядром всем процессам текущей группы при нажатии клавиш <Ctrl>+<\>.
SIGSTOP Остановить Сигнал отправляется всем процессам текущей группы при нажатии пользователем клавиш <Ctrl>+<Z>. Получение сигнала вызывает останов выполнения процесса.
SIGSYS Завершить+core Сигнал отправляется ядром при попытке недопустимого системного вызова.
SIGTERM Завершить Сигнал обычно представляет своего рода предупреждение, что процесс вскоре будет уничтожен. Этот сигнал позволяет процессу соответствующим образом "подготовиться к смерти" — удалить временные файлы, завершить необходимые транзакции и т.д. Команда kill(1) по умолчанию отправляет именно этот сигнал.
SIGTTIN Остановить Сигнал генерируется ядром (драйвером терминала) при попытке процесса фоновой группы осуществить чтение с управляющего терминала.
SIGTTOU Остановить Сигнал генерируется ядром (драйвером терминала) при попытке процесса фоновой группы осуществить запись на управляющий терминал.
SIGUSR1 Завершить Сигнал предназначен для прикладных задач как простейшее средство межпроцессного взаимодействия.
SIGUSR2 Завершить Сигнал предназначен для прикладных задач как простейшее средство межпроцессного взаимодействия.
Простейшим интерфейсом к сигналам UNIX является устаревшая, но по-прежнему поддерживаемая в большинстве систем функция signal(3C). Эта функция позволяет изменить диспозицию сигнала, которая по умолчанию устанавливается ядром UNIX. Порожденный вызовом fork(2) процесс наследует диспозицию сигналов от своего родителя. Однако при вызове exec(2) диспозиция всех перехватываемых сигналов будет установлена на действие по умолчанию. Это вполне естественно, поскольку образ новой программы не содержит функции-обработчика, определенной диспозицией сигнала перед вызовом exec(2). Функция signal(3C) имеет следующее определение:

#include <signal.h>

void(*signal(int sig, void (*disp)(int)))(int);

Аргумент sig определяет сигнал, диспозицию которого нужно изменить.

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

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

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

#include <signal.h>


/* Функция-обработчик сигнала */

static void sig_hndlr(int signo) {

 /* Восстановим диспозицию */

 signal(SIGINT, sig_hndlr);

 printf("Получен сигнал SIGINT\n");

}


main() {

 /* Установим диспозицию */

 signal(SIGINT, sih_hndlr);

 signal(SIGUSR1, SIG_DFL);

 signal(SIGUSR2, SIG_IGN);

 /* Бесконечный цикл */

 while(1)

  pause();

}

В этом примере изменена диспозиция трех сигналов: SIGINT, SIGUSR1 и SIGUSR2. При получении сигнала SIGINT вызывается обработчик при получении сигнала SIGUSR1 производится действие по умолчанию (процесс завершает работу), а сигнал SIGUSR2 игнорируется. После установки диспозиции сигналов процесс запускает бесконечный цикл, в процессе которого вызывается функция pause(2). При получении сигнала, который не игнорируется, pause(2) возвращает значение -1, а переменная errno устанавливается равной EINTR. Заметим, что каждый раз при получении сигнала SIGINT мы вынуждены восстанавливать требуемую диспозицию, в противном случае получение следующего сигнала этого типа вызвало бы завершение выполнения процесса (действие по умолчанию).

При запуске программы, получим следующий результат:

$ а.out &

[1] 8365              PID порожденного процесса

$ kill -SIGINT 8365

Получен сигнал SIGINT Сигнал SIGINT перехвачен

$ kill -SIGUSR2 8365  Сигнал SIGUSR2 игнорируется

$ kill -SIGUSR1 8365

[1]+ User Signal 1    Сигнал SIGUSR1 вызывает завер-

a.out                 шение выполнения процесса

$

Для отправления сигналов процессу использована команда kill(1), описанная в предыдущей главе.

Надежные сигналы

Стандарт POSIX. 1 определил новый набор функций управления сигналами. основанный на интерфейсе 4.2BSD UNIX и лишенный рассмотренных выше недостатков.

Модель сигналов, предложенная POSIX, основана на понятии набора сигналов (signal set), описываемого переменной типа sigset_t. Каждый бит этой переменной отвечает за один сигнал. Во многих системах тип sigset_t имеет длину 32 бита, ограничивая количество возможных сигналов числом 32.

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

#include <signal.h>


int sigempyset(sigset_t *set);

int siufillset(sigset_t *set);

int sigaddset(sigset_t *set, int signo);

int sigdelset(sigset_t *set, int signo);

int sigismember(sigset_t *set, int signo);

В отличие от функции signal(3C), изменяющей диспозицию сигналов, данные функции позволяют модифицировать структуру данных sigset_t, определенную процессом. Для управления непосредственно сигналами используются дополнительные функции, которые мы рассмотрим позже.

Функция sigemptyset(3C) инициализирует набор, очищая все биты. Если процесс вызывает sigfillset(3C), то набор будет включать все сигналы, известные системе. Функции sigaddset(3C) и sigdelset(3C) позволяют добавлять или удалять сигналы набора. Функция sigismember(3C) позволяет проверить, входит ли указанный параметром signo сигнал в набор.

Вместо функции signal(3C) стандарт POSIX. 1 определяет функцию sigaction(2), позволяющую установить диспозицию сигналов, узнать ее текущее значение или сделать и то и другое одновременно. Функция имеет следующее определение:

#include <signal.h>


int sigaction (int sig, const struct sigaction *act,

 struct sigaction *oact);

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

void (*sa_handler)() Обработчик сигнала sig
void (*sa_sigaction)(int, siginfo_t*, void*) Обработчик сигнала sig при установленном флаге SA_SIGINFO
sigset_t sa_mask Маска сигналов
int sa_flags Флаги
Поле sa_handler определяет действие, которое необходимо предпринять при получении сигналов, и может принимать значения SIG_IGN, SIG_DFL или адреса функции-обработчика. Если значение sa_handler или sa_sigaction не равны NULL, то в поле sa_mask передается набор сигналов, которые будут добавлены к маске сигналов перед вызовом обработчика. Каждый процесс имеет установленную маску сигналов, определяющую сигналы, доставка которых должна быть заблокирована. Если определенный бит маски установлен, соответствующий ему сигнал будет заблокирован. После возврата из функции-обработчика значение маски возвращается к исходному значению. Заметим, что сигнал, для которого установлена функция-обработчик, также будет заблокирован перед ее вызовом. Такой подход гарантирует, что во время обработки, последующее поступление определенных сигналов будет приостановлено до завершения функции. Как правило, UNIX не поддерживает очередей сигналов, и это значит, что блокировка нескольких однотипных сигналов в конечном итоге вызовет доставку лишь одного.

Поле sa_flags определяет флаги, модифицирующие доставку сигнала. Оно может принимать следующие значения:

SA_ONSTACK Если определена функция-обработчик сигнала, и с помощью функции sigaltstack(2) задан альтернативный стек для функции-обработчика, то при обработке сигнала будет использоваться этот стек. Если флаг не установлен, будет использоваться обычный стек процесса.
SA_RESETHAND* Если определена функция-обработчик, то диспозиция сигнала будет изменена на SIG_DFL, и сигнал не будет блокироваться при запуске обработчика. Если флаг не установлен, диспозиция сигнала остается неизменной.
SA_NODEFER* Если определена функция-обработчик, то сигнал блокируется на время обработки только в том случае, если он явно указан в поле sa_mask. Если флаг не установлен, в процессе обработки данный сигнал автоматически блокируется.
SA_RESTART Если определена функция-обработчик, ряд системных вызовов, выполнение которых было прервано полученным сигналом, будут автоматически перезапущены после обработки сигнала.[25] Если флаг не установлен, системный вызов возвратит ошибку EINTR.
SA_SIGINFO* Если диспозиция указывает на перехват сигнала, вызывается функция, адресованная полем sa_sigaction. Если флаг не установлен, вызывается обработчик sa_handler.
SA_NOCLDWAIT* Если указанный аргументом sig сигнал равен SIGCHLD, при завершении потомки не будут переходить в состояние зомби. Если процесс в дальнейшем вызовет функции wait(2), wait3(2), waitid(2) или waitpid(2), их выполнение будет блокировано до завершения работы всех потомков данного процесса.
SA_NOCLDSTOP* Если указанный аргументом sig сигнал равен SIGCHLD, указанный сигнал не будет отправляться процессу при завершении или останове любого из его потомков.
*Данные флаги не определены для UNIX BSD.


В системах UNIX BSD 4.x структура sigaction имеет следующий вид:

struct sigaction {

 void (*sa_handler)();

 sigset_t sa_mask;

 int sa_flags;

};

где функция-обработчик определена следующим образом:

void handler(int signo, int code, struct sigcontext *scp);

В первом аргументе signo содержится номер сигнала, code определяет дополнительную информацию о причине поступления сигнала, a scp указывает на контекст процесса.

Для UNIX System V реализована следующая возможность получения более полной информации о сигнале. Если установлен флаг SA_SIGINFO, то при получении сигнала sig будет вызван обработчик, адресованный полем sa_sigaction. Помимо номера сигнала, обычно передаваемого обработчику сигнала, ему будет переданы указатель на структуру siginfo_t, содержащую информацию о причинах получения сигнала, а также указатель на структуру ucontext_t, содержащую контекст процесса.

Структура siginfo_t определена в файле <siginfo.h> и включает следующие поля:

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

pid_t si_pid Идентификатор процесса PID
uid_t si_uid Идентификатор пользователя UID
которые адресуют процесс, пославший сигнал; если значение si_code больше нуля, то оно указывает на причину отправления сигнала. Список возможных значений si_code для некоторых сигналов, соответствующих полю si_signo, приведен в табл. 2.19


Таблица 2.19. Значения поля si_code структуры siginfo_t для некоторых сигналов

Значение поля si_signo Значение поля si_code Описание
SIGILL Попытка выполнения недопустимой инструкции
ILL_ILLOPC Недопустимый код операции (opcode)
ILL_ILLOPN Недопустимый операнд
ILL_ADR Недопустимый режим адресации
ILL_ILLTRP Недопустимая ловушка (trap)
ILL_PRVOPC Привилегированный код операции
ILL_PRVREG Привилегированный регистр
ILL_COPROC Ошибка сопроцессора
ILL_BADSTK Ошибка внутреннего стека
SIGFPE Особая ситуация операции с плавающей точкой
FPE_INTDIV Целочисленное деление на ноль
FPE_INTOVF Целочисленное переполнение
FPE_FLTDIV Деление на ноль с плавающей точкой
FPE_FLTOVF Переполнение с плавающей точкой
FPE_FLTUND Потеря точности с плавающей точкой (underflow)
FPE_FLTRES Неоднозначный результат операции с плавающей точкой
FPE_FLTINV Недопустимая операция с плавающей точкой
FPE_FLTSUB Индекс вне диапазона
SIGSEGV Нарушение сегментации
SEGV_MAPPER Адрес не отображается на объект
SEGV_ACCERR Недостаточно прав на отображаемый объект
SIGBUS Ошибка адресации
BUS_ADRALN Недопустимое выравнивание адреса
BUS_ADRERR Несуществующий физический адрес
BUS_OBJERR Аппаратная ошибка, связанная с объектом
SIGTRAP Ловушка
TRAP_BRKPT Процессом достигнута точка останова
TRAP_TRACE Ловушка трассирования процесса
SIGCHLD Завершение выполнения дочернего процесса
CLD_EXITED Дочерний процесс завершил выполнение
CLD_KILLED Дочерний процесс был "убит"
CLD_DUMPED Ненормальное завершение дочернего процесса
CLD_TRAPPED Трассируемый дочерний процесс находится в ловушке
CLD_STOPPED Выполнение дочернего процесса было остановлено
CLD_CONTINUED Выполнение остановленного дочернего процесса было продолжено
SIGPOLL Событие на опрашиваемом устройстве
POLL_IN Поступили данные для ввода
POLL_OUT Свободны буферы данных
POLL_MSG Сообщение ожидает ввода
POLL_ERR Ошибка ввода/вывода
POLL_PRI Высокоприоритетные данные ожидают ввода
POLL_HUP Устройство отключено
Уже отмечалось, что при получении сигнала от пользовательского процесса структура siginfo_t содержит дополнительные поля (табл. 2.20).


Таблица 2.20. Дополнительные поля структуры siginfo_t

Значение поля si_signo Дополнительные поля Значение
SIGILL SIGFPE caddr_t si_addr Адрес недопустимой инструкции
SIGSEGV SIGBUS caddr_t si_addr Адрес недопустимой области памяти
SIGCHLD pid_t si_pid Идентификатор дочернего процесса
int si_status Код возврата сигнала
SIGPOLL long si_band Ошибка канала (для модулей STREAMS)
Установить маску сигналов или получить текущую маску можно с помощью функции sigprocmask(2):

#include <signal.h>

int sigprocmask(int how, sigset_t *set, sigset_t *oset);

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

SIG_BLOCK Результирующая маска получится путем объединения текущей маски и набора set
SIG_UNBLOCK Сигналы набора set будут удалены из текущей маски
SIG_SETMASK Текущая маска будет заменена на набор set
Если указатель set равен NULL, то аргумент how игнорируется. Если аргумент oset не равен NULL, то в набор, адресованный этим аргументом, помещается текущая маска сигналов.

Функция sigpending(2) используется для получения набора заблокированных сигналов, ожидающих доставки:

#include <signal.h>


int sigpending(int how, sigset_t *set, sigset_t *oset);

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

Системный вызов sigsuspend(2) замещает текущую маску набором, адресованным аргументом set, и приостанавливает выполнение процесса до получения сигналов, диспозиция которых установлена либо на завершение выполнения процесса, либо на вызов функции-обработчика сигнала.

#include <signal.h>


int sigsuspend(const sigset_t *set);

При получении сигнала, завершающего выполнение процесса, возврата из функции sigsuspend(2) не происходит. Если же диспозиция полученного сигнала установлена на вызов функции-обработчика, возврат из sisuspend(2) происходит сразу после завершения обработки сигнала. При этом восстанавливается маска, существовавшая до вызова sigsuspend(2).

Заметим, что в BSD UNIX вызов signal(3) является упрощенным интерфейсом к более общей функции sigaction(2), в то время как в ветви System V signal(3) подразумевает использование старой семантики ненадежных сигналов.

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

#include <signal.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>


/* Вариант "надежной" функции signal() */

void (*mysignal(int signo, void (*hndlr)(int)))(int) {

 struct sigaction act, oact;

 /* Установим маску сигналов */

 act.sa_handler = hndlr;

 sigemptyset(&act.sa_mask);

 act.sa_flags = 0;

 if (signo != SIGALRM)

  act.sa_flags = SA_RESTART;

 /* Установим диспозицию */

 if (sigaction(signo, &act, &oact) < 0)

  return SIG_ERR;

 return(oact.sa_handler);

}


/* Функция-обработчик сигнала */

static void sig_hndlr(int signo) {

 /* Эта часть кода нам уже не нужна

  mysignal(SIGINT, sig_hndlr);

 */

 printf("Получен сигнал SIGINT\n");

}


main() {

 /* Установим диспозицию */

 mysignal(SIGINT, sig_hndlr);

 mysignal(SIGUSR2, SIG_IGN);

 /* Бесконечный цикл */

 while (1)

  pause();

}

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

Группы и сеансы

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

Многие системные вызовы могут быть применены как к единичному процессу, так и ко всем процессам группы. Например, системный вызов kill(2) может отправить сигнал как одному процессу, так и всем процессам указанной группы. Точно так же функция waitpid(2) позволяет родительскому процессу ожидать завершения конкретного процесса или любого процесса группы.

Каждый процесс, помимо этого, является членом сеанса (session), являющегося набором одной нескольких групп процессов. Понятие сеанса было введено в UNIX для логического объединения процессов, а точнее, групп процессов, созданных в результате регистрации и последующей работы пользователя в системе. Таким образом, термин "сеанс работы" в системе тесно связан с понятием сеанса, описывающего набор процессов, которые порождены пользователем за время пребывания в системе.

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

#include <sys/types.h>

#include <unistd.h>


pid_t getpgrp(void);

pid_t getpgid(pid_t pid);

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

Системный вызов setpgid(2) позволяет процессу стать членом существующей группы или создать новую группу.

#include <sys/types.h>

#include <unistd.h>


int setpgid(pid_t pid, pid_t pgid);

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

Если значения обоих аргументов равны, то создается новая группа с идентификатором pgid, а процесс становится лидером (group leader) этой группы. Поскольку именно таким образом создаются новые группы, их идентификаторы гарантированно уникальны. Заметим, что группа не удаляется при завершении ее лидера, пока в нее входит хотя бы один процесс.

Идентификатор сеанса можно узнать с помощью функции getsid(2):

#include <sys/types.h>

#include <unistd.h>


pid_t getsid(pid_t pid);

Как и в случае с группой, идентификатор pid должен адресовать процесс, являющийся членом того же сеанса, что и процесс, вызвавший getsid(2). Заметим, что эти ограничения не распространяются на процессы, имеющие привилегии суперпользователя.

Вызов функции setsid(2) приводит к созданию нового сеанса:

#include <sys/types.h>

#include <unistd.h>


pid_t setsid(void);

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

Понятия группы и сеанса тесно связаны с терминалом или, точнее, с драйвером терминала. Каждый сеанс может иметь один ассоциированный терминал, который называется управляющим терминалом (controlling terminal), а группы, созданные в данном сеансе, наследуют этот управляющий терминал. Наличие управляющего терминала позволяет ядру контролировать стандартный ввод/вывод процессов, а также дает возможность отправить сигнал всем процессам ассоциированной с терминалом группы, например, при его отключении. Типичным примером является регистрация и работа пользователя в системе. При входе в систему терминал пользователя становится управляющим для лидера сеанса (в данном случае для командного интерпретатора shell) и всех процессов, порожденных лидером (в данном случае для всех процессов, которые запускает пользователь из командной строки интерпретатора). При выходе пользователя из системы shell завершает свою работу и таким образом отключается от управляющего терминала, что вызывает отправление сигнала SIGHUP всем незавершенным процессам текущей группы. Это гарантирует, что после завершения работы пользователя в системе не останется запущенных им процессов.[26]

Текущие и фоновые группы процессов

Как было показано, для каждого управляющего терминала существует сеанс, включающий одну или несколько групп процессов. Одна из этих групп является текущей (foreground group), а остальные фоновыми (background group).[27] Сигналы SIGINT и SIGQUIT, которые генерируются драйвером терминала, посылаются всем процессам текущей группы. Попытка процессов фоновых групп осуществить доступ к управляющему терминалу, как правило, вызывает отправление им сигналов SIGSTP, SIGTTIN или SIGTTOU.

Рассмотрим следующие команды:

$ find / -name foo &

$ cat | sort

При этом происходит чтение ввода пользователя с клавиатуры (cat(1) и сортировка введенных данных (sort(1)). Если интерпретатор поддерживает управление заданиями, оба процесса, созданные для программ cat(1) и sort(1), будут помещены в отдельную группу. Это подтверждается выводом команды ps(1):

$ ps -efj | egrep "PID|andy"

UID  PID  PPID PGID SID  С  STIME   TTY   TIME CMD

andy 2436 2407 2435 2407 1 15:51:30 tty01 0:00 sort

andy 2431 2407 2431 2407 0 15:51:25 tty01 0:00 find / -name foo

andy 2407 2405 2407 2407 0 15:31:09 tty01 0:00 -sh

andy 2435 2407 2435 2407 0 15:51:30 tty01 0:00 cat

Все четыре процесса (sh, find, cat и sort) имеют один и тот же идентификатор сеанса, связанного с управляющим терминалом tty01. Процессы cat(1) и sort(1) принадлежат одной группе, идентификатор которой (2435) отличен от идентификатора группы командного интерпретатора (2407). То же самое можно сказать и о процессе find(1), который является лидером отдельной группы (2431). Можно также заметить, что процессы sh(1), find(1) и cat(1) являются лидерами групп, a еще sh(1) и лидером сеанса.

Хотя команда ps(1) не указывает, какие группы являются фоновыми, а какая текущей, синтаксис команд позволяет утверждать, что командный интерпретатор помещает cat(1) и sort(1) в текущую группу. Это, во-первых, позволяет процессу cat(1) читать данные со стандартного потока ввода, связанного с терминалом tty01. Во-вторых, пользователь имеет возможность завершить выполнение обоих процессов путем нажатия клавиши <Del> (или <Ctrl>+<C>), что вызовет генерацию сигнала SIGINT. Получение процессами этого сигнала вызовет завершение их выполнения (действие по умолчанию), если, конечно, процесс не установил игнорирование SIGINT. На рис. 2.13. представлена схема взаимодействия управляющего терминала, сеанса и групп процессов для приведенного выше примера. Более детально взаимосвязь между терминалом и процессами рассмотрена в следующей главе.

Рис. 2.13. Связь между управляющим терминалом, сеансом и группами

Если командный интерпретатор не поддерживает управление заданиями, оба процесса станут членами той же группы, что и сам shell. В этом случае командный интерпретатор должен позаботиться об игнорировании сигналов SIGINT и SIGQUIT, чтобы допустимые действия пользователя (такие как нажатие клавиши <Del> или <Ctrl>+<C>) не привели к завершению выполнения shell и выходу из системы.

Ограничения

UNIX является многозадачной системой. Это значит, что несколько процессов конкурируют между собой при доступе к различным ресурсам. Для "справедливого" распределения разделяемых ресурсов, таких как память, дисковое пространство и т.п., каждому процессу установлен набор ограничений. Эти ограничения не носят общесистемного характера, как, например, максимальное число процессов или областей, а устанавливаются для каждого процесса отдельно. Для получения информации о текущих ограничениях и их изменения предназначены системные вызовы getrlimit(2) и setrlimit(2):

#include <sys/time.h>

#include <sys/resource.h>


int getrlimit{int resource, struct rlimit *rlp);

int setrlimit(int resource, const struct rlimit *rlp);

Аргумент resource определяет вид ресурса, для которого мы хотим узнать или изменить ограничения процесса. Структура rlimit состоит из двух полей:

rlim_t rlim_cur;

rlim_t rlim_max;

определяющих, соответственно, изменяемое (soft) и жесткое (hard) ограничение. Первое определяет текущее ограничение процесса на данный ресурс, а второе — максимальный возможный предел потребления ресурса. Например, изменяемое ограничение на число открытых процессом файлов может составлять 64, в то время как жесткое ограничение равно 1024.

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

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

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


Таблица 2.21. Ограничения процесса (значения аргумента resource)

Ограничение Тип ресурса Эффект
RLIMIT_CORE Максимальный размер создаваемого файла core, содержащего образ памяти процесса. Если предел установлен равным 0, файл core создаваться не будет. После создания файла core запись в этот файл будет остановлена при достижении предельного размера.
RLIMIT_CPU Максимальное время использования процессора в секундах. При превышении предела процессу отправляется сигнал SIGXCPU.
RLIMIT_DATA Максимальный размер сегмента данных процесса в байтах, т.е. максимальное значение смещения брейк-адреса. При достижении этого предела последующие вызовы функции brk(2) завершатся с ошибкой ENOMEM.
RLIMIT_FSIZE Максимальный размер файла, который может создать процесс. Если значение этого предела равно 0, процесс не может создавать файлы. При достижении этого предела процессу отправляется сигнал SIGXFSZ. Если сигнал перехватывается или игнорируется процессом, последующие попытки увеличить размер файла закончатся с ошибкой EFBIG.
RLIMIT_NOFILE Максимальное количество назначенных файловых дескрипторов процесса. При достижении этого предела, последующие попытки получить новый файловый дескриптор закончатся с ошибкой EMFlLE.
RLIMIT_STACK Максимальный размер стека процесса. При попытке расширить стек за установленный предел отправляется сигнал SIGSEGV. Если процесс перехватывает или игнорирует сигнал и не использует альтернативный стек с помощью функции sigaltstack(2), диспозиция сигнала устанавливается на действие по умолчанию перед отправкой процессу.
RLIMIT_VMEM Максимальный размер отображаемой памяти процесса в байтах. (Предел определен в версиях System V.) При достижении этого предела последующие вызовы brk(2) или mmap(2) завершатся с ошибкой ENOMEM.
RLIMIT_NPROC Максимальное число процессов с одним реальным UID. Определяет максимальное число процессов, которые может запустить пользователь. (Предел определен в версиях BSD UNIX.) При достижении этого предела, последующие вызовы fork(2) для порождения нового процесса завершатся с ошибкой EAGAIN.
RLIMIT_RSS Максимальный размер в байтах резидентной части процесса (RSS — Resident Set Size). Определяет максимальное количество физической памяти, предоставляемой процессу. (Предел определен в версиях BSD UNIX.) Если система ощущает недостаток памяти, ядро освободит память за счет процессов, превысивших свой RSS.
RLIMIT_MEMLOCK Максимальный физической памяти (физических страниц) в байтах, который процесс может заблокировать с помощью системного вызова mlock(2). (Предел определен в версиях BSD UNIX.) При превышении предела системный вызов mlock(2) завершится с ошибкой EAGAIN.
В заключение приведем пример программы, выводящий на экран установленные ограничения для процесса:

#include <sys/types.h>

#include <sys/resource.h>


/* Процедура вывода на экран текущего и максимального

   пределов потребления ресурса resource */

void disp_limit(int resource, char *rname) {

 struct rlimit rim;

 getrlimit(resource, &rlm);

 printf("%-13s ", rname);

 /* Значение изменяемого ограничения */

 if (rlm.rlim_curr == RLIM_INFINITY)

  printf("infinite ");

 else

  printf("%101d ", rlm.rlim_cur);

 /* Значение жесткого ограничения */

 if (rlm.rlim_max == RLIM_INFINITY)

  printf("infinite \n");

 else

  printf("%10ld\n", rlm.rlim_max);

}


main() {

 disp_limit(RLIMIT_CORE, "RLIMIT_CORE");

 disp_limit(RLIMIT_CPU, "RLIMIT_CPU");

 disp_limit(RLIMIT_DATA, "RLIMIT_DATA");

 disp_limit(RLIMIT_FSIZE, "RLIMIT_FSIZE");

 disp_limit(RLIMIT_NOFILE, "RLIMIT_NOFILE");

 disp_limit(RLIMIT_STACK, "RLIMIT_STACK");

 /* BSD */

#ifdef RLIMIT_NPROC

 disp_limit(RLIMIT_NPROC, "RLIMIT_NPROC");

#endif

 /* BSD */

#ifdef RLIMIT_RSS

 disp_limit(RLIMIT_RSS, "RLIMIT_RSS");

#endif

 /* BSD */

#ifdef RLIMIT_MEMLOCK

 disp_limit(RLIMIT_MEMLOCK, "RLIMIT_MEMLOCK");

#endif

 /* System V */

#ifdef RLIMIT_VMEM

 disp_limit(RLIMIT_VMEM, "RLIMIT_VMEM");

#endif

}

Запуск программы под управлением операционной системы Solaris 2.5 даст следующие результаты:

$ а.out

RLIMIT_CORE   infinite   infinite

RLIMIT_CPU    infinite   infinite

RLIMIT_DATA   2147479552 2147479552

RLIMIT_FSIZE  infinite   infinite

RLIMIT_NOFILE 64         1024

RLIMIT_STACK  8388608    2147479552

RLIMIT_VMEM   infinite   infinite

Примеры программ

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

Демон

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

Некоторые демоны работают постоянно, наиболее яркий пример такого демона — процесс init(1M), являющийся прародителем всех прикладных процессов в системе. Другими примерами являются cron(1M), позволяющий запускать программы в определенные моменты времени, inetd(1M) обеспечивающий доступ к сервисам системы из сети, и sendmail(1M), обеспечивающий получение и отправку электронной почты.

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

1. Демон не должен реагировать на сигналы управления заданиями, посылаемые ему при попытке операций ввода/вывода с управляющим терминалом. Начиная с некоторого времени, демон снимает ассоциацию с управляющим терминалом, но на начальном этапе запуска ему может потребоваться вывести то или иное сообщение на экран.

2. Необходимо закрыть все открытые файлы (файловые дескрипторы), особенно стандартные потоки ввода/вывода. Многие из этих файлов представляют собой терминальные устройства, которые должны быть закрыты, например, при выходе пользователя из системы. Предполагается, что демон остается работать и после того, как пользователь "покинул" UNIX.

3. Необходимо снять его ассоциацию с группой процессов и управляющим терминалом. Это позволит демону избавиться от сигналов, генерируемых терминалом (SIGINT или SIGHUP), например, при нажатии определенных клавиш или выходе пользователя из системы.

4. Сообщения о работе демона следует направлять в специальный журнал с помощью функции syslog(3), — это наиболее корректный способ передачи сообщений от демона.

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

Приведем скелет программы-демона:

#include <stdio.h>

#include <syslog.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/param.h>

#include <sys/resource.h>


main(int argc, char **argv) {

 int fd;

 struct rlimit flim;

 /* Если родительский процесс — init, можно не беспокоиться

    за терминальные сигналы. Если нет — необходимо игнорировать

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

    фонового процесса: SIGTTOU, SIGTTIN, SIGTSTP */

 if (getppid() != 1) {

  signal(SIGTTOU, SIG_IGN);

  signal(SIGTTIN, SIG_IGN);

  signal(SIGTSTP, SIG_IGN);


  /* Теперь необходимо организовать собственную группу и сеанс,

     не имеющие управляющего терминала. Однако лидером группы и

     сеанса может стать процесс, если он еще не является лидером.

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

     необходима гарантия, что наш процесс не является лидером.

     Для этого порождаем дочерний процесс. Т.к. его PID уникален,

     то ни группы, ни сеанса с таким идентификатором не существует,

     а значит нет и лидера. При этом родительский процесс

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

     Существует еще одна причина необходимости порождения

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

     командного интерпретатора shell не в фоновом режиме,

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

     и таким образом, терминал будет заблокирован.

     Порождая процесс и завершая выполнение родителя,

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

     работы демона, после чего shell выведет свое приглашение */

  if (fork () !=0)

   exit(0); /* Родитель заканчивает работу */

   /* Дочерний процесс с помощью системного вызова

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

      ассоциированного терминала */[28]

 }

 /* Теперь необходимо закрыть открытые файлы. Закроем

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

    открытых файлов получим с помощью функции getrlimit */

 getrlimit(RLIMIT_NOFILE, &flim);

 for (fd = 0; fd < flim.rlim_max; fd++)

  close(fd);

 /* Сменим текущий каталог на корневой */

  chdir("/");

 /* Заявим о себе в системном журнале. Для этого сначала

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

    предваряться идентификатором PID демона, при невозможности

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

    источник сообщений определим как "системный демон"

    (см. комментарии к функциям ведения журнала ниже). */

 openlog("Скелет демона" , LOG_PID | LOG_CONS, LOG_DAEMON);

 /* Отметимся */

 syslog(LOG_INFO, "Демон начал плодотворную работу...");

 closelog();

 /* Далее следует текст программы, реализующий полезные функции

    демона. Эта часть предоставляется читателю для собственной

    разработки. */

 ...

}

В программе использовалось еще не обсуждавшаяся возможность системного журнала сообщений выполняющихся программ. Функцией генерации сообщений является syslog(3), отправляющая сообщение демону системного журнала syslogd(1M), который в свою очередь либо дописывает сообщения в системный журнал, либо выводит на их консоль, либо перенаправляет в соответствии со списком пользователей данной или удаленной системы. Конкретный пункт назначения определяется конфигурационным файлом (/etc/syslog.conf). Функция имеет определение:

#include <syslog.h>


void syslog(int priority, char *logstring, /* параметры*/...);

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

LOG_EMERG Идентифицирует состояние "паники" в системе. Обычно рассылается всем пользователям.
LOG_ALERT Идентифицирует ненормальное состояние, которое должно быть исправлено немедленно, например, нарушение целостности системной базы данных.
LOG_CRIT Идентифицирует критическое событие, например, ошибку дискового устройства.
LOG_ERR Идентифицирует различные ошибки.
LOG_WARNING Идентифицирует предупреждения.
LOG_NOTICE Идентифицирует события, которые не являются ошибками, но требуют внимания.
LOG_INFO Идентифицирует информационные сообщения, как, например, использованное в приведенной программе.
LOG_DEBUG Идентифицирует сообщение, обычно используемое только при отладке программы.
Последний тип сообщений подсказывает еще одну возможность использования системного журнала — для отладки программ, особенно неинтерактивных.

Строка logstring может включать элементы форматирования, такие же, как и в функции printf(3), с одним дополнительным выражением %m, которое заменяется сообщением, соответствующим ошибке errno. При этом может осуществляться вывод значений дополнительных параметров.

Функция openlog(3) позволяет определить ряд опций ведения журнала. Она имеет следующее определение:

void openlog(char *ident, int logopt, int facility);

Строка ident будет предшествовать каждому сообщению программы. Аргумент logopt задает дополнительные опции, в том числе:

LOG_PID Позволяет указывать идентификатор процесса в каждом сообщении. Эта опция полезна при журналировании нескольких демонов с одним и тем же значением ident, например, когда демоны порождаются вызовом fork(2).
LOG_CONS Позволяет выводить сообщения на консоль при невозможности записи в журнал.
Наконец, аргумент facility позволяет определить источник сообщений:

LOG_KERN Указывает, что сообщения отправляются ядром.
LOG_USER Указывает, что сообщения отправлены прикладным процессом (используется по умолчанию).
LOG_MAIL Указывает, что инициатором сообщений является система электронной почты.
LOG_DAEMON Указывает, что инициатором сообщений является системный демон.
LOG_NEWS Указывает, что инициатором сообщений является система телеконференций USENET.
LOG_CRON Указывает, что инициатором сообщений является система cron(1).
Закончив работу с журналом, следует аккуратно закрыть его с помощью функции closelog(3):

void closelog(void);

Командный интерпретатор

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

Функции приведенного командного интерпретатора сведены к минимуму: он распознает и выполняет несколько встроенных команд, остальной ввод он расценивает как внешние программы, которые и пытается запустить с помощью системного вызова exec(2).

#include <sys/types.h>

#include <sys/wait.h>

#include <unistd.h>


extern char** environ;


#define CMDSIZE 80

/* Встроенные команды интерпретатора */


#define CD 1

#define ECHO 2

#define EXEC 3 ...

#define PROGRAM 1000


/* Функция, которая производит анализ строки, введенной

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

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

   функция принимает строку cmdbuf, введенную пользователем,

   и возвращает имя команды/программы path и переданные ей

   параметры arguments. Возвращаемое значение указывает на

   внутреннюю команду или внешнюю программу, которую необходимо

   запустить.*/

int parse_command(char* cmdbuf, char* path, char** arguments);


main {

 charcmd[CMDSIZE];

 int command;

 int stat_loc;

 char** args;

 char cmdpath[MAXPATH];

 while (1) {

  /* Выведем сообщение интерпретатора */

  write(1, "$ ", 2);

  /* Считаем ввод пользователя и проанализируем строку */

  cmdsize = read(0, cmd, CMDSIZE);

  cmd[cmdsize-1] ='\0';

  command = parse_command(cmd, cmdpath, args);

  switch(command) {

  /* Если это внутренняя команда, обработаем ее */

  case (CD):

   chdir(args[0]);

   break;

  case(ECHO):

   write(1, args[0], strlen(args[0]));

   break;

  case(EXEC):

   execve(path, args, environ);

   write(2, "shell: cannot execute", 21);

   break;

   ...

  /* Если это внешняя программа, создадим дочерний процесс, который

     и запустит программу */

  case(PROGRAM):

   pid = fork();

   if (pid < 0)

    write(2, "shell: cannot fork", 18);

   else if (pid == 0) {

    /* Дочерний процесс */

    execve(path, args, environ);

    write(2, "shell: cannot execute", 21);

   } else

    /* Родительский процесс */

    /* Ожидаем завершения выполнения программы */

   wait(&stat_lock);

   break;

  }

 }

}

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

Заключение

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

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

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

Вся функциональность операционной системы в конечном счете определяется выполнением тех или иных процессов. Даже так называемые уровни выполнения системы (run levels) представляют собой ни что иное, как удобную форму определения группы выполняющихся процессов. Возможность терминального или сетевого доступа к системе, различные сервисы, традиционные для UNIX, — система печати, удаленные архивы FTP, электронная почта и система телеконференций (news) — все это результат выполнения определенных процессов.

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

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

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

Последние разделы главы посвящены взаимодействию между процессами. Хотя основной задачей операционной системы является изоляция отдельного процесса от остальных, время от времени процессам все же требуется обмениваться данными. Для этого UNIX предлагает широкий спектр средств — от элементарного механизма сигналов до сложных подсистем межпроцессного взаимодействия — IPC UNIX System V и сокетов BSD.

Основы управления процессом

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

Рис. 3.1. Инфраструктура процесса операционной системы UNIX

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

Новорожденная операционная система UNIX обеспечивала выполнение всего двух процессов, по одному на каждый подключенный к PDP-7 терминал. Спустя год, на той же PDP-7 число процессов заметно увеличилось, появился системный вызов fork(2). В Первой редакции UNIX появился вызов exec(2), но операционная система по-прежнему позволяла размещать в памяти только один процесс в каждый момент времени. После реализации аппаратной подсистемы управления памятью на операционная система была модифицирована, что позволило загружать в память сразу несколько процессов, уменьшая тем самым время на сохранение образа процесса во вторичной памяти (на диске) и считывание его, когда процесс продолжал выполнение. Однако до 1972 года UNIX нельзя было назвать действительно многозадачной системой, т.к. операции ввода/вывода оставались синхронными, и другие процессы не могли выполняться, пока их "коллега" не завершал операцию ввода/вывода достаточно продолжительную). Истинная многозадачность появилась только после того, как код UNIX был переписан на языке С в 1973 году. С тех пор основы управления процессами практически не изменились.

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

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

Структуры данных процесса

Каждый процесс представлен в системе двумя основными структурами данных — proc и user, описанными, соответственно, в файлах <sys/proc.h> и <sys/user.h>. Содержимое и формат этих структур различны для разных версий UNIX. В табл. 3.1 приведены некоторые поля структуры proc в SCO UNIX, позволяющие проиллюстрировать информацию, необходимую ядру, для управления процессом.


Таблица 3.1. Структура proc

char p_stat Состояние процесса (выполнение, приостановлен, сон и т.д.)
char p_pri Текущий приоритет процесса
unsigned int p_flag Флаги, определяющие дополнительную информацию о состоянии процесса
unsigned short p_uid UID процесса
unsigned short p_suid EUID процесса
int p_sid Идентификатор сеанса
short p_pgrp Идентификатор группы процессов (равен идентификатору лидера группы)
short p_pid Идентификатор процесса (PID)
short p_ppid Идентификатор родительского процесса (PPID)
sigset_t p_sig Сигналы, ожидающие доставки
unsigned int p_size Размер адресного пространства процесса в страницах
time_t p_utime Время выполнения в режиме задачи
time_t p_stime Время выполнения в режиме ядра
caddr_t p_ldt Указатель на LDT процесса
struct pregion *p_region Список областей памяти процесса
short p_xstat Код возврата, передаваемый родительскому процессу
unsigned int p_utbl[] Массив записей таблицы страниц для u-area
В любой момент времени данные структур proc для всех процессов должны присутствовать в памяти, хотя остальные структуры данных, включая образ процесса, могут быть перемещены во вторичную память, — область свопинга. Это позволяет ядру иметь под рукой минимальную информацию, необходимую для определения местонахождения остальных данных, относящихся к процессу, даже если они отсутствуют в памяти.

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

Вторая упомянутая структура — user, также называемая u-area или u-block, содержит дополнительные данные о процессе, которые требуются ядру только во время выполнения процесса (т.е. когда процессор выполняет инструкции процесса в режиме ядра или задачи). В отличие от структуры proc, адресованной указателем curproc, данные user размещаются (точнее, отображаются) в определенном месте виртуальной памяти ядра и адресуются переменной u. На рис. 3.2 показаны две основные структуры данных процесса и способы их адресации ядром UNIX.

Рис. 3.2. Основные структуры данных процесса

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

Как видно из рис. 3.2, u-area также содержит стек фиксированного размера, — системный стек или стек ядра (kernel stack). При выполнении процесса в режиме ядра операционная система использует этот стек, а не обычный стек процесса.

Состояния процесса

Жизненный цикл процесса может быть разбит на несколько состояний. Переход процесса из одного состояния в другое происходит в зависимости от наступления тех или иных событий в системе. На рис. 3.3 показаны состояния, в которых процесс может находиться с момента создания до завершения выполнения.

1. Процесс выполняется в режиме задачи. При этом процессором выполняются прикладные инструкции данного процесса.

2. Процесс выполняется в режиме ядра. При этом процессором выполняются системные инструкции ядра операционной системы от имени процесса.

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

4. Процесс находится в состоянии сна (asleep), ожидая недоступного в данный момент ресурса, например завершения операции ввода/вывода.

5. Процесс возвращается из режима ядра в режим задачи, но ядро прерывает его и производит переключение контекста для запуска более высокоприоритетного процесса.

6. Процесс только что создан вызовом fork(2) и находится в переходном состоянии: он существует, но не готов к запуску и не находится в состоянии сна.

7. Процесс выполнил системный вызов exit(2) и перешел в состояние зомби (zombie, defunct). Как такового процесса не существует, но остаются записи, содержащие код возврата и временную статистику его выполнения, доступную для родительского процесса. Это состояние является конечным в жизненном цикле процесса.


Рис. 3.3. Состояния процесса

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

Процесс начинает свой жизненный путь с состояния 6, когда родительский процесс выполняет системный вызов fork(2). После того как создание процесса полностью завершено, процесс завершает "дочернюю часть" вызова fork(2) и переходит в состояние 3 готовности к запуску, ожидая своей очереди на выполнение. Когда планировщик выбирает процесс для выполнения, он переходит в состояние 1 и выполняется в режиме задачи.

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

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

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

В UNIX 4.x BSD определены дополнительные состояния процесса, в первую очередь связанные с системой управления заданиями и взаимодействием процесса с терминалом. Процесс может быть переведен в состояние "остановлен" с помощью сигналов останова SIGSTOP, SIGTTIN или SIGTTOU. В отличие от других сигналов, которые обрабатываются только для выполняющегося процесса, отправление этих сигналов приводит к немедленному изменению состояния процесса.[29] В этом случае, если процесс выполняется или находится в очереди на запуск, его состояние изменяется на "остановлен". Если же процесс находился в состоянии сна, его состояние изменится на "остановлен в состоянии сна". Выход из этих состояний осуществляется сигналом продолжения SIGCONT, при этом из состояния "остановлен" процесс переходит в состояние "готов к запуску", а для процесса, остановленного в состоянии сна, следующим пунктом назначения является продолжение "сна". Описанные возможности полностью реализованы и в SVR4.

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

Принципы управления памятью

Одной из основных функций операционной системы является эффективное управление памятью. Оперативная память, или основная память, или память с произвольным доступом (Random Access Memory, RAM) является достаточно дорогостоящим ресурсом. Время доступа к оперативной памяти составляет всего несколько циклов процессора, поэтому работа с данными, находящимся в памяти, обеспечивает максимальную производительность. К сожалению, данный ресурс, как правило, ограничен. В большей степени это справедливо для многозадачной операционной системы общего назначения, каковой является UNIX. Поэтому данные, которые не могут быть размещены в оперативной памяти, располагаются на вторичных устройствах хранения, или во вторичной памяти, роль которой обычно выполняют дисковые накопители. Время доступа ко вторичной памяти па несколько порядков превышает время доступа к оперативной памяти и требует активного содействия операционной системы. Подсистема управления памятью UNIX отвечает за справедливое и эффективное распределение разделяемого ресурса оперативной памяти между процессами и за обмен данными между оперативной и вторичной памятью. Часть операций производится аппаратно устройством управления памятью (Memory Management Unit, MMU) процессора под управлением операционной системы, чем достигается требуемое быстродействие.

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

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

□ Выполнение задач, размер которых превышает размер оперативной памяти.

□ Выполнение частично загруженных в память задач для минимизации времени их запуска.

□ Размещение нескольких задач в памяти одновременно для повышения эффективности использования процессора.

□ Размещение задачи в произвольном месте оперативной памяти.

□ Размещение задачи в нескольких различных частях оперативной памяти.

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

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

Виртуальная и физическая память

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

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

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

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

□ В-третьих, подобное распределение памяти между процессами вряд ли можно назвать оптимальным. Объем физической оперативной памяти будет существенным образом ограничивать число процессов, одновременно выполняющихся в системе. Так восемь процессов, каждый из которых занимает 1 Мбайт памяти, исчерпают 8 Мбайт оперативной памяти, а операционная система при средней загрузке насчитывает более 80 процессов!

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

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

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

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

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

Рис. 3.4. Виртуальная и физическая память

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

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

Сегменты

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

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

Дескрипторы сегментов расположены в двух системных таблицах — локальной таблице дескрипторов (Local Descriptor Table — LDT) и глобальной таблице дескрипторов (Global Descriptor Table — GDT). Как следует из названия, LDT обеспечивает трансляцию виртуальных адресов сегментов процесса, в то время как GDT обслуживает адресное пространство ядра (например, при обработке системного вызова или прерывания). Для каждого процесса создается собственная LDT, в то время как GDT разделяется всеми процессами. Информация о таблице, на которую указывает селектор, находится в самом селекторе, вид которого представлен на рис. 3.5.

Рис. 3.5. Селектор сегмента

Если бит TI равен 0, то селектор указывает на GDT, в противном случае используется LDT. Поле RPL задает уровень привилегий сегмента и является одним из механизмов обеспечения защиты сегментов. Например, если процесс, находясь в режиме задачи, попытается обратиться к сегменту, принадлежащему ядру, процессор сгенерирует особую ситуацию, в ответ на это ядро отправит процессу сигнал SIGSEGV.

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

Дескрипторы сегментов (кода, данных, стека) имеют несколько полей:

Базовый адрес В этом поле хранится 32-битный адрес начала сегмента. Процессор добавляет к нему смещение и получает 32-битный линейный адрес.
Предел Это поле определяет размер сегмента. Если результирующий линейный адрес выходит за пределы сегмента, процессор генерирует особую ситуацию. Границы сегмента позволяют процессору обнаруживать такие распространенные ошибки, как переполнение стека, неверные указатели, неверные адреса вызовов и переходов. В случае, когда операционная система считает, что обращение за пределы сегмента не является ошибкой (например, при переполнении стека), она может расширить сегмент путем выделения дополнительной памяти и запросить выполнение команды вновь.
Привилегии Это поле, имеющее название Descriptor Privilege Level (DPL), определяет уровень привилегий сегмента и используется совместно с полем RPL селектора для разрешения или запрещения доступа к сегменту. Для получения доступа к сегменту задача должна иметь по крайней мере такой же уровень привилегий, как и сегмент, т.е. RPL ≥ DPL.
Признак присутствия Этот бит обеспечивает один из механизмов реализации виртуальной памяти. Если бит не установлен, при попытке обращения к сегменту процессор генерирует особую ситуацию отсутствия сегмента, позволяя ядру подгрузить сегмент из вторичной памяти и вновь повторить инструкцию, не затрагивая при этом выполнение процесса. Однако в большинстве современных версий UNIX виртуальная память основана на страничном механизме, при котором сегмент всегда присутствует в памяти, а обмен между оперативной и вторичной памятью происходит на уровне страниц.
Тип Это поле определяет тип сегмента. Процессор проверяет тип сегмента на соответствие исполняемой команде. Это, в частности, не позволяет интерпретировать информацию сегмента данных как инструкции процессора.
Права доступа Это поле определяет права доступа, ограничивающие множество операций, которые можно производить с сегментом. Например, сегмент кода обычно отмечается как исполняемый и читаемый. Сегменты данных могут иметь право доступа только для чтения, или для чтения и записи.
Комбинация селектора и смещения образует логический адрес. Блок управления памятью процессора использует селектор для определения соответствующего ему дескриптора. Складывая базовый адрес сегмента, хранящийся в дескрипторе, со смещением, процессор создает линейный адрес (рис. 3.6).

Рис. 3.6. Трансляция адреса с использованием механизма сегментации

Если страничный механизм не используется, полученный линейный адрес является физическим, используемым для непосредственного доступа к оперативной памяти. Однако реализация виртуальной памяти, основанная только на сегментах, не обладает достаточной гибкостью и не используется в современных версиях UNIX. Управление памятью в большинстве систем основано на страничном механизме. Сегменты используются ядром для размещения кода, данных и стека процесса, причем каждый из них имеет нулевой базовый адрес и предел — 3 Гбайт, т.е. всю адресуемую виртуальную память за вычетом 1 Гбайт, занимаемых ядром системы. Распределение виртуального адресного пространства между ядром и процессами рассмотрено в разделе "Адресное пространство процесса".

Страничный механизм

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

Страничный механизм обеспечивает гораздо большую гибкость. В этом случае все виртуальное адресное пространство (4 Гбайт для процессоров Intel) разделено на блоки одинакового размера, называемые страницами. Большинство процессоров Intel работает со страницами размером 4 Кбайт. Так же как и в случае сегментации, страница может либо присутствовать в оперативной памяти, либо находиться в области свопинга или исполняемом файле процесса. Основное преимущество такой схемы заключается в том, что система управления памятью оперирует областями достаточно малого размера для обеспечения эффективного распределения ресурсов памяти между процессами. Страничный механизм допускает, чтобы часть сегмента находилась в оперативной памяти, а часть отсутствовала. Это дает ядру возможность разместить в памяти только те страницы, которые в данное время используются процессом, тем самым значительно освобождая оперативную память. Еще одним преимуществом является то, что страницы сегмента могут располагаться в физической памяти в произвольном месте и порядке, что позволяет эффективно использовать свободное пространство[30].

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

Рис. 3.7. Трансляция адреса с использованием страничного механизма

Первое поле адреса, с 22 по 31 бит, указывает на элемент каталога таблиц страниц (Page Directory Entry, PDE). Каталог таблиц страниц имеет длину, равную одной странице, и содержит до 1024 указателей на таблицы страниц (page table). Таким образом, первое поле адресует определенную таблицу страниц. Второе поле, занимающее с 12 по 21 бит, указывает на элемент таблицы страниц (Page Table Entry, РТЕ). Таблицы страниц также имеют длину 4 Кбайт, а элементы таблицы адресуют в совокупности 1024 страниц. Другими словами, второе поле адресует определенную страницу. Наконец, смещение на странице определяется третьим полем, занимающим младшие 12 бит линейного адреса. Таким образом, с помощью одного каталога таблиц процесс может адресовать 1024×1024×4096 = 4 Гбайт физической памяти.

На рис. 3.7 показано, как блок страничной адресации процессора транслирует линейный адрес в физический. Процессор использует поле PDE адреса (старшие 10 бит) в качестве индекса в каталоге таблиц. Найденный элемент содержит адрес таблицы страниц. Второе поле линейного адреса, РТЕ, позволяет процессору выбрать нужный элемент таблицы, адресующий физическую страницу. Складывая адрес начала страницы со смещением, хранящимся в третьем поле, процессор получает 32-битный физический адрес.[31]

Каждый элемент таблицы страниц содержит несколько полей (табл. 3.2), описывающих различные характеристики страницы.


Таблица 3.2. Поля РТЕ

P Признак присутствия в оперативной памяти. Доступ к странице, отсутствующей в памяти (P=0) вызывает страничную ошибку, особую ситуацию, о чем процессор информирует ядро, которое обрабатывает ее соответствующим образом.
R/W Права только на чтение страницы (R/W=0) или на чтение и запись (R/W=1).
U/S Привилегии доступа. Если U/S = 0, только привилегированные задачи (ядро) имеют доступ к адресам страницы. В противном случае, доступ к странице имеют все задачи.
Адрес Физический адрес начала страницы (адрес базы).

Адресное пространство процесса

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

Рис. 3.8. Адресное пространство в режимах ядра и задачи

Специальный регистр (CR3 для Intel) указывает на расположение каталога таблиц страниц в памяти. В SCO UNIX используется только один каталог, независимо от выполняющегося процесса, таким образом значение регистра CR3 не меняется на протяжении жизни системы. Поскольку ядро (код и данные) является частью выполняющегося процесса, таблицы страниц, отображающие старший 1 Гбайт виртуальной памяти, принадлежащей ядру системы, не изменяются при переключении между процессами. Для отображения ядра используются старшие 256 элементов каталога.

При переключении между процессами, однако, изменяется адресное пространство режима задачи, что вызывает необходимость изменения оставшихся 768 элементов каталога. В совокупности они отображают 3 Гбайт виртуального адресного пространства процесса в режиме задачи. Таким образом, при смене процесса адресное пространство нового процесса становится видимым (отображаемым), в то время как адресное пространство предыдущего процесса является недоступным[32].

Формат виртуальной памяти процесса в режиме задачи зависит, в первую очередь, от типа исполняемого файла, образом которого является процесс. На рис. 3.9 изображено расположение различных сегментов процесса в виртуальной памяти для двух уже рассмотренных нами форматов исполняемых файлов — COFF и ELF. Заметим, что независимо от формата исполняемого файла виртуальные адреса процесса не могут выходить за пределы 3 Гбайт.

Рис. 3.9. Виртуальная память процесса в режиме задачи

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

Управление памятью процесса

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

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

□ Размещение в памяти каталога страниц и таблиц страниц; инициализация регистра — указателя на каталог таблиц страниц (для Intel — CR3) (в системах, использующих несколько каталогов страниц, каждый процесс хранит в u-area значение этого регистра; в этом случае инициализацию указателя необходимо проводить при каждом переключении контекста); инициализация каталога страниц.

□ Установка отображения путем записи соответствующих значений в таблицы страниц.

□ Обработка страничных ошибок.

□ Управление сверхоперативным кэшем.

□ Обеспечение обмена страницами между оперативной и вторичной памятью.

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

Области

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

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

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

Поскольку одна и та же область может использоваться несколькими процессами, для каждого процесса ядро создает связанный список структур pregion (per process region), которые в свою очередь адресуют области, используемые процессом. Указатель на список структур pregion для каждого процесса находится в записи таблицы процессов — структуре proc.

Основные поля структур region и pregion приведены на рис. 3.10.

Рис. 3.10. Управление адресным пространством процесса в SCO UNIX

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

Значение Описание
PT_UNUSED Область не используется
PT_TEXT Область содержит сегмент кода
PT_DATA Область содержит сегмент данных
PT_STACK Область используется в качестве стека процесса
PT_SHMEM Область используется в качестве разделяемой памяти
PT_LIBTXT Область содержит код библиотек
PT_LIBDAT Область содержит данные библиотек
PT_SHFIL Область используется для хранения файла, отображенного в память
Наконец, поле p_regva задает виртуальный адрес области в адресном пространстве процесса.

Поля структуры region, приведенные на рис. 3.10, имеют следующие значения. Поле r_pgsz определяет размер области в страницах, из которых r_nvalid страниц присутствуют в оперативной памяти (см. далее раздел "Страничное замещение"). Несколько процессов могут ссылаться на одну и ту же область, поле r_refcnt хранит число таких ссылок. Поле r_pde  адресует таблицу страниц области[33]. Поле r_iptr адресует inode файла, где располагаются данные области (например, для области кода, r_iptr будет указывать на inode исполняемого файла).

Фактическую информацию о структурах управления адресным пространством процесса можно получить с помощью команды crash(1M). В следующем примере таким образом определяется содержимое структур pregion процесса и характеристики соответствующих областей.

# crash

dumpfile = /dev/mem, namelist = /unix, outfile = stdout

> pregion 101

SLOT PREG REG#      REGVA  TYPE FLAGS

 101    0   12   0x700000  text rdonly

        1   22   0x701000  data

        2   23 0x7ffffffc stack

        3  145 0x80001000 lbtxt rdonly

        4  187 0x80031000 lbdat pr

Как можно увидеть из вывода команды crash(1М), с рассматриваемым процессом связаны пять областей: сегмент кода, данных и стека, а также сегменты кода и данных подключенной библиотеки. Столбец REG# определяет запись таблицы областей, где расположена адресуемая каждой pregion область region. Заметим, что значение в столбце REG# лишь отчасти соответствует полю p_reg структуры pregion, поскольку последнее является указателем, а не индексом таблицы. Столбец REGVA содержит значения виртуальных адресов областей.

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

>region 12 22 23

SLOT PGSZ VALID SMEM NONE SOFF KEF SWP NSW FORW BACK INOX TYPE FLAGS

  12    1     1    1    0    0  11   0   0   15    5  154 stxt done

  22    3     1    0    0    0   1   0   0  238   23  154 priv done

  23    2     1    1    0    0   1   0   0  135   24      priv stack

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

Мы можем взглянуть на дополнительные сведения об этом файле:

>inode 154

INODE TABLE SIZE = 472

SLOT MAJ/MIN FS INUMB RCNT LINK UID GID SIZE    MODE MNT M/ST FLAGS

154    1,42   2  1562    3    1 123  56 8972 f---755   0 R130 tx

Из этой таблицы мы можем определить файловую систему, в которой расположен файл (MAJ/MIN), а также номер его дискового inode — INUMB. В данном случае он равен 1562. Выполнив команду ncheck(1), мы узнаем имя исполняемого файла, соответствующего исследуемому процессу:

$ ncheck -i 1562

/de/root:

1562 /home/andrei/CH3/test

Замещение страниц

Ранние версии UNIX работали на компьютерах PDP-11 с 16-разрядной архитектурой и адресным пространством 64 Кбайт. Некоторые модификации позволяли использовать отдельные адресные пространства для кода и данных, накладывая тем не менее существенные ограничения на размер адресного пространства процесса. Это привело к разработке различных схем программных оверлеев (overlay), использовавшихся как для прикладных задач, так и для ядра операционной системы. Суть этих методов заключается в том, что в неиспользуемые участки адресного пространства процесса записываются другие части программы. Например, после запуска системы необходимость в функциях начальной инициализации отпадает и часть памяти, содержащая этот код, может быть использована для хранения других данных или инструкций операционной системы. Не говоря о значительной сложности такого подхода для разработчиков программного обеспечения, использование этих методов приводило к низкой переносимости программ, поскольку они в значительной степени зависели от конкретной организации памяти. Порой даже расширение оперативной памяти требовало внесения модификаций в программное обеспечение.

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

Рис. 3.11. Управление памятью, основанное на свопинге

Механизм страничного замещения по требованию был реализован в UNIX в 1978 году на новом компьютере VAX-11/780, имевшем 32-разрядную архитектуру, 4 Гбайт адресуемого пространства и аппаратную поддержку страничного механизма. Первой системой UNIX, в которой управление памятью основывалось на страничном замещении по требованию, явилась версия 3.xBSD. Уже в середине 80-х годов все основные версии UNIX обеспечивали страничное замещение в качестве основного механизма, оставляя свопингу вторую роль.

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

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

Рис. 3.12. Управление памятью, основанное на страничном замещении по требованию

Вообще говоря, конкретный механизм страничного замещения зависит от того, как реализованы три основных принципа:

1. При каких условиях система загружает страницы в память, т.н. принцип загрузки (fetch policy).

2. В каких участках памяти система размещает страницы, т.н. принцип размещения (placement policy).

3. Каким образом система выбирает страницы, которые требуется освободить из памяти, когда отсутствуют свободные страницы для размещения (или их число меньше некоторого порогового значения), т.н. принцип замещения (replacement policy).

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

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

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

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

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

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

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

Рис. 3.13. Возможное местонахождение физических страниц процесса

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

Различные версии UNIX используют разные подходы. Например, в SCO UNIX для описания страниц используются структуры pfdat и связанные с ними дескрипторы дисковых блоков. В UNIX 4.3BSD для этого используются поля записи таблицы страниц.

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

□ Размер программы ограничивается лишь размером виртуальной памяти, который для компьютеров с 32-разрядной архитектурой составляет 4 Гбайт.

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

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

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

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

Как и оперативная память, процессор является разделяемым ресурсом, который должен быть справедливо распределен между конкурирующими процессами. Планировщик процессов как раз и является той подсистемой ядра, которая обеспечивает предоставление процессорных ресурсов процессам, выполняющимся в операционной системе. UNIX является системой разделения времени, это означает, что каждому процессу вычислительные ресурсы выделяются на ограниченный промежуток времени, после чего они предоставляются другому процессу и т.д. Максимальный временной интервал, на который процесс может захватить процессор, называется временным квантом (time quantum или time slice). Таким образом создается иллюзия, что процессы выполняются одновременно, хотя в действительности в каждый момент времени выполняется только один (на однопроцессорной системе) процесс.

UNIX является многозадачной системой, а это значит, что одновременно выполняются несколько приложений. Очевидно, что приложения предъявляют различные требования к системе с точки зрения их планирования и общей производительности. Можно выделить три основных класса приложений:

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

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

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

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

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

Обработка прерываний таймера

Каждый компьютер имеет аппаратный таймер или системные часы, которые генерируют аппаратное прерывание через фиксированные интервалы времени. Временной интервал между соседними прерываниями называется тиком процессора или просто тиком (CPU tick, clock tick). Как правило, системный таймер поддерживает несколько значений тиков, но в UNIX это значение обычно устанавливается равным 10 миллисекундам, хотя это значение может отличаться для различных версий операционной системы. Большинство систем хранят это значение в константе HZ, которая определена в файле заголовков <param.h>. Например, для тика в 10 миллисекунд значение HZ устанавливается равным 100.

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

□ Обновление статистики использования процессора для текущего процесса

□ Выполнение ряда функций, связанных с планированием процессов, например пересчет приоритетов и проверку истечения временного кванта для процесса

□ Проверка превышения процессорной квоты для данного процесса и отправка этому процессу сигнала SIGXCPU в случае превышения

□ Обновление системного времени (времени дня) и других связанных с ним таймеров

□ Обработка отложенных вызовов (callout)

□ Обработка алармов (alarm)

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

Часть перечисленных задач не требует выполнения на каждом тике. Большинство систем вводят нотацию главного тика (major tick), который происходит каждые n тиков, где n зависит от конкретной версии системы. Определенный набор функций выполняется только на главных тиках. Например, 4.3BSD производит пересчет приоритетов каждые 4 тика, a SVR4 обрабатывает алармы и производит пробуждение системных процессов раз в секунду.

Отложенные вызовы

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

int co_ID = timeout(void (*fn)(), caddr_t arg, long delta);

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

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

Отложенные вызовы применяются для выполнения многих функций, например:

□ Выполнение ряда функций планировщика и подсистемы управления памятью

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

□ Опрос устройств, не поддерживающих прерывания

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

Эти функции хранятся в системной таблице отложенных вызовов, организация которой отличается для различных версий UNIX. Поскольку просмотр этой таблицы осуществляется каждый тик при обработке высокоприоритетного прерывания, для минимизации влияния этой операции на функционирование системы в целом, организация этой таблицы должна обеспечивать быстрый поиск нужных функций. Например, в 4.3BSD и SCO UNIX таблица отложенных вызовов организована в виде списка, отсортированного по времени запуска. Каждый элемент хранит разницу между временем вызова функции и временем вызова функции предыдущего элемента таблицы. На каждом тике значение этой величины уменьшается на единицу для первого элемента таблицы. Когда это значение становится равным 0, производится вызов соответствующей функции и запись удаляется. На рис. 3.14 приведена схема организации этой таблицы.

Рис. 3.14. Организация таблицы отложенных вызовов

Алармы

Процесс может запросить ядро отправить сигнал по прошествии определенного интервала времени. Существуют три типа алармов — реального времени (real-time), профилирования (profiling) и виртуального времени (virtual time). С каждым из этих типов связан таймер интервала (interval timer, или itimer). Значение itimer уменьшается на единицу при каждом тике. Когда значение itimer достигает нуля, процессу отправляется соответствующий сигнал.

Указанные таймеры обладают следующими характеристиками:

ITIMER_REAL Этот таймер используется для отсчета реального времени. Когда значение таймера становится равным нулю, процессу отправляется сигнал SIGALRM.
ITIMER_PROF Этот таймер уменьшается только когда процесс выполняется в режиме ядра или задачи. Когда значение таймера становится равным нулю, процессу отправляется сигнал SIGPROF.
ITIMER_VIRT Этот таймер уменьшается только когда процесс выполняется в режиме задачи. Когда значение таймера становится равным нулю, процессу отправляется сигнал SIGVTALRM.
В версиях BSD UNIX для установки таймеров всех трех типов используется системный вызов settimer(2), для которого значение таймера устанавливается в микросекундах[34]. Ядро системы преобразует это значение в тики, на основании которых и производится уменьшение таймера. Напомним, что тик является максимальным временным разрешением, которое может обеспечить система. В версиях System V для установки таймера реального времени используется вызов alarm(2), позволяющий указать интервал в секундах. UNIX SVR4 позволяет установить таймеры высокого разрешения с помощью системного вызова hrtsys(2), для которого время указывается в микросекундах. С помощью этого вызова также достигается совместимость с BSD, которая обеспечивается библиотечной функцией settimer(3). Аналогично, в BSD UNIX вызов alarm(3) реализован в виде библиотечной функции.

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

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

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

Контекст процесса

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

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

□ Управляющая информация. Ядро использует две основные структуры данных для управления процессом — proc и user. Сюда же входят данные, необходимые для отображения виртуального адресного пространства процесса в физическое.

□ Окружение процесса. Переменные окружения процесса представляют собой строки пар вида:

 переменная=значение

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

□ Аппаратный контекст. Сюда входят значения общих и ряда системных регистров процессора. К системным регистрам, в частности, относятся:

 • указатель инструкций, содержащий адрес следующей инструкции, которую необходимо выполнить;

 • указатель стека, содержащий адрес последнего элемента стека;

 • регистры плавающей точки;

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

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

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

1. Текущий процесс переходит в состояние сна, ожидая недоступного ресурса.

2. Текущий процесс завершает свое выполнение.

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

4. Происходит пробуждение более высокоприоритетного процесса.

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

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

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

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

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

Каждый процесс имеет два атрибута приоритета: текущий приоритет, на основании которого происходит планирование, и заказанный относительный приоритет, называемый nice number (или просто nice), который задается при порождении процесса и влияет на текущий приоритет.

Текущий приоритет варьируется в диапазоне от 0 (низкий приоритет) до 127 (наивысший приоритет). Процессы, выполняющиеся в режиме задачи, имеют более низкий приоритет, чем в режиме ядра. Для режима задачи приоритет меняется в диапазоне 0–65, для режима ядра — 66–95 (системный диапазон).

Процессы, приоритеты которых лежат в диапазоне 96–127, являются процессами с фиксированным приоритетом, не изменяемым операционной системой, и предназначены для поддержки приложений реального времени[35].

Процессу, ожидающему недоступного в данный момент ресурса, система определяет значение приоритета сна, выбираемое ядром из диапазона системных приоритетов и связанное с событием, вызвавшее это состояние. В табл. 3.3 приведены значения приоритетов сна для систем 4.3BSD UNIX и SCO UNIX (OpenServer 5.0). Заметим, что направление роста значений приоритета для этих систем различно — в BSD UNIX большему значению соответствует более низкий приоритет.


Таблица 3.3. Системные приоритеты сна

Событие Приоритет 4.3BSD UNIX Приоритет SCO UNIX
Ожидание загрузки в память сегмента/страницы (свопинг/страничное замещение) 0 95
Ожидание индексного дескриптора 10 88
Ожидание ввода/вывода 20 81
Ожидание буфера 30 80
Ожидание терминального ввода 75
Ожидание терминального вывода 74
Ожидание завершения выполнения 73
Ожидание события — низкоприоритетное состояние сна 40 66
Когда процесс пробуждается, ядро устанавливает значение текущего приоритета процесса равным приоритету сна. Поскольку приоритет такого процесса находится в системном диапазоне и выше, чем приоритет режима задачи, вероятность предоставления процессу вычислительных ресурсов весьма велика. Такой подход позволяет, в частности, быстро завершить системный вызов, выполнение которого, в свою очередь, может блокировать некоторые системные ресурсы.

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

Текущий приоритет процесса в режиме задачи p_priuser зависит от двух факторов: значения nice number и степени использования вычислительных ресурсов p_cpu:

p_priuser = a*p_nice - b*p_cpu,

где p_nice — постоянная составляющая, зависящая от параметра nice.[36]

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

Каждую секунду ядро пересчитывает текущие приоритеты процессов, готовых к запуску (приоритеты которых меньше 65), последовательно увеличивая их.[37] Это перемещает процессы в более приоритетные очереди и повышает вероятность их последующего запуска.

Например, UNIX версии SVR3, использует следующую формулу:

p_cpu = p_cpu/2

Эта простая схема проявляет недостаток нивелирования приоритетов при повышении загрузки системы. Это происходит потому, что в этом случае каждый процесс получает незначительный объем вычислительных ресурсов и следовательно имеет малую составляющую p_cpu, которая еще более уменьшается благодаря формуле пересчета p_cpu. В результате степень использования процессора перестает оказывать заметное влияние на приоритет, и низкоприоритетные процессы (т.е. процессы с высоким nice number) практически "отлучаются" от вычислительных ресурсов системы.

В 4.3BSD UNIX для пересчета p_cpu используется другая формула:

p_cpu = p_cpu*(2*load)/(2*load+1)

Здесь параметр load равен среднему числу процессов, находившихся в очереди на выполнение за последнюю секунду, и характеризует среднюю загрузку системы за этот период времени. Этот алгоритм позволяет частично избавиться от недостатка планирования SVR3, поскольку при значительной загрузке системы уменьшение p_cpu при пересчете будет происходить медленнее.

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

Как правило, очередь на выполнение не одна. Например, SCO UNIX имеет 127 очередей — по одной на каждый приоритет. BSD UNIX использует 32 очереди, каждая из которых обслуживает диапазон приоритетов, например 0–3, 4–7 и т.д. При выборе следующего процесса на выполнение из одной очереди, т. е. из нескольких процессов с одинаковым текущим приоритетом, используется механизм кругового чередования (round robin).[38] Этот механизм запускается ядром через каждый временной квант для наиболее приоритетной очереди. Однако если в системе появляется готовый к запуску процесс с более высоким приоритетом, чем текущий, он будет запущен, не дожидаясь прошествия временного кванта. С другой стороны, если все процессы, готовые к запуску, находятся в низкоприоритетных по отношению к текущему процессу очередях, последний будет продолжать выполняться и в течение следующего временного кванта.

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

Как уже обсуждалось, в UNIX проведена четкая грань между программой и процессом. Каждый процесс в конкретный момент времени выполняет инструкции некоторой программы, которая может быть одной и той же для нескольких процессов.[39] Примером может служить командный интерпретатор, с которым одновременно работают несколько пользователей, таким образом инструкции программы shell выполняют несколько различных процессов. Такие процессы могут совместно использовать один сегмент кода в памяти, но в остальном они являются изолированными друг от друга и имеют собственные сегменты данных и стека.

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

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

Тем не менее между родительским и дочерним процессом имеется ряд различий:

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

□ Соответственно и идентификатор родительского процесса PPID для родителя и потомка различны.

□ Дочерний процесс получает собственную копию u-area и, в частности, собственные файловые дескрипторы, хотя он разделяет те же записи файловой таблицы.

□ Для дочернего процесса очищаются все ожидающие доставки сигналы.

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

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

Более подробно наследуемые характеристики представлены в табл. 3.4.


Таблица 3.4. Наследование установок при создании процесса и запуске программы

Атрибут Наследование потомком (fork(2)) Сохранение при запуске программы (exec(2))
Сегмент кода (text) Да, разделяемый Нет
Сегмент данных (data) Да, копируется при записи (copy-on-write) Нет
Окружение Да Возможно
Аргументы Да Возможно
Идентификатор пользователя UID Да Да
Идентификатор группы GID Да Да
Эффективный идентификатор пользователя EUID Да Да (Нет, при вызове setuid(2))
Эффективный идентификатор группы EGID Да Да (Нет, при вызове setgid(2))
ID процесса (PID) Нет Да
ID группы процессов Да Да
ID родительского процесса (PPID) Нет Да
Приоритет nice number Да Да
Права доступа к создаваемому файлу Да Да
Ограничение на размер файла Да Да
Сигналы, обрабатываемые по умолчанию Да Да
Игнорируемые сигналы Да Да
Перехватываемые сигналы Да Нет
Файловые дескрипторы Да Да, если для файлового дескриптора не установлен флаг FD_CLOEXEC (например, с помощью fcntl(2))
Файловые указатели Да, разделяемые Да, если для файлового дескриптора не установлен флаг FD_CLOEXEC (например, с помощью fcntl(2))
В общем случае вызов fork(2) выполняет следующие действия:

□ Резервирует место в области свопинга для сегмента данных и стека процесса.

□ Размещает новую запись proc в таблице процессов и присваивает процессу уникальный идентификатор PID.

□ Инициализирует структуру proc (поля структуры proc подробно рассматривались в разделе "Структуры данных процесса").

□ Размещает карты отображения, необходимые для трансляции адреса.

□ Размещает u-area процесса и копирует ее содержимое с родительского.

□ Создает соответствующие области процесса, часть из которых совпадает с родительскими.

□ Инициализирует аппаратный контекст процесса, копируя его с родительского.

□ Устанавливает в ноль возвращаемое дочернему процессу вызовом fork(2) значение.

□ Устанавливает возвращаемое родительскому процессу вызовом fork(2) значение равным PID потомка.

□ Помечает процесс готовым к запуску и помещает его в очередь на выполнение.

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

Для решения данной проблемы используются два подхода. Первый из них, предложенный в UNIX System V, называется "копирование при записи" (copy-on-write или COW). Суть этого подхода заключается в том, что сегменты данных и стека родительского процесса помечаются доступными только для чтения, а дочерний процесс, хотя и получает собственные карты отображения, разделяет эти сегменты с родительским. Другими словами, сразу после создания процесса и родитель и потомок адресуют одни и те же страницы физической памяти. Если какой-либо из двух процессов попытается модифицировать данные или стек, возникнет страничная ошибка, поскольку страница открыта только для чтения, а не для записи. При этом будет запущен обработчик ошибки ядра, который создаст для процесса копию этой страницы, доступную для записи. Таким образом, фактическому копированию подлежат только модифицируемые страницы, а не все адресное пространство процесса. Если дочерний процесс делает системный вызов exec(2) или вообще завершает свое выполнение, права доступа к страницам родителя, имеющим флаг COW, возвращаются к их прежним значениям (т.е. до создания дочернего процесса), а флаг COW очищается.

Другой подход используется в BSD UNIX. В этой версии системы был предложен новый системный вызов — vfork(2). Использование этого вызова имеет смысл, когда дочерний процесс сразу же выполняет вызов exec(2) и запускает новую программу. При вызове vfork(2) родительский процесс предоставляет свое адресное пространство дочернему и переходит в состояние сна, пока последний не вернет его обратно. Далее дочерний процесс выполняется в адресном пространстве родителя, пока не делает вызов exec(2) или exit(2), после чего ядро возвращает адресное пространство родителю и пробуждает его. С помощью vfork(2) можно добиться максимального быстродействия, т.к. в этом случае мы полностью избегаем копирования, даже для карт отображения. Вместо этого адресное пространство родительского процесса предоставляется потомку передачей нескольких аппаратных регистров, отвечающих за трансляцию адресов. Однако vfork(2) таит в себе потенциальную опасность, поскольку позволяет одному процессу использовать и даже модифицировать адресное пространство другого.

Для управления памятью процесса ядру необходимо соответствующим образом задать области. При этом структуры pregion дочернего процесса, соответствующие разделяемым областям, указывают на те же структуры region, что и для родителя. Для областей, совместное использование которых недопустимо, ядро размещает отдельные структуры region для дочернего процесса (изначально копируя их содержимое с родительского) и устанавливает соответствующие указатели. На рис. 3.15 представлена схема этих операций. Заметим, что совместная работа и дублирование областей являются отдельным механизмом, не связанным с рассмотренными выше подходами, для совместного использования адресного пространства, например COW. Так, после создания отдельной копии неразделяемой области она по-прежнему будет адресовать те же страницы памяти, что и соответствующая область родителя.

Рис. 3.15. Создание областей нового процесса

Запуск новой программы

Запуск новой программы осуществляется с помощью системного вызова exec(2). Напомним, что при этом создается не новый процесс, а новое адресное пространство процесса, которое загружается содержимым новой программы. Если процесс был создан вызовом vfork(2), старое адресное пространство возвращается родителю, в противном случае оно просто уничтожается. После возврата из вызова exec(2) процесс продолжает выполнение кода новой программы.

Операционная система UNIX обычно поддерживает несколько форматов исполняемых файлов. Старейший из них — a.out, в разделе "Форматы исполняемых файлов" главы 2 также были рассмотрены форматы COFF и ELF. В любом случае исполняемый файл содержит заголовок, позволяющий ядру правильно разместить адресное пространство процесса и загрузить в него соответствующие фрагменты исполняемого файла.

Перечислим ряд действий, которые выполняет exec(2) для запуска новой программы:

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

□ Считывает заголовок файла и проверяет, является ли файл исполняемым. Вызов exec(2) также распознает скрипты, о которых говорилось в главе 1. При этом он анализирует первую строку скрипта, которая обычно имеет вид #!shellname. В этом случае exec(2) запускает программу, указанную shellname, передавая ей в качестве аргумента имя скрипта. Если исполняемый файл (т.е. файл с установленным атрибутом x) не является бинарным и не содержит в первой строке названия интерпретатора, exec(2) запускает интерпретатор по умолчанию (/bin/sh, /usr/bin/sh, или /usr/bin/ksh, как предписывает стандарт XPG4), передавая ему содержимое файла в качестве ввода.

□ Если исполняемый файл имеет атрибуты SUID или SGID, exec(2) соответствующим образом изменяет эффективные идентификаторы UID и GID для этого процесса.[40]

□ Сохраняет аргументы вызова exec(2) и переменные окружения в адресном пространстве ядра, поскольку адресное пространство процесса будет уничтожено.

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

□ Освобождает старые области процесса и соответствующие области свопинга. Если процесс был создан вызовом vfork(2), старое адресное пространство возвращается родителю.

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

□ Копирует сохраненные аргументы и переменные окружения в новый стек процесса.

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

□ Инициализирует аппаратный контекст процесса. В частности, после этого указатель инструкций адресует точку входа новой программы.

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

Рис. 3.16. Запуск новой программы: а) Адресное пространство процесса до вызова exec(2); б) Уничтожение старого адресного пространства; в) Новое адресное пространство процесса; г) Новое адресное пространство процесса при использовании динамических библиотек

Выполнение в режиме ядра

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

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

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

Системные вызовы позволяют процессам воспользоваться базовыми услугами ядра. Интерфейс системных вызовов определяет ограниченный набор точек входа в ядро системы, обращение к которым изменяет режим выполнения процесса и позволяет выполнять привилегированные инструкции ядра. Стандартная библиотека С, позволяющая использовать системные функции как обычные процедуры, на самом деле содержит заглушки, обеспечивающие фактическую реализацию вызова соответствующей точки входа ядра. Эта реализация существенным образом зависит от аппаратной архитектуры системы. Например, для систем на базе процессоров Intel используются шлюзы (gate). Имеются два типа шлюзов: шлюзы ловушек (trap gate) и шлюзы вызовов (call gate). Для осуществления вызова через шлюз ловушки процесс выполняет команду прерывания, а при работе шлюз вызова — команду межсегментного вызова.

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

Сон и пробуждение

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

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

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

События, в ожидании которых "засыпают" процессы, не являются равноценными.

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

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

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

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

Процесс завершает свое выполнение с помощью функции exit(). Эта функция может быть вызвана системным вызовом exit(2), а если завершение процесса вызвано получением сигнала, функцию exit() вызывает само ядро. Функция exit() выполняет следующие действия:

□ Отключает все сигналы.

□ Закрывает все открытые файлы.

□ Сохраняет статистику использования вычислительных ресурсов и код возврата в записи proc таблицы процессов.

□ Изменяет состояние процесса на "зомби".

□ Делает процесс init(1M) родительским для всех потомков данного процесса.

□ Освобождает адресное пространство процесса, u-area, карты отображения и области свопинга, связанные с процессом.

□ Отправляет сигнал SIGCHLD родительскому процессу, уведомляя его о "смерти" потомка.

□ Пробуждает родительский процесс, если тот ожидает завершения потомка.

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

После завершения выполнения функции exit() процесс находится в состоянии "зомби". При этом от процесса остается запись proc в таблице процессов, содержащая статистику использования вычислительных ресурсов и код возврата. Эта информация может потребоваться родительскому процессу, поэтому освобождение структуры proc производит родитель с помощью системного вызова wait(2) возвращающего статистику и код возврата потомка. Если родительский процесс заканчивает свое выполнение раньше потомка, "родительские права" переходят к процессу init(1M). В этом случае после смерти потомка init(1M) делает системный вызов wait(2) и освобождает структуру proc.

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

Сигналы

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

Группы и сеансы

Группы процессов и сеансы уже обсуждались в главе 2. Такое представление набора процессов используется в UNIX для управления доступом к терминалу и поддержки пользовательских сеансов работы в системе. Перечислим еще раз наиболее важные понятия, связанные с группами и сеансами.

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

□ Управляющий терминал. Процесс может быть связан с терминалом, который называется управляющим. Все процессы группы имеют один и тот же управляющий терминал.

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

Управление сигналами

Сигналы обеспечивают механизм вызова определенной процедуры при наступлении некоторого события. Каждое событие имеет свой идентификатор и символьную константу. Некоторые из этих событий имеют асинхронный характер, например, когда пользователь нажимает клавишу <Del> или <Ctrl>+<C> для завершения выполнения процесса, другие являются уведомлением об ошибках и особых ситуациях, например, при попытке доступа к недопустимому адресу или вызовы недопустимой инструкции. Различные события, соответствующие тем или иным сигналам, подробно рассматривались в главе 2.

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

Отправление сигнала

Ядро генерирует и отправляет процессу сигнал в ответ на ряд событий, которые могут быть вызваны самим процессом, другим процессом, прерыванием или какими-либо внешними событиями. Можно выделить основные причины отправки сигнала:

Особые ситуации Когда выполнение процесса вызывает особую ситуацию, например, деление на ноль, процесс получает соответствующий сигнал.
Терминальные прерывания Нажатие некоторых клавиш терминала, например, <Del>, <Ctrl>+<C> или <Ctrl>+<\>, вызывает отправление сигнала текущему процессу, связанному с терминалом.
Другие процессы Процесс может отправить сигнал другому процессу или группе процессов с помощью системного вызова kill(2). В этом случае сигналы являются элементарной формой межпроцессного взаимодействия.
Управление заданиями Командные интерпретаторы, поддерживающие систему управления заданиями, используют сигналы для манипулирования фоновым и текущими задачами. Когда процесс, выполняющийся в фоновом режиме делает попытку чтения или записи на терминал, ему отправляется сигнал останова. Когда дочерний процесс завершает свою работу, родитель уведомляется об этом также с помощью сигнала.
Квоты Когда процесс превышает выделенную ему квоту вычислительных ресурсов или ресурсов файловой системы, ему отправляется соответствующий сигнал.
Уведомления Процесс может запросить уведомление о наступлении тех или иных событий, например, готовности устройства и т.д. Такое уведомление отправляется процессу в виде сигнала.
Алармы Если процесс установил таймер, ему будет отправлен сигнал, когда значение таймера станет равным нулю.

Доставка и обработка сигнала

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

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

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

Доставка сигнала происходит после того, как ядро от имени процесса вызывает системную процедуру issig(), которая проверяет, существуют ли ожидающие доставки сигналы, адресованные данному процессу. Функция issig() вызывается ядром в трех случаях:

1. Непосредственно перед возвращением из режима ядра в режим задачи после обработки системного вызова или прерывания.

2. Непосредственно перед переходом процесса в состояние сна с приоритетом, допускающим прерывание сигналом.

3. Сразу же после пробуждения после сна с приоритетом, допускающим прерывание сигналом.

Если процедура issig() обнаруживает ожидающие доставки сигналы, ядро вызывает функцию доставки сигнала, которая выполняет действия по умолчанию или вызывает специальную функцию sendsig(), запускающую обработчик сигнала, зарегистрированный процессом. Функция sendsig() возвращает процесс в режим задачи, передает управление обработчику сигнала, а затем восстанавливает контекст процесса для продолжения прерванного сигналом выполнения.

Рассмотрим типичные ситуации, связанные с отправлением и доставкой сигналов. Допустим, пользователь, работая за терминалом, нажимает клавишу прерывания (<Del> или <Ctrl>+<C> для большинства систем). Нажатие любой клавиши вызывает аппаратное прерывание (например, прерывание от последовательного порта), а драйвер терминала при обработке этого прерывания определяет, что была нажата специальная клавиша, генерирующая сигнал, и отправляет текущему процессу, связанному с терминалом, сигнал SIGINT. Когда процесс будет выбран планировщиком и запущен на выполнение, при переходе в режим задачи он обнаружит поступление сигнала и обработает его. Если же в момент генерации сигнала терминальным драйвером процесс, которому был адресован сигнал, уже выполнялся (т.е. был прерван обработчиком терминального прерывания), он также обработает сигнал при возврате в режим задачи после обработки прерывания.

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

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

В первом случае, доставка сигнала будет проверена ядром непосредственно перед переходом процесса в состояние сна. Если такой сигнал поступил, будет вызван обработчик сигнала, а системный вызов, который выполнялся процессом, будет аварийно завершен с ошибкой EINTR. Если генерация сигнала произошла в течение сна процесса, ядро будет вынуждено разбудить его и снять прерванный системный вызов (ошибка EINTR). После пробуждения процесса либо вследствие получения сигнала, либо из-за наступления ожидаемого события, ядром будет вызвана функция issig(), которая обнаружит поступление сигнала и вызовет соответствующую обработку.[41]

Взаимодействие между процессами

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

Для реализации взаимодействия требуется:

□ обеспечить средства взаимодействия между процессами и одновременно

□ исключить нежелательное влияние одного процесса на другой.

Взаимодействие между процессами необходимо для решения следующих задач:

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

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

□ Извещения. Процесс может известить другой процесс или группу процессов о наступлении некоторого события. Это может понадобиться, например, для синхронизации выполнения нескольких процессов.

Очевидно, что решать данную задачу средствами самих процессов неэффективно, а в рамках многозадачной системы — опасно и потому невозможно. Таким образом, сама операционная система должна обеспечить механизмы межпроцессного взаимодействия (Inter-Process Communication, IPC).

К средствам межпроцессного взаимодействия, присутствующим во всех версиях UNIX, можно отнести:

□ сигналы

□ каналы

□ FIFO (именованные каналы)

□ сообщения (очереди сообщений)

□ семафоры

□ разделяемую память

Последние три типа IPC обычно обобщенно называют System V IPC.

Во многих версиях UNIX есть еще одно средство IPC — сокеты, впервые предложенные в BSD UNIX (им посвящен отдельный раздел главы).

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

Каналы

Вспомните синтаксис организации программных каналов при работе в командной строке shell:

cat myfile | wc

При этом (стандартный) вывод программы cat(1), которая выводит содержимое файла myfile, передается на (стандартный) ввод программы wc(1), которая, в свою очередь подсчитывает количество строк, слов и символов. В результате мы получим что-то вроде:

12 45 260

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

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

Для создания канала используется системный вызов pipe(2):

int pipe(int* fildes);

который возвращает два файловых дескриптора — fildes[0] для записи в канал и fildes[1] для чтения из канала. Теперь, если один процесс записывает данные в fildes[0], другой сможет получить эти данные из fildes[1]. Вопрос только в том, как другой процесс сможет получить сам файловый дескриптор fildes[1]?

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

Хотя в приведенном примере может показаться, что процессы cat(1) и wc(1) независимы, на самом деле оба этих процесса создаются процессом shell и являются родственными.

Рис. 3.17. Создание канала между задачами cat(1) и wc(1)

FIFO

Название каналов FIFO происходит от выражения First In First Out (первый вошел — первый вышел). FIFO очень похожи на каналы, поскольку являются однонаправленным средством передачи данных, причем чтение данных происходит в порядке их записи. Однако в отличие от программных каналов, FIFO имеют имена, которые позволяют независимым процессам получить к этим объектам доступ. Поэтому иногда FIFO также называют именованными каналами. FIFO являются средством UNIX System V и не используются в BSD. Впервые FIFO были представлены в System III, однако они до сих пор не документированы и поэтому мало используются.

FIFO является отдельным типом файла в файловой системе UNIX (ls -l покажет символ p в первой позиции, см. раздел "Файлы и файловая система UNIX" главы 1). Для создания FIFO используется системный вызов mknod(2):

int mknod(char *pathname, int mode, int dev);

где pathname — имя файла в файловой системе (имя FIFO),

mode — флаги владения, прав доступа и т.д. (см. поле mode файла),

dev — при создании FIFO игнорируется.

FIFO может быть создан и из командной строки shell:

$ mknod name p

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

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

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

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

3. Если канал пуст и ни один процесс не открыл его на запись, при чтении из канала будет получено 0 байтов. Если один или более процессов открыли канал для записи, вызов read(2) будет заблокирован до появления данных (если для канала или FIFO не установлен флаг отсутствия блокирования O_NDELAY).

4. Запись числа байтов, меньшего емкости канала или FIFO, гарантированно атомарно. Это означает, что в случае, когда несколько процессов одновременно записывают в канал, порции данных от этих процессов не перемешиваются.

5. При записи большего числа байтов, чем это позволяет канал или FIFO, вызов write(2) блокируется до освобождения требуемого места. При этом атомарность операции не гарантируется. Если процесс пытается записать данные в канал, не открытый ни одним процессом на чтение, процессу генерируется сигнал SIGPIPE, а вызов write(2) возвращает 0 с установкой ошибки (errno=ERRPIPE) (если процесс не установил обработки сигнала SIGPIPE, производится обработка по умолчанию — процесс завершается).

В качестве примера приведем простейший пример приложения клиент- сервер, использующего FIFO для обмена данными. Следуя традиции, клиент посылает серверу сообщение "Здравствуй, Мир!", а сервер выводит это сообщение на терминал.

Сервер:
#include <sys/types.h>

#include <sys/stat.h>


#define FIFO "fifo.1"

#define MAXBUFF 80


main() {

 int readfd, n;

 char buff[MAXBUFF]; /* буфер для чтения данных из FIFO */

 /* Создадим специальный файл FIFO с открытыми для всех

    правами доступа на чтение и запись */

 if (mknod(FIFO, S_IFIFO | 0666, 0) < 0) {

  printf("Невозможно создать FIFO\n");

  exit(1);

 }

 /* Получим доступ к FIFO */

 if ((readfd = open(FIFO, O_RDONLY)) < 0) {

  printf("Невозможно открыть FIFO\n");

  exit(1);

 }

 /* Прочитаем сообщение ("Здравствуй, Мир!") и выведем его

    на экран */

 while ((n = read(readfd, buff, MAXBUFF)) > 0)

  if {write(1, buff, n) != n) {

   printf("Ошибка вывода\n");

   exit(1);

  }

 /* Закроем FIFO, удаление FIFO - дело клиента */

 close(readfd);

 exit(0);

}

Клиент:
#include <sys/types.h>

#include <sys/stat.h>


/* Соглашение об имени FIFO */

#define FIFO "fifo.1"


main() {

 int writefd, n;

 /* Получим доступ к FIFO */

 if ((writefd = open(FIFO, O_WRONLY)) < 0) {

  printf("Невозможно открыть FIFO\n");

  exit(1);

 }

 /* Передадим сообщение серверу FIFO */

 if (write(writefd, "Здравствуй, Мир!\n", 18) != 18) {

  printf("Ошибка записи\n");

  exit(1);

 }

 /* Закроем FIFO */

 close(writefd);

 /* Удалим FIFO */

 if (unlink(FIFO) < 0) {

  printf("Невозможно удалить FIFO\n");

  exit(1);

 }

 exit(0);

}

Идентификаторы и имена в IPC

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

Для таких объектов IPC, как очереди сообщений, семафоры и разделяемая память, процесс назначения имени является более сложным, чем просто указание имени файла. Имя для этих объектов называется ключом (key) и генерируется функцией ftok(3C) из двух компонентов — имени файла и идентификатора проекта:

#include <sys/types.h>

#include <sys/ipc.h>


key_t ftok(char* filename, char proj);

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

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

Каждое из перечисленных IPC имеет свой уникальный дескриптор (идентификатор), используемый ОС (ядром) для работы с объектом. Уникальность дескриптора обеспечивается уникальностью дескриптора для каждого из типов объектов (очереди сообщений, семафоры и разделяемая память), т.е. какая-либо очередь сообщений может иметь тот же численный идентификатор, что и разделяемая область памяти (хотя любые две очереди сообщений должны иметь различные идентификаторы).


Таблица 3.5. Идентификация объектов IPC

Объект IPC Пространство имен Дескриптор
Канал Файловый дескриптор
FIFO Имя файла Файловый дескриптор
Очередь сообщений Ключ Идентификатор
Объект IPC Пространство имен Дескриптор
Семафор Ключ Идентификатор
Разделяемая память Ключ Идентификатор
Работа с объектами IPC System V во многом сходна. Для создания или получения доступа к объекту используются соответствующие системные вызовы get: msgget(2) для очереди сообщений, semget(2) для семафора и shmget(2) для разделяемой памяти. Все эти вызовы возвращают дескриптор объекта в случае успеха и -1 в случае неудачи. Отметим, что функции get позволяют процессу получить ссылку на объект, которой по существу является возвращаемый дескриптор, но не позволяют производить конкретные операции над объектом (помещать или получать сообщения из очереди сообщений, устанавливать семафор или записывать данные в разделяемую память. Все функции get в качестве аргументов используют ключ key и флажки создания объекта ipcflag. Остальные аргументы зависят от конкретного типа объекта. Переменная ipcflag определяет права доступа к объекту PERM, а также указывает, создается ли новый объект или требуется доступ к существующему. Последнее определяется комбинацией (или отсутствием) флажков IPC_CREAT и IPC_EXCL.

Права доступа к объекту указываются набором флажков доступа, подобно тому, как это делается для файлов:

Значение PERM (в восьмеричном виде) Аналог прав доступа для файлов Разрешено
0400 r-------- Чтение для владельца-пользователя
0200 -w------- Запись для владельца-пользователя
0040 ---r----- Чтение для владельца-группы
0020 ----w---- Запись для владельца-группы
0004 ------r-- Чтение для всех остальных
0002 -------w- Запись для всех остальных
Комбинацией флажков можно добиться различных результатов:

Значение аргумента ipcflag Результат действия функции
Объект существует Объект не существует
0 Возвращает дескриптор Ошибка: отсутствие объекта (ENOENT)
PERM | IPC_CREAT Возвращает дескриптор Создает объект с соответствующими PERM правами доступа
PERM | IPC_CREAT Ошибка: объект уже существует (EEXIST) Создает объект с соответствующими PERM правами доступа
Работа с объектами IPC System V во многом похожа на работу с файлами в UNIX. Одним из различий является то, что файловые дескрипторы имеют значимость в контексте процесса, в то время как значимость дескрипторов объектов IPC распространяется на всю систему. Так файловый дескриптор 3 одного процесса в общем случае никак не связан с дескриптором 3 другого неродственного процесса (т.е. эти дескрипторы ссылаются на различные файлы). Иначе обстоит дело с дескрипторами объектов IPC. Все процессы, использующие, скажем, одну очередь сообщений, получат одинаковые дескрипторы этого объекта.

Для каждого из объектов IPC ядро поддерживает соответствующую структуру данных, отличную для каждого типа объекта (очереди сообщений, семафора или разделяемой памяти). Общей у этих данных является структура ipc_perm описывающая права доступа к объекту, подобно тому, как это делается для файлов. Основными полями этой структуры являются:

uid Идентификатор владельца-пользователя объекта
gid Идентификатор владельца-группы объекта
cuid UID создателя объекта
cgid GID создателя объекта
mode Права доступа на чтение и запись для всех классов доступа (9 битов)
key Ключ объекта
Права доступа (как и для файлов) определяют возможные операции, которые может выполнять над объектом конкретный процесс (получение доступа к существующему объекту, чтение, запись и удаление).

Заметим, что система не удаляет созданные объекты IPC даже тогда, когда ни один процесс не пользуется ими. Удаление созданных объектов является обязанностью процессов, которым для этого предоставляются соответствующие функции управления msgctl(2), semctl(2), shmctl(2). С помощью этих функций процесс может получить и установить ряд полей внутренних структур, поддерживаемых системой для объектов IPC, а также удалить созданные объекты. Безусловно, как и во многих других случаях использования объектов IPC процессы предварительно должны "договориться", какой процесс и когда удалит объект. Чаще всего, таким процессом является сервер.

Сообщения

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

Данная возможность позволяет процессам обмениваться структурированными данными, имеющими следующие атрибуты:

□ Тип сообщения (позволяет мультиплексировать сообщения в одной очереди)

□ Длина данных сообщения в байтах (может быть нулевой)

□ Собственно данные (если длина ненулевая, могут быть структурированными)

Очередь сообщений хранится в виде внутреннего однонаправленного связанного списка в адресном пространстве ядра. Для каждой очереди ядро создает заголовок очереди (msqid_ds), где содержится информация о правах доступа к очереди (msg_perm), ее текущем состоянии (msg_cbytes — число байтов и msg_qnum — число сообщений в очереди), а также указатели на первое (msg_first) и последнее (msg_last) сообщения, хранящиеся в виде связанного списка (рис. 3.18). Каждый элемент этого списка является отдельным сообщением.

Рис. 3.18. Структура очереди сообщений

Для создания новой очереди сообщений или для доступа к существующей используется системный вызов msgget(2):

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/msg.h>


int msgget(key_t key, int msgflag);

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

□ Помещать в очередь сообщения с помощью функции msgsnd(2);

□ Получать сообщения определенного типа из очереди с помощью функции msgrcv(2);

□ Управлять сообщениями с помощью функции msgctl(2).

Перечисленные системные вызовы манипулирования сообщениями имеют следующий вид:

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/msg.h>


int msgsnd(int msqid, const void *msgp,

 size_t msgsz, int msgflg);

int msgrcv(int msqid, void *msgp,

 size_t msgsz, long msgtyp, int msgflg);

Здесь msgid является дескриптором объекта, полученного в результате вызова msgget(2). Параметр msgtyp указывает на буфер, содержащий тип сообщения и его данные, размер которого равен msgsz байт. Буфер имеет следующие поля:

long msgtype тип сообщения
char msgtext[] данные сообщения
Аргумент msgtyp указывает на тип сообщения и используется для их выборочного получения. Если msgtyp равен 0, функция msgrcv(2) получит первое сообщение из очереди. Если величина msgtyp выше 0, будет получено первое сообщение указанного типа. Если msgtyp меньше 0, функция msgrcv(2) получит сообщение с минимальным значением типа, меньше или равного абсолютному значению msgtyp.

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

Рассмотрим типичную ситуацию взаимодействия процессов, когда серверный процесс обменивается данными с несколькими клиентами. Свойство мультиплексирования позволяет использовать для такого обмена одну очередь сообщений. Для этого сообщениям, направляемым от любого из клиентов серверу, будем присваивать значение типа, скажем, равным 1. Если в теле сообщения клиент каким-либо образом идентифицирует себя (например, передает свой PID), то сервер сможет передать сообщение конкретному клиенту, присваивая тип сообщения равным этому идентификатору.

Поскольку функция msgrcv(2) позволяет принимать сообщения определенного типа (типов), сервер будет принимать сообщения с типом 1, а клиенты — сообщения с типами, равными идентификаторам их процессов. Схема такого взаимодействия представлена на рис. 3.19.

Рис. 3.19. Мультиплексирование сообщений в одной очереди

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

Пример приложения "Здравствуй, Мир!", использующего сообщения:

Файл описания mesg.h
#define MAXBUFF 80

#define PERM 0666


/* Определим структуру нашего сообщения. Она может отличаться

   от структуры msgbuf, но должна содержать поле mtype. В данном

   случае структура сообщения состоит из буфера обмена */

typedef struct our msgbuf {

 long mtype;

 char buff[MAXBUFF];

} Message;

Сервер:
#include <sys/ipc.h>

#include <sys/msg.h>

#include "mesg.h"


main() {

 /* Структура нашего сообщения (может отличаться от

    структуры msgbuf) */

 Message message;

 key_t key;

 int msgid, length, n;


 /* Получим ключ */

 if ((key = ftok("server", 'A')) < 0) {

  printf("Невозможно получить ключ\n");

  exit(1);

 }

 /* Тип принимаемых сообщений */

 message.mt_type = 1L;

 /* Создадим очередь сообщений */

 if ((msgid = msgget(key, РЕRМ | IPC_CREAT)) < 0) {

  printf("Невозможно создать очередь\n");

  exit(1);

 }

 /* Прочитаем сообщение */

 n =

  msgrcv(msgid, &message, sizeof(message), message.mtype, 0);

 /* Если сообщение поступило, выведем его содержимое

    на терминал */

 if (n > 0) {

  if (write(1, message.buff, n) != n) {

   printf("Ошибка вывода\n");

   exit(1);

  }

 } else {

  printf("Ошибка чтения сообщения\n");

  exit(1);

 }


 /* Удалить очередь поручим клиенту */

 exit(0);

}

Клиент:
#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/msg.h>

#include "mesg.h"


main {

 /* Структура нашего сообщения (может отличаться от

    структуры msgbuf */

 Message message;

 key_t key;

 int msgid, length;


 /* Тип посылаемого сообщения, может использоваться для

    мультиплексирования */

 message.mtype = 1L;

 /* Получим ключ */

 if ((key = ftok("server", 'A')) < 0) {

  printf("Невозможно получить ключ\n");

  exit(1);

 }

 /* Получим доступ к очереди сообщений, очередь уже

    должна быть создана сервером */

 if ((msgid = msgget(key, 0)) < 0) {

  printf("Невозможно получить доступ к очереди\n");

  exit(1);

 }

 /* Поместим строку в сообщение */

 if ((length = sprintf(message.buff,

  "Здравствуй, Мир!\n")) < 0) {

  printf("Ошибка копирования в буфер\n");

  exit(1);

 } /* Передадим сообщение */

 if (msgsnd(msgid, (void*)&message, length, 0) != 0) {

  printf("Ошибка записи сообщения в очередь\n");

  exit(1);

 }

 /* Удалим очередь сообщений */

 if (msgctl(msgid, IPC_RMID, 0) < 0) {

  printf("Ошибка удаления очереди\n");

  exit(1);

 }

 exit(0);

}

Семафоры

Для синхронизации процессов, а точнее, для синхронизации доступа нескольких процессов к разделяемым ресурсам, используются семафоры. Являясь одной из форм IPC, семафоры не предназначены для обмена большими объемами данных, как в случае FIFO или очередей сообщений. Вместо этого, они выполняют функцию, полностью соответствующую своему названию — разрешать или запрещать процессу использование того или ино