Планировщик задач на Linux

Рассмотрим теперь блокировку сигналов. Поскольку игнорирование сигнала устанавливается функцией sigaction (), можно было бы ожидать, что и блокировка устанавливается этой же функцией, но это не так. Так как зачастую программисту приходится блокировать несколько сигналов сразу, для блокировки существует специальная функция sigprocmask (2), которая оперирует наборами сигналов (signalsets). Разделение интерфейса между несколькими функциями вызвано еще и требованиями многопоточности. Параметры, устанавливаемые sigaction (), действительны для всей программы в целом, тогда как блокировку сигналов потоки осуществляют независимо друг от друга. Наборы сигналов хранятся в переменных специального типа sigset_t, а операции над ними осуществляются с помощью специальных функций. Функция sigemptyset () инициализирует набор сигналов пустыми значениями, а функция sigfillset () устанавливает все возможные значения в наборе.

Используемая нами функция sigaddset () добавляет значение сигнала в набор, а функция sigdelset () удаляет сигнал из набора. После того как набор сигналов сформирован, мы передаем его функции sigprocmask (), которая выполняет блокирование и разблокирование сигналов. Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной командыkill -s 1 <PID>, где PID — идентификатор процесса. Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом.

Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном программировании, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX-системах существует специальная функция sigwait (3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов. Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUPsigprocmask (SIG_BLOCK, &newset, 0);while (!sigwait (&newset, &sig))printf («SIGHUP recievedn»);Первым параметром функции sigwait () является указатель на набор сигналов, получения которых будет ждать функция.

Во втором параметре sigwait () вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait (), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask (), иначе, при получении сигнала, вместо выхода из sigwait () будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait (), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait () возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом. Для генерации сигналов в Unix предусмотрены две функции — kill (2) и raise (3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill ()совпадает с семантикой одноименной команды ОС.

У функции kill ()два аргумента -PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill ()как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов. Таблица 2. Поведение функции kill ()в зависимости от значения PIDУсловие.

ДействиеPID > 1Сигнал посылается процессу с соответствующим PID. PID == 0Сигнал посылается всем процессам из той же группы что и процесс-источник.PID < 0Сигнал посылается всем процессам, чей идентификатор группы равен абсолютному значению PID. PID == 1Сигнал посылается всем процессам системы. Вызовraise (sig)эквивалентенвызовуkill (getpid (), sig). Так же как и для других примитивов IPC, для сигналов действует система прав доступа, основанная на правах доступа владельцев процессов. Процесс-приемник получит сигнал только в том случае, если у процесса-источника есть соответствующие права. С помощью функции kill ()можно проверить, существует ли в системе процесс с заданным PID, не посылая процессу никаких сигналов. Для этого предназначен псевдо-сигнал с номером 0. Если соответствующего процесса не существует, функция kill ()вернет значение 1, соответствующее об ошибке. В любом случае, сигнал не будет отправлен.

2.3. Создание копии процесса.

В Unix-системах, fork () системный вызов, создающий новый процесс (потомок), который является практически полной копией процесса-родителя, выполняющего этот вызов. Между процессом-потомком и процессом-родителем существуют различия: PID процесса-потомка отличен от PID процесса-родителя;

значению PPID процесса-потомка присваивается значение PID процесса-родителя;

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

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

временная статистика выполнения процесса-потомка в таблицах ОС обнуляется;

блокировки памяти и записи, установленные в процессе-родителе, не наследуются. После вызова fork () алгоритм обычно разветвляется (в случае успешного выполнения функции fork (), она возвращает PID процесса-потомка родительскому процессу и нуль процессу-потомку. Если порождение процесса-потомка закончилось неудачей, функция fork () возвращает значение 1).После fork () процесс-потомок чаще всего выполняет системный вызов exec (), загружающий в пространство процесса новую программу (именно так, и только так, в Unix-системе выполняется запуск программы в отдельном процессе). Так, первый (нулевой) процесс Unix (ядро системы) создаёт свою копию, чтобы запустить init (процесс с PID = 1), который в свою очередь создаёт дочерние процессы для запуска инициализации системы и терминалов. Некоторые программы создают дочерние процессы не для запуска другой программы, а для выполнения параллельной задачи. Так, например, поступают простые сетевые серверы при подсоединении клиента, сервер создаёт свою копию (дочерний процесс), которая обслуживает клиентское соединение и завершается по его закрытии. Родительский же процесс продолжает ожидать новых соединений. Вызов fork () выполняется довольно долго, так как требует копирования большого количества данных. Для того чтобы это обойти, некоторые сетевые серверы (например, веб-серверы Apache и Lighttpd), создают дочерние процессы заранее, чтобы уменьшить время отклика сервера. Также существуют «облегченные» реализации fork () (Например в ядре Linux[1]), отображающие в новый процесс страницы памяти родительского, вместо того чтобы их копировать (новая страница создаётся только при изменении её содержимого одним из процессов), что существенно снижает время создания нового процесса.

2.4. Взаимодействие с базой данных SQLiteSQLite — это встраиваемая реляционная база данных, поставляемая с исходными кодами. Впервые выпущена в 2000 году, предназначена для предоставления привычных возможностей реляционных баз данных без присущих им накладных расходов. За время эксплуатации успела заслужить репутацию как переносимая, легкая в использовании, компактая, производительная и надежная база данных. Встраиваемость базы данных означает, что она существует не как процесс, отдельный от обслуживаемого процесса, а является его частью — частью некоторого прикладного приложения. Внешний наблюдатель не заметит, что прикладное приложение пользуется СУБД. Это избавляет от необходимости сетевых настроек, никаких файерволов, никаких сетевых адресов, никаких пользователей и конфликтов их прав доступа. И клиент, и сервер работают в одном процессе. Это избавляет от проблем конфигурирования.

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

Верхние модули компилируют запросы, средние выполняют их, а нижние управляются с диском и взаимодействуют с операционной системой.Рис. 2. Архитектура SQLiteИнтерфейс является верхним модулем и состоит из м C API. Общение с SQLite производится через него. Подробнее с SQLAPIможно познакомиться на официальном сайте.

http://sqlite.org.

2.5. Описание алгоритма работы демона.

Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем. UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных W eb-приложений и даже встроенных систем реального времени.

Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие вырази-тельных возможностей, этот язык прост для понимания и использования. Диаграммы деятельности — это один из пяти видов диаграмм, применя-емых в UML для моделирования динамических аспектов поведения системы. Диаграмма деятельности — это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой, однако, по сравнению с последней, у ней есть явные преимущества: поддержка много-поточности и объектно-ориентированного проектирования. Диаграмма деятельности (Activitydiagram) показывает поток перехо-дов от одной деятельности к другой. Деятельность (Activity) — это продол-жающийся во времени неатомарный шаг вычислений в автомате. Деятельно-сти в конечном счете приводят к выполнению некоего действия (Action), со-ставленного из выполняемых атомарных вычислений, каждое из которых ли-бо изменяет состояние системы, либо возвращает какое-то значение. Дей-ствие может заключаться в вызове другой операции, посылке сигнала, созда-нии или уничтожении объекта либо в простом вычислении — скажем, значе-ния выражения.

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

а)б)в)Рис. 3. Состояния действия и комментарий: а) простое действие; б) выражение; в) комментарий.

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

Предполагается, что для их завершения требуется заметное время. Можно считать, что состояние действия — это частный вид состояния деятельности, а конкретнее — такое состояние, которое не может быть подвергнуто дальней-шей декомпозиции. А состояние деятельности можно представлять себе как составное состояние, поток управления которого включает только другие со-стояния деятельности и действий. Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние дей-ствия или деятельности. Для описания этого потока используются переходы, показывающие путь из одного состояния действия или деятельности в дру-гое. В UML переход представляется простой линией со стрелкой, как показа-но на рисунке 4.Рис. 4. Простые нетриггерные переходы.

Простые последовательные переходы встречаются наиболее часто, но их одних недостаточно для моделирования любого потока управления. Как и в блок-схеме, вы можете включить в модель ветвление, которое описывает различные пути выполнения в зависимости от значения некоторого булевского выражения. Как видно из рисунка5, точка ветвления представляется ромбом. В точку ветвления может входить ровно один переход, а выходить — два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Ни для каких двух исходящих переходов эти сторожевые условия не должны одновременно принимать значение «истина», иначе поток управления окажется неоднозначным. Но эти условия должны покрывать все возможные варианты, иначе поток остановится. Рис 5. Ветвления в диаграммах деятельности.

Для удобства разрешается использовать ключевое слово else для по-метки того из исходящих переходов, который должен быть выбран в случае, если условия, заданные для всех остальных переходов, не выполнены. UML диаграмма деятельности разработанного демона Linuxизображена на рисунке 6.Рис. 6. Диаграмма деятельности демона LinuxРабота демона осуществляется следующим образом. Создается рабочий каталог демона, если он не существует. Создается файл лога для мониторинга работы демона и записи результатов работы приложений, запускаемых по расписанию. Создается база данных SQLiteс таблицей tasks, если она отсутствует в каталоге демона. Таблица tasks имеет следующие поля: task_id — идентификатор запускаемой задачи;command — запускаемая команда Linux вместе с ее аргументами;schedule — расписание выполнения команды. Полеscheduleсодержит строку, формат которой соответствует формату времени запуска команды в таблице crontabутилиты cron. Эта строка состоит из пяти колонок, разделяемых пробелами или табуляторами, эти пять колонок задают время выполнения команды в следующем порядке:

минута (от 0 до 59);час (от 0 до 23);день (от 1 до 31);месяц (от 1 до 12);день недели (от 0 до 7, воскресенью соответствует либо 0, либо 7).Каждая колонка строки, хранящейся в поле scheduleможет содержать либо число, либо специальный символ «*», в этом случае команда Linuxбудет запускаться при любых значениях соответствующей компоненты текущего времени. Далее считываются все записи из базы данных и формируется список заданий, после чего соединение с базой данных закрывается. Для запуска демона в фоновом режиме выполняется системный вызов fork (), позволяющий создать копию процесса демона. После создания копии процесса, родительский процесс завершается. В дочернем процессе сначала создается PID-файл, содержащий идентификатор PIDдочернего процесса. Создание PID-файла позволяет предотвратить повторный запуск демона и используется управляющим приложением для опроса состояния демона. Далее организовывается бесконечный цикл, в котором получается текущее время, и производится сравнение с целью проверить удовлетворяет ли текущее время условиям выполнения команды Linux, если текущее время удовлетворяет заданным условиям, то запускается команда Linuxс помощью системного вызова popen (), при этом результаты работы команды записываются в файл лога. Демон обрабатывает два сигнала: SIGHUP, при поступлении которого демон перезапускается и заново читает данные из базы данных, и SIGTERM, при поступлении которого демон завершает свою работу, предварительно удалив PID-файл.

2.6. Описание алгоритма работы управляющей программы.

Диаграмма деятельности управляющей программы показана на рисунке 7Рис. 7. Диаграмма деятельности управляющей программы.

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

Команда exit. Завершает работу управляющей программы. Формат команды: exit. Команда terminate. Завершает работу демона, путем отправки сигнала SEGTERMпроцессу-демону, идентификатор которого, берется из PID-файла. Формат команды: terminate. Команда status. Показывает статус демона путем чтения содержимого PID-файла.

Формат команды: status. Команда add. Добавляет команду Linux в базу данных. Формат команды: add <команда и ее параметры>. После добавления на терминал выводится идентификатор команды и посылается сигналSIGHUPпроцессу демона. Команда remove. Удаляет команду Linuxиз базы данных. Формат команды: remove <идентификатор команды>. Идентификатор команды получается после выполнения команд addили list. После ввода команды на терминал выводится количество удаленных записей и посылается сигнал SIGHUP процессу демона. Команда schedule. Устанавливает расписание запуска для команды Linux. Формат команды: schedule <идентификатор команды> <расписание запуска>. Идентификатор команды получается после выполнения команд addили list. Формат строки с расписанием запуска команды соответствует формату поля scheduleиз раздела 2.

5. После ввода команды на терминал выводится количество обновленных записей и посылается сигнал SIGHUP процессу демона. Команда list. Показывает список всех команд и расписание их запуска.

2.7. Развертывание программы.

Структурная схема взаимодействия демона Linuxс управляющей программой изображена на рисунке 8. На этом рисунке демон имеет имя simple-chrond, тогда как управляющая программа называется simple-chron.Рис. 8. Структурная схема взаимодействия демона Linuxи управляющей программы.

Очевидно, что и демон и управляющая программа используют одну и ту же базу данных, но поскольку демон только считывает значения из базы данных, а управляющая программа выполняет как считывание, так и запись в базу данных, то файлы СУБД SQLiteдолжны быть скомпилированы с поддержкой библиотеки POSIXThreads (Pthreads).

2.8. Выводы.

Таким образом, в этой главе былрассмотрен прикладной программный интерфейс межпроцессного взаимодействия с помощью сигналов, а также средства клонирования процессов для последующего запуска демона. Рассмотрена архитектура СУБД SQLite. Приведено описание алгоритмов работы прикладной программы и демона.

ЗАКЛЮЧЕНИЕ

Таким образом, в данной работе выполнена разработка простого планировщика заданий, включающего в себя демон Linux, консольное управляющее приложение и базу данных SQLite. В первой главе были рассмотрены назначение и цель создания программы. Рассмотрены основные компоненты операционной системы, с которыми осуществляется взаимодействие — это процессы, нити и сигналы. Был про-изведен анализ наиболее распространенных свободно распространяемых СУБД, которые могли бы быть использованы при написании программы, это SQLite, MySQL и PostgreSQL.

Поскольку работа программы не будет осуществляться в многопользовательской среде и не требуется запись и обработка больших объемов данных, то, очевидно, наиболее подходящей СУБД является SQLite. Во второй главе был рассмотрен прикладной программный интерфейс меж-процессного взаимодействия с помощью сигналов, а также средства кло-нирования процессов для последующего запуска демона. Рассмотрена ар-хитектура СУБД SQLite. Приведено описание алгоритмов работы при-кладной программы и демона. Задание на курсовую работу выполнено в полном объеме. СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫСкотт Граннеман.Linux. Необходимый код и команды. Карманный справочник. — М.:Вильямс., 2015.

Арнольд.

Роббинс. Unix. Справочник. — М.: КУДИЦ-Пресс. — 2007.

Бруй В. В., Карлов С. В. LINUX-сервер: пошаговые инструкции инсталляции и настройки. М.: Изд-во СИП РИА, 2003.

Дунаев С. «UNIXSYSTEMV. Release 4.

2. Общее руководство". М.:" Диалог-МИФИ", 1995.

Иваницкий К. А. ALT Linux для школы (+ CD-ROM) -М.: Издательство:

Триумф, 2009.

Колисниченко Д.Н., Аллен Питер В. LINUX: полное руководство. — СПб: Наука и Техника, 2006.

Немет Э., Снайдер Г., Хейн Т. Руководство администратора Linux. 2-еиздание.: Пер. с англ. — М.: ООО «И.Д.Вильямс», 2007.

Робачевский А. «Операционная система UNIX» — СПб.: БХВ-Петербург, 2002.

Фленов М. Linux глазами хакера — С-Пб.; БХВ-Петербург, 2005.