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

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

В Solaris стандартный планировщик задач (диспетчер) старается предоставить процессам, которые по умолчанию запускаются с классом планирования timesharing (в режиме с разделением времени) примерно одинаковый доступ к процессору. Однако, если на самом деле некоторые процессы в системе более важны, чем другие (сервер баз данных, веб-сервер крупного портала и т.п.), можно использовать другой метод планирования, а именно долевое распределение (fair share scheduler – FSS). В этом случае можно будет назначить группам процессов разные "порции" процессорного времени, которые те будут получать в единицу времени. Грубо говоря, можно потребовать от планировщика отдать 70% времени веб-серверу, а 30% – всем остальным процессам. Если этого не сделать, время будет делиться поровну. Кроме соответствующего алгоритма, в Solaris начиная с версии Solaris 9 появился новый класс планирования, который тоже называется планированием на основе долевого распределения.

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

Более детальное описание этой возможности дано по адресу http://docs.sun.com/db/doc/816-4882/6mb2ipq5n?q=scheduling+class&a=view

В лекции 5 курса "Системное администрирование ОС Solaris 10" показано, как использовать планирование на основе долевого распределения для управления ресурсами системы.

Распределение памяти. Swaping

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

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

Традиционно в литературе по системам UNIX для описания процесса обмена страницами между памятью и диском используетcя термин "свопинг" (swaping). Этот термин в действительности означает полную выгрузку страниц процесса на диск. На самом деле менеджер виртуальной памяти в UNIX обычно выполняет "пейджинг" (paging), что означает постраничную (частичную) выгрузку процесса на диск. Свопинг выполняется в том случае, если памяти критически не хватает, что при нормальной работе системы не наблюдается.

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

Более подробно алгоритм работы менеджера виртуальной памяти рассмотрен в лекции 8 курса "Системное администрирование ОС Solaris 10".

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

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

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

Доступ процессов к файлам

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

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

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

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

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

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

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

Идея в том, чтобы право записи в /etc/shadow дать не конкретному пользователю, а программе passwd (как нам известно, пароль меняет именно эта программа). К сожалению, в UNIX нет механизма, который позволяет давать какие-либо права отдельному процессу или приложению. Поэтому право записи в /etc/shadow дали пользователю root (назначив его владельцем этого файла и разрешив запись в файл владельцу – вы помните, как это сделать с помощью chmod?), а программу passwd разрешили всем запускать от имени ее владельца – root.

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

Как мы помним, полный вид слова прав доступа таков:

Старшие три бита –SUID (su), SGID (sg) и sticky bit (t).

Suid и Sgid

Установить бит suid или sgid можно, указав chmod права доступа в числовом виде:

chmod 4755 файл

или мнемоническом виде:

chmod u+s файл

В некоторых системах UNIX доступна только одна из этих двух форм.

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

В выводе команды ls файлы с установленными битами SUID и SGID отличаются от прочих тем, что в поле, где обычно стоит "x" (бит выполняемости), оказывается символ "s":

-r-xr-sr-x    1 root   tty   10040 Nov  4  2002 /usr/sbin/wall
-r-sr-sr-x    1 root   sys   22168 Nov  4  2002 /usr/bin/passwd

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

dr-Sr-xr-x    2 root   other   512 May 10 01:48 enum
-rw-r--r--    1 root   other     0 May 10 01:47 q

Обратите внимание на права доступа к каталогу enum. Объяснение смысла SUID/SGID для каталога дано в "Устройство и администрирование файловой системы UFS" .

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

find / -perm –u+s

а файлы с установленным битом SGID – по команде

find / -perm –g+s

Относитесь внимательно к файлам, права доступа к которым разрешают запускать их от чужого имени. Появление таких файлов в системе может облегчить жизнь взломщику. Программа passwd, например, написана таким образом, что запускающий ее пользователь точно не сможет с ее помощью сделать ничего, кроме изменения собственного пароля. Поэтому ей можно доверить запускаться с правами root'a. Где гарантия, что все остальные программы с установленным SUID такие же? Устанавливайте бит suid только тем программам, которым доверяете на все сто!

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

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

Интерактивные и фоновые процессы

Процесс в UNIX может быть интерактивным и фоновым. Процесс, который имеет доступ к вводу с терминала и к выводу на него, называется интерактивным (foreground). Таким процессом является почтовая программа mail, редактор текста vi и другие программы. Фоновый процесс не имеет доступа к вводу с терминала и имеет условный доступ к выводу на терминал. Условие состоит в том, что вывод на терминал разрешен фоновому процессу, если терминал настроен для работы в режиме -tostop. Эту настройку можно выполнить командой

stty -tostop

Обратная настройка выполняется командой

stty tostop

Если фоновый процесс пытается выводить что-либо на терминал, настроенный для работы в режиме tostop, то процессу посылается сигнал SIGSTOP. Процесс, получивший такой сигнал, останавливается (переводится в состояние STOPPED).

Для запуска фонового процесса из командного интерпретатора следует дать команду, завершив ее знаком "&" (амперсэнд):

команда &

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

make all &