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

Делаем «жизнь» в Linux проще или автоматизация запуска процессов с помощью cron

Введение

Демоны atd и cron

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

Михаэль Кофлер «Linux. Установка, настройка, администрирование.» — СПб.: Питер, 2014

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

Если у вас установлен обычный дистрибутив, то вам не о чем беспокоится, cron инсталлируется автоматически. Если же минимальный, то не расстраиваемся — идём в терминал.

Доступ юзерам к демону, настраивается в каталоге /var/spool/cron/tabs/user. Их права задаются в файлах /cron/allow и /deny. Добавляя пользователя в /allow мы разрешаем ему выполнять команду cron, а если добавить пользователя в /deny, то наоборот, пользователю будет запрещено пользоваться демоном.

Сам cron настраивается в каталоге /etc/crontab. Файл /crontab или файлы в /etc/cron. d содержат список команд, предназначенных для выполнения. Синтаксис таков:

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

Если в любом из первых пяти полей стоит символ *, то это поле игнорируется. В предыдущей команде не указаны ни месяц, ни неделя, следовательно, она будет выполнятся каждые 15 минут. Чтобы изменить конфигурацию воспользуйтесь в терминале командой vi или вручную измените содержание файла /etc/crontab.

Работа с .hourly, .daily, .weekly, .monthly

По умолчанию почти во всех дистрибутивах, файл /etc/crontab содержит всего несколько записей, необходимых для выполнения сценариев:
/etc/cron.hourly/* — сценарии выполняющиеся каждый час
/etc/cron.daily/* — сценарии выполняющиеся каждый день
/etc/cron.weekly/* — сценарии выполняющиеся каждую неделю
/etc/cron.monthly/* — сценарии выполняющиеся каждый месяц

Чтобы демон выполнял ваши команды, добавьте сценарий выполняющий команды в один из каталогов. Не забудьте установить бит execute(chmod a+x файл). Если вы этого не сделаете, то у вашего сценария просто не будет доступа и он выполнятся не будет!
Для проверки, будет ли запускаться ваш сценарий, выполните команду

Если сценарий расположен в другом каталоге, то соответственно меняйте daily на monthly и т.д.
И помните, в имени сценария не может быть точек, любые символы, кроме точек. Команда run-parts просто-напросто игнорирует сценарии с точкой, не знаю почему.

Источник

Скрипты и планировщик задач в ОС Linux

В данном посте обсуждаются базовые принципы написания скриптов и работа планировщика заданий в Oracle Linux. Рассматриваются следующие вопросы:

• Скрипты в ОСLinux
• Что такое планировщик заданий
• Работа сервисаcron
• Примеры

1. Скрипты в ОС Linux

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

Для того, чтобы превратить файл с набором команд в скрипт, понадобятся две вещи. Во-первых, в первой строке пустого файла необходимо прописать путь к командной оболочке, которая будет исполнять данный файл. В большинстве дистрибутивов Linux данной оболочкой является Bash, и соответственно первой строкой будет #!/bin/bash. В других строках символ решетки используется для обозначения комментариев, которые не будут обработаны оболочкой. Однако, первая строка — это особый случай, здесь решетка, за которой следует восклицательный знак (эту последовательность называют шебанг) и путь /bin/bash, указывают системе что данный скрипт создан именно для оболочки bash. Во вторых, чтобы скрипт запустить как исполняемый файл, ему необходимо дать права на исполнение, иначе, попытка его запуска даст ошибку Permission denied.

Пример ошибки, когда запускается неисполняемый файл:

Права на исполнение даются командой chmod. Например,

chmod +x filename.sh

Данная команда дает всем пользователям операционной системы право на запуск файла с именем filename.sh

Право на запуск того же файла только владельцу можно дать следующей командой: chmod u+x filename.sh.

Расширение .sh не обязательно, но таким образом легче определять, какой файл является скриптом.

Ниже рассматривается пример написания простейшего скрипта, копирующего все файлы из папки /home/rustam/Documents в папку /tmp/backup.

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

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

Существуют два типа переменных, которые используются в bash-скриптах:

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

Можно использовать системную переменную $HOME в двойных кавычках, что не помешает ее распознаванию системой.

В дополнение к переменным среды, bash-скрипты позволяют задавать и использовать в скрипте свои собственные переменные. Подобные переменные хранят значение до тех пор, пока не завершится выполнение сценария. Как и в случае с системными переменными, к пользовательским переменным обращаются используя знак доллара:

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

2. Что такое планировщик заданий. Работа сервиса cron.

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

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

Как и большинство других сервисов Linux, cron запускается при старте системы и работает в фоновом режиме. Его основная задача – выполнять требуемые процессы в заданное время. Существует несколько конфигурационных файлов, из которых берется информация о том, что и когда нужно выполнять. Cron открывает файл /etc/crontab, в котором указываются необходимые данные.

Для настройки времени, даты и интервала выполнения задания, используется специальный синтаксис файла cron и специальная команда. Не рекомендуется непосредственно редактировать файл /etc/crontab. Вместо этого используется команда crontab. Ниже запускается команда crontab с ключом –e для редактирования файла

Рекомендуется ее выполнять с опцией -e, тогда для редактирования правил используется текстовый редактор по умолчанию. После выполнения команды открывается временный файл, в котором записаны текущие правила cron и есть возможность добавлять новые. Добавленные правила запускаются именно от того пользователя, от имени которого они были добавлены.

Файлы crontab, используемые для управления работой планировщика, располагаются в каталоге /etc/cron.d/. Кроме того, в каталогах /etc/cron.daily/, /etc/cron.weekly/ и /etc/cron.monthly/ размещаются автоматически запускаемые программы (ежедневно, еженедельно или ежемесячно).

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

Таблица crontab состоит из 6 колонок, которые разделяются пробелами или табуляторами. Первые пять колонок отвечают за время выполнения, соответственно, минута, час, день месяца, месяц, день недели. В них может находиться: число, список чисел (1,2,3), диапазон чисел (1-3), символы * или /. Все остальные символы в строке интерпретируются как выполняемая команда с ее параметрами – можно указать как саму команду (например, echo “Доброе утро”), так и путь к исполняемому скрипту.

Как запускать скрипты через cron

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

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

Пример запуска ранее созданного скрипта filename.sh, который копирует файлы каждый день в 23:00:

или копирует файлы каждые 5 минут:

3. Примеры

Ниже приведены примеры настройки и работы cron:

0 17 * * 1-5 echo “Рабочий день закончен – эта надпись выводится в 17:00 с понедельника по пятницу”

15 6 * * sun echo “Выполняется в 6:15 в воскресенье”

30 12,13 * * 1,3 echo “Эта надпись выводится в понедельник и среду в 12:30 и 13:30”

Источник

Linuxoid

OpenSource forever

Планировщики процессов Linux

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

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

Долгое время в Linux присутствовал фактически один scheduler — O(1). Да были другие предложения вроде Staircase от Кона Коливаса (Con Kolivas, http://ck.kolivas.org/patches/pre-releases/2.6.21-rc7/2.6.21-rc7-ck1/patches/ ), с мая 2007 его разработка прекращена. Или Fairsched ( http://s ource f orge .net/projects/fairsched ). Но все они были реализованы исключительно в виде дополнений, не попадая основную ветку. Сегодня наметилась явная активность разработчиков в этом направлении. Сообщения о новых реализациях появляются на KernelTrap чуть ли не ежемесячно.

Стандартному планировщику O(1) уже более 15 лет. В июле 1993 года Линус Торвальдс в своем сообщении ( http://kerneltrap.org/mailarchive/linux-activists/36335 ) описал принцип работы планировщика задач Linux. Оригинальный файл этого планировщика sched.c содержал всего 254 строки кода. Это был простой и понятный алгоритм. В 1996 году нем было уже более 6 тысяч строк. Только через 10 лет в 2002 году первое глобальное изменение ultra-scalable O(1) scheduler от Инго Молнара (Ingo Molnar). В последних версиях sched.c содержит уже более 7000 строк.

Алгоритм работы O(1) очень прост. Каждая задача имела фиксированное число (tick), которое пересчитывается с каждым системным тиком (по умолчанию 100 Hz), при выходе из режима ядра или при появлении более приоритетной задачи. Алгоритм просто делит число на два и добавляет базовую величину (по умолчанию 15, с учетом величины nice ). Когда тик становится равным 0, он пересчитывается. Кроме этого каждый процессор имеет две очереди. В одной находятся готовые к запуску задачи, во вторую помещаются отработавшие и спящие задачи, которые например, ожидают не доступного в настоящее время ресурса. Когда первая очередь пустеет, очереди меняются местами. Поэтому время работы алгоритма постоянно и не зависит от количества процессов. Современная реализация O(1) используют уже более сложные алгоритмы, анализируя среднее время сна процесса, чтобы обнаружить интерактивные задачи ожидающие ответа пользователя и стараясь задержать их подольше в активном дереве.

В ядро 2.6.23 после трех месяцев обкатки в экспериментальной -mm ветке ядра, был включен в качестве основного планировщик CFS (Completely Fair Scheduler, абсолютно справедливый планировщик). Алгоритм которого полностью пересмотрен и весьма сложен. В отличие от O(1) CFS равномернее распределяет процессорное время (фактически если задачи две, то каждая получит ровно 50% CPU), распределяет задачи по нескольким ядрам и имеет меньшее время отклика. Для настройки CFS используется файл /proc/sys/kernel/sched_granularity_ns , в котором по умолчанию установлен режим desktop (меньшее время задержки), но при необходимости его можно переключить в server .

$ cat server > /proc/sys/kernel/sched_granularity_ns

Con Kolivas остановив разработку ветки ck, в марте анонсировал совершенно новый планировщик RSDL (Rotating Staircase DeadLine scheduler), в последствии он был переименован в SD (Staircase Deadline, ck.kolivas.org/patches/staircase-deadline). За его основу был взят Staircase. Задача нового планировщика исключить зависания присущие O(1), здесь все процессы равны, каждому дается своя квота, исчерпав которую он опускается на следующий уровень приоритета, где получает новую квоту. Причем каждый уровень также имеет свою квоту, если ее исчерпает хотя бы один процесс, все перейдут на следующий уровень, в не зависимости от того отработали ли они свою квоту или нет. Планировщик также пытается определить интерактивные процессы, автоматически повышая им приоритет. Версия SD показывала неплохие результаты на серверах, и поговаривали, что этот планировщик будет включен в основную ветку начиная с 2.6.22, но из-за проблем со здоровьем разработка шла относительно медленно и Инго Молнар обогнал соперника.

Как ответ на сложность CFS Роман Зиппель (Roman Zippel) представил рабочий прототип базового алгоритма нового планировщика RFS (Really Fair Scheduler, kerneltrap.org/RFS), который помещает задачу в виртуальную (нормализованную) time line, в которой имеет значение только относительное расстояние между двумя любыми задачами. После некоторых споров в ответ на этот прототип Инго Молнар представил свою версию, которую он назвал RSRFS (Really Simple Really Fair Scheduler) реализованный поверх CFS, и включающий алгоритм из RFS. Есть и патчи к CFS, например programming.kicks-ass.net/kernel-patches/sched-cfs.

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

Проект DeskOpt

Интересный проект был представлен примерно полгода назад в списке рассылки разработчиков ядра Linux. Программа DeskOpt (www.stardust.webpages.pl/files/tools/deskopt) представляет собой демон, написанный на языке высокого уровня Python, который отслеживает запускаемые пользователем приложения и автоматически выбирает оптимальные параметры работы планировщика процессов CFS и планировщик ввода/вывода (CFQ, anticipatory, deadline). Все настройки осуществляются путем редактирования конфигурационного файла, в котором по умолчанию описано три класса оптимизации: игры, просмотр видео и прослушивание музыки. Текущая версия 0.6-rc1 от января 2008 года. DeskOpt легко устанавливается

Требования:
— Python 2.x (http://python.org/)
— elementtree (http://effbot.org/downloads/#elementtree)
$ tar xjvf deskopt-006-rc1.tar.bz2

$ cd deskopt-006-rc1

$ cp deskopt /usr/local/bin/
$ sudo mkdir /etc/deskopt/
$ sudo cp deskopt.conf /etc/deskopt/
$ sudo cp deskopt.rc /etc/init.d/

К онфигурационный файл имеет простой XML формат, в нем уже есть готовые настройки. В простейшем случае команда выглядит так:

$ sudo deskopt -c /etc/deskopt/deskopt.conf

2 комментария

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

Источник