Unix Programming Lecture 01

Программирование под OS UNIXРоманенко В.А

Лекция №1

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

представлена на рис. 1.

Рис. 1. Модель системы UNIXВ центре находится ядро системы (kernel). Ядро непосредственно взаимодействует с

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

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

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

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

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

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

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

int fd;char buf[80]; fd = open("file", O_RDONLY); /*Oткроем файл — получим

дескриптор fd*/


read(fd, buf, sizeof(buf)); /*Считаем в буфер buf 80 символов*/

close(fd); /*Закроем файл*/Структура ядра представлена на рис 2.

Рис. 2. Внутренняя структура ядра UNIXЯдро состоит из трех основных подсистем:1. Файловая подсистема2. Подсистема управления процессами и памятью3. Подсистема ввода/вывода

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

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

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

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

Подсистема управления процессамиЗапущенная на выполнение программа порождает в системе один или более

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

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

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


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

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

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

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

Подсистема ввода/выводаПодсистема ввода/вывода выполняет запросы файловой подсистемы и подсистемы

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

Работа в операционной системе UNIXФайлы и файловая система

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

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

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


накопителя, CD-ROM или удаленного компьютера в сети), на котором он фактически хранится.

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

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

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

Обычный файл (regular file) Каталог (directory) Специальный файл устройства (special device file) FIFO или именованный канал (named pipe) Связь (link) Сокет

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

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

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

/home/user

Номер inode Имя файла

17374128383432443454

.

..file01file02


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

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

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

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

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

Например, с помощью команды 1п(1) мы можем создать еще одно имя файла, на который указывает имя file01 (рис. 3).

$ In file01 /home/user/file02 Изменения, внесенные в любой из этих файлов, затронут и другой, поскольку оба

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

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

Команда 1п(1) с ключом -s позволяет создать символическую связь:$ In –s file01 /home/user/symfile01

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

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

часто используется для доступа к сети TCP/IP. В системах, ветви BSD UNIX на базе


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

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

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

1 2 3 4 5 6 7 8rw- r-- r-- 1 andy group 235520 Dec 22 19:13 pride,tarrw- rwr r-- 1 andy student 3450 Nov 12 19:13 exams, quest

Владельцем-пользователем вновь созданного файла является пользователь, который создал файл.

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

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

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

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

User access (u) Для владельца пользователя файла Group access (g) Для членов группы, являющейся владельцем файла Other access (о) Для остальных пользователей (кроме суперпользователя)

UNIX поддерживает три типа прав доступа для каждого класса: Read (r) Для чтенияWrite (w) Для записиExecute (х) Для исполнения

Права доступа могут быть изменены только владельцем файла или супер-пользователем (superuser) — администратором системы. Для этого используется команда chmod(l). Ниже приведен общий формат этой команды.


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

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

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

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

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

Существует способ несколько обезопасить себя в случае, когда необходимо предоставить право на запись другим пользователям, — установка флага Sticky bit на каталог.

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

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

Дополнительные атрибуты также устанавливаются утилитой chmod(l).

Таблица 1. Дополнительные атрибуты для обычных файловКод Название Значениеt Sticky bit Сохранить образ выполняемого файла в памяти

после завершения выполненияS Set UID, SUID Установить DID процесса при выполненииS Set GID, SGID Установить GIO процесса при выполнении


1 Блокирование Установить обязательное блокирование файлаУстановка атрибута Sticky bit (действительное название — save text mode) редко

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

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

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

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

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

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

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

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

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

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

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

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

Системными процессами являются: shed (диспетчер свопинга), vhand (диспетчер страничного замещения), bdfflush (диспетчер буферного кэша) и kmadaemon (диспетчер памяти ядра).


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

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

Прикладные процессыК прикладным процессам относятся все остальные процессы, выполняющиеся в

системе. Как правило, это процессы, порожденные в рамках пользовательского сеанса работы. Например, запуск команды ls(l) породит соответствующий процесс этого типа.

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

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

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

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

Атрибуты процессаПроцесс в UNIX имеет несколько атрибутов, позволяющих операционной системе

эффективно управлять его работой.1. Идентификатор процесса Process ID ( PID )

Каждый процесс имеет уникальный идентификатор PID, позволяющий ядру системы различать процессы. 2. Идентификатор родительского процесса Parent Process ID ( PPID )

Идентификатор процесса, породившего данный процесс.3. Приоритет процесса ( Nice Number )

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


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

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

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

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

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

Жизненный путь процессаПроцесс в UNIX создается системным вызовом fork(2). Процесс, сделавший вызов

fork(2) называется родительским, а вновь созданный процесс — дочерним. Новый процесс является точной копией породившего его процесса и имеет те же

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

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

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

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

Рассмотрим эту схему на примере.1. Пользователь, работая в командном режиме (в командном интерпретаторе shell)

запускает команду ls(l). 2. Текущий процесс (shell) делает вызов fork(2), порождая вторую копию shell. 3. В свою очередь, порожденный shell вызывает ехес(2), указывая в качестве

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

4. Код ls(l) замещает код порожденного shell, и утилита ls(l) начинает вы-полняться.

5. По завершении работы ls(l) созданный процесс "умирает". Пользователь вновь возвращается в командный режим.


Описанный процесс представлен на рис. 4.

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

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

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

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

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

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

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

Для отправления сигнала служит команда kill(l):kill sig_no pidгде sig-no — номер или символическое название сигнала, a pid — идентификатор

процесса, которому посылается сигнал.


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

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

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

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

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

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

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

$ kill -9 pid

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

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

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

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

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

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

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


Пользователи системыС точки зрения системы, пользователь — не обязательно человек. Пользователь

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

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

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

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

Атрибуты пользователяКак правило, все атрибуты пользователя хранятся в файле /etc/passwd. В конечном

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

Unix Programming Lecture 01

Documents