2.2Реализация процессов в ОС Unix 2.2.1Процесс ОС Unix
Механизм управления и взаимодействия процессов в ОС Unix послужил во многом основой для развития операционных систем в целом, и логического блока управления процессами в частности. Во многом организация управления процессами в ОС Unix является эталонной, рассмотрим ее теперь более детально.
С точки зрения понимания термина процесса в ОС Unix данное понятие можно определить двояко. В первом случае процесс можно определить как объект, зарегистрированный в таблице процессов. Таблица процессов является одной из специальных системных таблиц, которая, очевидно, является программной таблицей. Второе определение объявляет процессом объект, порожденный системным вызовом fork(). Оба определения являются корректными и равносильными (если учесть, что в системе существуют два особых процесса с нулевым и первым номерами, и об их особенностях речь пойдет ниже).
Остановимся сначала на первой трактовке процесса. В операционной системе имеется таблица процессов, размер которой является параметром настройки ОС, и, соответственно, количество процессов в системе является системным ресурсом. Таблица устроена позиционным образом, а это означает, что именование процесса осуществляется посредством номера записи таблицы, соответствующей данному процессу (нумерация строится от нуля до некоторого фиксированного значения). Этот номер записи называется идентификатором процесса (PID — Process Identifier). Как только что отмечалось, две первые записи таблицы предопределены и используются для системных нужд. Соответственно, каждая запись таблицы (Рис. 74.) имеет ссылку на контекст процесса, который структурно состоит из пользовательской, системной и аппаратной составляющих.
Пользовательская составляющая — это тело процесса. В нее входит сегмент кода, который содержит машинные команды и неизменяемые константы. Сегмент кода — это обычно не изменяемая программным способом часть тела процесса. Также в пользовательскую составляющую входит сегмент данных, в который входит область статических данных процесса (в т.ч. статические переменные), область разделяемой памяти (т.е. область памяти, которая может принадлежать двум и более процессам одновременно), а также область стека. На стеке в системе реализуется передача фактических параметров в функциях, реализуются автоматические и регистровые переменные, а также в этой области организуется динамическая память (т.н. куча).
Таблица процессов в ОС Unix.
В ОС Unix реализован такая возможность, как разделение сегмента кода (Рис. 75.). Допустим, в системе работает несколько (пускай, 100) пользователей, каждый из которых помимо прочего работает с одним и тем же текстовым редактором. Таким образом, в системе обрабатываются 100 копий текстового редактора. Ставится вопрос о необходимости держать в ОЗУ все сегменты кода для этих 100 процессов. Для оптимизации подобных ситуаций в ОС Unix используется указанный механизм разделения сегмента кода. Тогда каждый обрабатываемый в системе процесс текстового редактора в пользовательской составляющей хранит ссылку на единственную копию сегмента кода редактора, а сегмент данных у каждого из процессов оказывается своим. Соответственно, в приведенном примере в памяти будут находиться один сегмент кода и 100 сегментов данных. Но рассмотренный механизм может иметь место в ОС только в том случае, когда сегмент кода нельзя изменить: он закрыт на запись.
Разделение сегмента кода.
Аппаратная составляющая включает в себя все регистры, аппаратные таблицы процессора и пр., характеризующие актуальное состояние процесса в момент его выполнения на процессоре.
Системная составляющая содержит системную информацию об идентификации процесса (т.е. идентификация пользователя, сформировавшего процесс), системная информация об открытых и используемых в процессе файлах и пр., а также сохраненные значения аппаратной составляющей. Итак, системная составляющая хранит множество параметров, рассмотрим некоторые из них.
Одними из таких параметров являются реальный и эффективный идентификаторы пользователя-владельца. В ОС Unix формирование процесса считается запуск исполняемого файла на выполнение. Исполняемым считается файл, имеющий установленный соответствующий бит исполнения в правах доступа к нему, при этом файл может содержать либо исполняемый код, либо набор команд для командного интерпретатора. Каждый пользователь системы имеет свой идентификатор (UID — User ID). Каждый файл имеет своего владельца, т.е. для каждого файла определен UID пользователя-владельца. В системе имеется возможность разрешать запуск файлов, которые не принадлежат конкретному пользователю. Большинство команд ОС Unix представляют собой исполняемые файлы, принадлежащие системному администратору (суперпользователю). Таким образом, при запуске файла определены фактически два пользователя: пользователь-владелец файла и пользователь, запустивший файл (т.е. пользователь-владелец процесса). И эта информация хранится в контексте процесса, как реальный идентификатор — идентификатор владельца процесса, и эффективный идентификатор — идентификатор владельца файла. А дальше возможно следующее: можно подменить права процесса по доступу к файлу с реального идентификатора на эффективный идентификатор. Соответственно, если пользователь системы хочет изменить свой пароль доступа к системе, хранящийся в файле, который принадлежит лишь суперпользователю и только им может модифицироваться, то этот пользователь запускает процесс passwd, у которого эффективный идентификатор пользователя — это идентификатор суперпользователя (UID = 0), а реальным идентификатором будет UID данного пользователя. И в этом случае права рядового пользователя заменятся на права администратора, поэтому пользователь сможет сохранить новый пароль в системной таблице (в соответствующем файле).
Итак, следуя второй трактовке, процессом называется объект, порожденный системным вызовом fork(). Выше уже упоминалось определение системного вызова, повторим его. Под системным вызовом понимается средство ОС, предоставляемое пользователям, а точнее, процессам, посредством которого процессы могут обращаться к ядру операционной системы за выполнением тех или иных функций. При этом выполнение системных вызовов происходит в привилегированном режиме (поскольку непосредственную обработку системных вызовов производит ядро), даже если сам процесс выполняется в пользовательском режиме. Что касается реализации системных вызовов, то в одних случаях системный вызов считается специфическим прерыванием, в других случаях — как команда обращения к операционной системе.
2.2.2Базовые средства управления процессами в ОС Unix
Рассмотрим теперь, что происходит при обращении к системному вызову fork(). При обращении процесса к данному системному вызову операционная система создает копию текущего процесса, т.е. появляется еще один процесс, тело которого полностью идентично исходному процессу. Это означает, что система заносит в таблицу процессов новую запись, тем самым новый процесс получает уникальный идентификатор, а также в системе создается контекст для дочернего процесса.
Новый процесс наследует почти все атрибуты исходного родительского процесса, за исключением идентификационной информации (т.е. у дочернего процесса, в частности, свой идентификатор PID и иной идентификатор родительского процесса). Среди прочего дочерний процесс наследует открытые отцовским процессом файлы. На это свойство в ОС Unix опираются многие механизмы. Хотя необходимо отметить, что наследуются необязательно все открытые файлы: если некоторый файл открывался в специальном режиме, то при формировании дочернего процесса этот файл для него будет автоматически закрыт.
#include
#include
pid_t fork(void);
Соответственно, при успешном завершении сыновнему процессу возвращается значение 0, а родительскому процессу — идентификатор порожденного процесса; в случае ошибки возвращается -1, а в переменной errno будет храниться код ошибки. Поскольку дочерний процесс является копией отцовского процесса, то возникает проблема, как отличить, какой из процессов в данный момент обрабатывается. Анализируя результат, возвращаемый системным вызовом fork(), можно определить, что текущий процесс является предком или потомком.
Рассмотрим пример (Рис. 76.). Пускай в системе обрабатывается процесс с идентификатором 2757. В некоторый момент времени этот процесс обращается к системному вызову fork(), в результате чего в системе появляется новый процесс, который, предположим, имеет идентификатор 2760. Сразу оговоримся, что дочерний процесс может получить совершенно произвольный идентификатор, отличный от нуля и единицы (обычно система выделяет новому процессу первую свободную запись в таблице процессов). По выходу из системного вызова fork() процесс 2757 продолжит свое выполнение с первой команды из then-блока, а дочерний процесс 2760 — с первой команды из else-блока. Далее эти процессы ведут себя независимо с точки зрения системного управления процессами: в частности, порядок их обработки на процессоре в общем случае пользователю неизвестен и зависит от той или иной реализованной в системе стратегии планирования времени процессора.
Пример использования системного вызова fork().
Рассмотрим еще один пример. В данном случае используются дополнительно два системных вызова: getpid() для получения идентификатора текущего процесса и getppid() для получения идентификатора родительского процесса. Итак, данный процесс при запуске печатает на экране идентификаторы себя и своего отца, затем производит обращение к системному вызову fork(), после чего и данный процесс, и его потомок снова печатают идентификаторы. Соответственно, на экране в случае успешной обработки всех системных вызовов будут напечатаны три строки.
int main(int argc, char **argv)
{
/* печать PID текущего процесса и PID процесса-предка */
printf("PID=%d; PPID=%d \n", getpid(), getppid());
/* создание нового процесса */
fork();
/* с этого момента два процесса функционируют параллельно и
независимо*/
/* оба процесса печатают PID текущего процесса и PID
процесса-предка */
printf("PID=%d; PPID=%d \n", getpid(), getppid());
}
Редко бывает, когда в процессе происходит обращение лишь к системному вызову fork(). Обычно к нему происходит обращение в связке с одним из семейства системных вызовов exec(). Последние обеспечивают смену тела текущего процесса. В это семейство входят вызовы, у которых в названии префиксная часть обычно представлена как exec, а суффиксная часть служит для уточнения сигнатуры того или иного системного вызова. В качестве иллюстрации приведем определение системного вызова execl().
#include
int execl(const char *path, char *arg0, ..., char *argn, 0);
Параметр path указывает на имя исполняемого файла. Параметры arg0, …, argn являются аргументами программы, передаваемые ей при вызове (это те параметры, которые будут содержаться в массиве argv при входе в программу). При неудачном завершении возвращается -1, а в переменной errno устанавливается код ошибки.
Итак, концептуально все системные вызовы семейства exec() работают следующим образом. Через параметры вызова передается указание на имя некоторого исполняемого файла, а также набор аргументов, которые передаются внутрь при запуске этого исполняемого файла. При выполнении данных системных вызовов происходит замена тела текущего процесса на тело, образованное в результате загрузки исполняемого файла, и управление передается на точку входа в новое тело.
Рассмотрим небольшой пример (Рис. 77.). Запускается процесс (ему ставится в соответствие идентификатор 2757), который обращается к системному вызову execl(), для смены своего тела телом команды ls -l, которая отображает содержимое текущего каталога. Реализация данной команды хранится, соответственно, в файле /bin/ls. После успешного завершения системного вызова execl() процесс (с тем же идентификатором 2757) будет содержать реализацию команды ls, и управление в нем будет передано на точку входа (т.е. запустится функция main()).
При обращении к системным вызовам семейства exec() сохраняются основные атрибуты текущего процесса (в частности, идентификатор процесса, идентификатор родительского процесса, приоритет и др.), а также сохраняются все открытые в текущем процессе файлы (за исключением, быть может, файлов, открытых в специальном режиме). С другой стороны, изменяются режимы обработки сигналов, эффективные идентификаторы владельца и группы и прочая системная информация, которая должна корректироваться при смене тела процесса.
Пример использования системного вызова execl().
Приведем ряд примеров для иллюстрации применения различных вызовов семейства exec().
Пример. Если обращение к системному вызову будет неуспешным, то функция printf() отобразит на экране соответствующий текст.
#include
int main(int argc, char **argv)
{
...
/*тело программы*/
...
execl(“/bin/ls”, ”ls”, ”-l”, (char*)0);
/* или execlp(“ls”, ”ls”, ”-l”, (char*)0); */
printf(“это напечатается в случае неудачного обращения к предыдущей функции, к примеру, если не был найден файл ls \n”);
...
}
Пример. Вызов C-компилятора. В данном случае второй параметр — вектор из указателей на параметры строки, которые будут переданы в вызываемую программу. Как и ранее, первый указатель — имя программы, последний — нулевой указатель. Эти вызовы удобны, когда заранее неизвестно число аргументов вызываемой программы.
int main(int argc, char **argv)
{
char *pv[]={“cc”, “-o”, “ter”, “ter.c”, (char*)0};
...
/*тело программы*/
...
execv (“/bin/cc”, pv);
...
}
Итак, мы рассмотрели по отдельности системные вызовы fork() и exec(), но в ОС Unix обычно применяется связка вызовов fork-exec.
Для иллюстрации сказанного рассмотрим еще один пример. В данном случае родительский процесс (PID = 2757) порождает своего потомка посредством обращения к системному вызову fork(), после чего в отцовском процессе управление переходит на else-блок. В то же время в дочернем процессе (PID = 2760) управление передается на первую инструкцию then-блока, где происходит обращение к системному вызову execl(). После чего тело дочернего процесса меняется на тело команды ls.
Пример использования схемы fork-exec.
Рассмотрим еще один пример. Программа порождает три процесса, каждый из которых запускает программу echo посредством системного вызова exec(). Данный пример демонстрирует важность проверки успешного завершения системного вызова exec(), в противном случае возможно исполнение нескольких копий исходной программы. В нашем случае, если все вызовы exec() проработают неуспешно, то копий программ будет восемь. Если все вызовы exec() будут успешными, то после последнего вызова fork() будет существовать четыре копии процесса. В каком порядке они пойдут на выполнение предсказать трудно.
int main(int argc, char **argv)
{
if(fork() == 0)
{
execl(“/bin/echo”,”echo”,”это”,”сообщение один”,NULL);
printf(“ошибка”);
}
if(fork() == 0)
{
execl(“/bin/echo”,”echo”,”это”,”сообщение два”,NULL);
printf(“ошибка”);
}
if(fork() == 0)
{
execl(“/bin/echo”,”echo”,”это”,”сообщение три”,NULL);
printf(“ошибка”);
}
printf(“процесс-предок закончился”);
}
Результат работы может быть следующим:
процесс-предок закончился
это сообщение три
это сообщение один
это сообщение два
Теперь рассмотрим системные вызовы, которые сопутствуют базовым системным вызовам управления процессами в ОС Unix. Прежде всего, речь пойдет о завершении процесса. Вообще говоря, процесс может завершиться по одной из двух причин. Первая причина связана с возникновением в процессе сигнала. Сигнал можно считать программным аналогом прерывания, и речь о них пойдет ниже при обсуждении вопросов взаимодействия процессов. Сигнал может быть связан с тем, что в процессе произошло деление на ноль, или сигнал может прийти от другого процесса с указанием незамедлительного завершения. Вторая причина связана с обращением к системному вызову завершения процесса. При этом обращение может быть явным, когда в теле программы встречается обращение к системному вызову _exit(), или неявным, если происходит выполнение оператора return языка C внутри функции main(). В последнем случае компилятор заменит действие оператора return обращением к системному вызову _exit().
#include
void _exit(int status);
Системный вызов exit() не возвращает никакого значения, поскольку он всегда прорабатывает. А через его единственный параметр status возвращается т.н. программный код завершения. Это значение передается операционной системе как код завершения программы. В принципе значение этой переменной может быть произвольным, но в системе есть договоренность, что возврат нулевого значения сигнализирует об успешном завершении процесса, остальные значения трактуются как ошибочное завершение (в частности, процесс может возвращать некий код ошибки).
Рассмотрим, что происходит с процессом и в системе при обращении к системному вызову exit(). Очевидно, что сиюминутно процесс не может завершиться, поэтому процесс переходит в переходное состояние — т.н. состояние зомби. При этом выполняется целая совокупность действий в системе, связанных с завершением процесса. Во-первых, корректно освобождаются ресурсы (закрываются файлы, освобождаются оперативная память и пр.). Во-вторых, поскольку ОС Unix является «семейственной» системой (у каждого процесса может быть целая иерархия потомков), стоит проблема, какой процесс считать отцовским после завершения данного родительского процесса, и в ОС Unix принято решение, что все сыновние процессы усыновляются процессом с номером 1. И, наконец, процессу-предку от данного завершаемого процесса передается сигнал SIGCHLD, но в большинстве случаев его игнорируют.
Симметричную картину иллюстрирует системный вызов wait(), который обеспечивает в процессе получение информации о факте завершения одного из его потомков.
#include
#include
pid_t wait(int *status);
Обычно при обращении к системному вызову wait() возможны следующие варианты. Во-первых, если до обращения к этому системному вызову какие-то сыновние процессы уже завершились, то процесс получит информацию об одном из этих процессов. Если же у процесса нет дочерних процессов, то, обращаясь к системному вызову wait(), процесс сразу получит соответствующий код ответа. В-третьих, если у процесса имеются дочерние процессы, но ни один из них не завершился, то при обращении к указанному системному вызову данный отцовский процесс будет блокирован до завершения одного из своих сыновних процессов.
По факту завершения одного из процессов родительский процесс при обращении к системному вызову wait() получает следующую информацию. В случае успешного завершения возвращается идентификатор PID завершившегося процесса, или же -1 — в случае ошибки или прерывания. А через параметр status передается указатель на целочисленную переменную, в которой система возвращает процессу причины завершения сыновнего процесса. Данный параметр содержит в старшем байте код завершения процесса-потомка (пользовательский код завершения процесса), передаваемый в качестве параметра системному вызову exit(), а в младшем байте — индикатор причины завершения процесса-потомка, устанавливаемый ядром ОС Unix (системный код завершения процесса). Системный код завершения хранит номер сигнала, приход которого в сыновний процесс вызвал его завершение.
Необходимо сделать замечание, касающееся системного вызова wait(). Данный системный вызов не всегда отрабатывает на завершении дочернего процесса. В случае если отцовский процесс производит трассировку сыновнего процесса, то посредством системного вызова wait() можно фиксировать факт приостановки сыновнего процесса, причем сыновний процесс после этого может быть продолжен (т.е. не всегда он должен завершиться, чтобы отцовский процесс получил информацию о сыне). С другой стороны, имеется возможность изменить режим работы системного вызова wait() таким образом, чтобы отцовский процесс не блокировался в ожидании завершения одного из потомков, а сразу получал соответствующий код ответа.
И, наконец, отметим, что после передачи информации родительскому процессу о статусе завершения все структуры, связанные с процессом-зомби, освобождаются, и удаляется запись о нем из таблицы процессов.
Рассмотрим пример использования системного вызова wait(). В данном случае приводится текст программы, которая последовательно запускает программы, имена которых указаны при вызове.
#include
int main(int argc, char **argv)
{
int i;
for (i=1; i
{
int status;
if(fork() > 0)
{
/* процесс-предок ожидает сообщения
от процесса-потомка о завершении */
wait(&status);
printf(“process-father\n”);
continue;
}
execlp(argv[i], argv[i], 0);
exit();
}
}
Пусть существуют три исполняемых файла print1, print2, print3, каждый из которых только печатает текст first, second, third соответственно, а код вышеприведенного примера находится в исполняемом файле с именем file. Тогда результатом работы команды
file print1 print2 print3
будет:
first
process-father
second
process-father
third
process-father
Рассмотрим еще один пример. В данном примере процесс-предок порождает два процесса, каждый из которых запускает команду echo. Далее процесс-предок ждет завершения своих потомков, после чего продолжает выполнение. В данном случае wait() вызывается в цикле три раза: первые два ожидают завершения процессов-потомков, последний вызов вернет неуспех, ибо ждать более некого.
int main(int argc, char **argv)
{
if ((fork()) == 0) /*первый процесс-потомок*/
{
execl(“/bin/echo”,”echo”,”this is”,”string 1”,0);
exit();
}
if ((fork()) == 0) /*второй процесс-потомок*/
{
execl(“/bin/echo”,”echo”,”this is”,”string 2”,0);
exit();
}
/*процесс-предок*/
printf(“process-father is waiting for children\n”);
while(wait() != -1);
printf(“all children terminated\n”);
exit();
}
2.2.3Жизненный цикл процесса. Состояния процесса
Рассмотрим обобщенную и несколько упрощенную схему жизненного цикла процессов в ОС Unix (Рис. 79.). Можно выделить целую совокупность состояний, в которых может находиться процесс.
Жизненный цикл процессов.
Начальное состояние — это состояние создания процесса: после обращения к системному вызову fork() создается новый процесс в системе (еще раз отметим, что иных способов создать процесс в ОС Unix не существует), который попадает в БВП (о котором речь шла выше). В ОС Unix БВП состоит из одного процесса, который после создания попадает в БОП. Итак, после создания процесса он получает статус, что он готов к выполнению. Из этого состояния по решению планировщика он может переходить в состояние выполнения, а затем обратно в состояние готовности к выполнению в случае исчерпания кванта времени обработки на процессоре. В состоянии выполнения процесс может работать как в пользовательском режиме, так и в режиме ядра, или супервизора. В режиме ядра процесс работает при обращении к системному вызову, когда ядро выполняет некоторые действия для конкретного процесса.
Затем из режима выполнения процесс может перейти в состояние блокировки. В этом состоянии процесс находится, ожидая завершения некоторого действия: например, ожидая завершения внешнего взаимодействия. Соответственно, по возникновению соответствующего события процесс переходит из состояния блокировки в состояние готовности к выполнению.
Посредством обращения к системному вызову exit() процесс переходит из состояния выполнения в состояние зомби, а после получения отцовским процессом информации о завершении данного процесса он завершает свой жизненный цикл.
Итак, мы рассмотрели упрощенную модель. Главным упрощением в ней можно считать отсутствие свопинга — отсутствие откачки процесса во внешнюю память.
2.2.4Формирование процессов 0 и 1
Все механизмы взаимодействия процессов в ОС Unix унифицированы и основываются на связке системных вызовов fork-exec. Абсолютно все процесс в ОС Unix создается по приведенной схеме, но существуют два процесса с номерами 0 и 1, которые являются исключениями из данного правила.
Рассмотрим детально, как формируются данные процессы, но для этого необходимо разобраться, что происходит в системе при включении компьютера. Практически во всех компьютерах имеется область памяти, способная постоянно хранить информацию — т.н. постоянное запоминающее устройство (ПЗУ). В этой области памяти находится т.н. аппаратный загрузчик компьютера. Данный загрузчик в общем случае имеет информацию о перечне и приоритетах системных устройств компьютера, которые априори могут содержать операционную систему. Приоритет определяет тот порядок, в котором аппаратный загрузчик осуществляет перебор устройств по списку в поисках программного загрузчика операционных систем. Обычно в нулевом блоке системного устройства находится т.н. программный загрузчик, который может содержать информацию о наличии в различных разделах системного устройства различных операционных систем. Раздел системного устройства — это последовательность блоков (выделенная на внешнем запоминающем устройстве), внутри которых используется виртуальная нумерация этих блоков, т.е. каждый раздел начинается с нулевого блока. Соответственно, если операционных систем несколько, то программный загрузчик может предложить пользователю компьютера выбрать, какую систему загружать. После этого программный загрузчик обращается к соответствующему разделу данного системного устройства и из нулевого блока выбранного раздела считывает загрузчик конкретной операционной системы, после чего начинает работать программный загрузчик конкретной ОС. Этот загрузчик, в свою очередь, «знает» структуру раздела, структуру файловой системы и находит в соответствующей файловой системе файл, который должен быть запущен в качестве ядра операционной системы.
Что касается Unix-систем, то указанный загрузчик ОС осуществляет поиск, считывание в память и запуск на исполнение файла /unix, который содержит исполняемый код ядра ОС Unix. Рассмотрим теперь действия ядра при запуске.
Первым делом происходит инициализация системы, которая включает в себя установку начальных параметров в аппаратных интерфейсах: установку системных часов, установка диспетчера оперативной памяти, установка средств защиты оперативной памяти. Затем, исходя из параметров настройки операционной системы, осуществляется формирование системных структур данных (в частности, создается таблица процессов). После этого ядро создает нулевой процесс. Отметим, что здесь мы оперируем определением процесса в ОС Unix: ядро формирует нулевую запись в таблице процессов, и более ничего, — это и есть создание нулевого процесса. Этот нулевой процесс в общем случае соответствует ядру (это процесс ядра), но этот процесс имеет особенность: он не имеет сегмента кода. Это означает, что нулевая запись таблицы процессов ссылается на контекст, в котором отсутствует ссылка на сегмент кода процесса. Нулевой процесс существует на всем протяжении функционирования ОС, причем он иллюстрирует нештатное формирование процесса в системе.
Формирование нулевого и первого процессов.
Следующим этапом ядро начинает формирование первого процесса, который также создается нестандартным образом, при этом выполняются следующие действия. Ядро осуществляет копирование нулевой записи в первую. После чего для первой записи выделяется пространство оперативной памяти и создается тело процесса. В тело процесса записывается код системного вызова exec(), после этого происходит внутри первого процесса обращение к этому системному вызову с параметром /etc/init. Таким образом, можно отметить, что сам первый процесс формируется нестандартным путем, но его тело его в конце уже формируется «правильным» образом посредством вызова exec().
Итак, в итоге в рамках первого процесса сформирован процесс init, который существует в системе также на протяжении всего ее функционирования. Процесс init поддерживает соответствующую стратегию организации работы системы: либо это однопользовательская система, либо многопользовательская. Эта стратегия определяется параметрами, которые возникают на стадии загрузки ядра и инициализации системы. Соответственно, система опознает один из подключенных терминалов как системную консоль. Если система однопользовательская, то происходит подключение интерпретатора команд к системной консоли. Если же режим многопользовательский, то процесс init обращается к системной таблице терминалов, хранящей все терминальные устройства, которые могут быть в системе, и для каждого готового к работе терминала из этого перечня он запускает процесс getty. Процесс getty — это процесс, который обеспечивает работу конкретного терминала. Заметим, что процесс init создает процесс getty уже стандартным способом, и после вообще все процессы создаются лишь по схеме fork-exec.
Инициализация системы.
После старта процесс getty печатает на экране приглашение ввести логин (Рис. 82.). После того, как пользователь вводит логин, процесс getty загружает на свое место программу login. Соответственно, программа login запрашивает ввода пароля, который после ввода и проверяет. В первых версиях ОС Unix все пароли хранились в зашифрованном виде в файле passwd. Если введенный пароль оказывается верным, программа login загружает параметры работы конкретного пользователя, загружает интерпретатор команд (shell), и пользователь может начинать работать в системе. Заметим, что тип загружаемого интерпретатора команд также задается среди параметров работы данного пользователя. А, вообще говоря, в настройках вместо интерпретатора команд может присутствовать любой исполняемый файл, например, это может быть менеджер по обслуживанию СУБД, функционирующей в системе.
Сеанс работы пользователя с системой представляется в виде файла, с которым происходят операции чтения и записи. Соответственно, работа с системой заканчивает закрытием файла — подачей символа EOF (end of file), этот код нажатия комбинации клавиш Ctrl+D на клавиатуре. После передачи этого символа интерпретатор завершается. Как только оказывается, с терминалом не связан ни один процесс, процесс init запускает новый процесс getty, который ассоциируется с этим терминалом, который, в свою очередь, снова печатает на экране приглашение ввести логин.
Схема работы пользователя с ОС Unix.
|
