Отложенный запуск службы linux

Отложенный запуск сервисов

Внимательно пролистал ман к systemctl , но не обнаружил в нем возможности отложить запуск сервиса.
Например, нужно задержать его на 10 секунд.

Временно сделал его по старинке с помощью cron —

но проблема в том, что по некоторым причинам нужно реализовать его именно с помощью возможностей systemd.

Как же это сделать?

например sleep в ExecStartPre или сделать таймер

Например, нужно задержать его на 10 секунд.

но вот тут что-то не так, т.к. одной из целей в systemd было убрать хардкодные задержки и заменить их на «события».

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

sleep в ExecStartPre или сделать таймер

Можете накидать примеры этих способов?

Можете накидать примеры этих способов?

некоторые внешние устройства при быстром запуске их сервиса не успевают инициализироваться

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

Если сервис в таких случаях завершается, то можно в юните прописать ему рестарт с задержкой. Так же можно попробовать запустить с помощью правил udev после определения устройства.

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

Есть параметр TimeoutStartSec, через который можно задать ожидание перед запуском.

Изменить параметры можно через Drop-in.

а вдруг 10 секунд в некоторорых случаях перестанет хватать? При рестарте сервиса жди N секунд — если работаешь не один и твой товарищ не в курсе или забыл, то он может решить, что возникла какая-то проблема (systemctl ждет когда юнит отработает полностью). И т.д.

рестарт с задержкой при падении (если сервис падает)

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

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

это не ожидание перед запуском. Это время ожидания подтверждения успешного запуска

Спасибо за уточнение.

По вашему «кривому» 🙂 способу

работает как часы, проверял top’ом.

не работает вообще. Ну и ладно, не очень-то и хотелось.

Не знаю только, стоит ли добавлять перезапуск при сбоях —

Если он так полезен, то почему он не установлен по дефолту?

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

Но при команде systemctl restart my_service не работает вообще. Ну и ладно, не очень-то и хотелось.

Ну стоило бы посмотреть systemctl status my_service и понять, почему рестарт не работает.

Есть гарантия что всего задержки 10 достаточно? Вдруг однажды 15 нужно будет?

В systemd.timer есть такая возможность, но я не помню синтаксис. Внесите intelfx .

Внимательно пролистал ман к systemctl , но не обнаружил в нем возможности отложить запуск сервиса.

Тебе нужно отложить запуск однократно?

Или сделать так, чтобы юнит в принципе запускался через N после загрузки ОС?

Есть гарантия что всего задержки 10 достаточно? Вдруг однажды 15 нужно будет?

Откуда вообще возникла потребность в задержке?

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

Что за устройство? Что понимается под «инициализацией»? Оно обнаруживается через несколько секунд или уже после обнаружения ещё какое-то время не готово к работе?

Устройство — известный всем USB-приемник для приема TV-программ, в народе именуемый «свистком» и который сейчас для чего только не используют.
Больше ничего неизвестно, но народ опытным путем вычислил, что для определения (или инициализации) этих свистков 5 секунд обычно всегда хватает, а чтобы была гарантия, ставят 10.

Я склоняюсь к тому, что запуском после сбоя должен заниматься человек,

Конечно. это правильнее, но не всегда у человека есть время мониторить этот сбой, куда проще сделать перезапуск после него.

Ты самого главного не сказал: он определяется 5 секунд или после определения ещё 5 секунд неработоспособен?

Не знаю насчет определения, но если не ввести задержку для сервиса, то он не работает вообще, сколько ни жди
А если ввести задержку 5 сек для запуска его сервиса, то после истечения этих 5 секунд он начинает работать сразу.

Источник

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Как запустить, остановить и перезапустить сервисы в Linux

Start — Stop — Restart — Reload

3 минуты чтения

Linux обеспечивает детальный контроль над системными службами через systemd с помощью команды systemctl. Службы могут быть включены, выключены, перезапущены, перезагружены или даже включены или отключены при загрузке. Если вы используете Debian, CentOSили Ubuntu, ваша система, вероятно, использует systemd.

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Это руководство покажет вам, как использовать основные команды для запуска, остановки и перезапуска служб в Linux.

Базовый синтаксис команды systemctl

Основной синтаксис для использования команды systemctl:

Как правило, вам нужно запускать это как суперпользователь поэтому команды будут начинаться с sudo.

Как проверить, работает ли служба в Linux

Чтобы проверить, активна ли служба или нет, выполните следующую команду:

Замените SERVICE_NAME на нужный сервис.

В нашем случае мы будем брать за пример веб-сервер Apache.

Интересный факт: в Ubuntu и других дистрибутивах на основе Debian служба Apache называется apache2. В CentOS и других дистрибутивах RedHat служба Apache называется httpd или httpd.service

Так мы проверили состояние Apache. Выходные данные показывают, что служба активна (работает), как на рисунке ниже:

Как перезапустить сервис

Чтобы остановить и перезапустить службу в Linux, используйте команду:

Где SERVICE_NAME — имя вашего сервиса.

После выполнения команды ваш сервис должен снова заработать. Вы можете проверить состояние с помощью команды status

Для перезапуска нашего сервера Apache используем:

Как перезагрузить конфигурационные файлы сервиса

Чтобы служба перезагрузила свои файлы конфигурации, введите в терминале следующую команду:

После перезагрузки проверьте ее состояние командой status для подтверждения.

В нашем примере мы перезагрузили Apache, используя:

Как запустить сервис

Чтобы запустить службу в Linux вручную, введите в терминале следующее:

Например, команда для запуска службы Apache:

Как остановить сервис

Чтобы остановить активную службу в Linux, используйте следующую команду:

Для нашего апача используем команду

Проверьте, остановился ли сервис с помощью команды status . Вывод должен показать, что сервис неактивен — inactive (dead)

Как включить сервис при загрузке

Чтобы настроить службу для запуска при загрузке системы, используйте команду:

Чтобы включить Apache при загрузке системы, выполните команду:

Как отключить сервис при загрузке

Вы можете запретить запуск службы при загрузке с помощью команды:

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Полезно?

Почему?

😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.

😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.

Источник

Использование таймеров systemd вместо заданий cron

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

Эти таймеры, как и задания cron, могут, в заданное время, вызывать выполнение различных действий в системе. Например — запуск скриптов командной оболочки или программ. Таймеры могут срабатывать, например, раз в день, причём — только по понедельникам. Ещё один пример — срабатывание таймера каждые 15 минут в рабочее время (с 8 утра до 6 вечера). Но таймеры systemd могут кое-что такое, что недоступно заданиям cron. Например, таймер может вызвать скрипт или программу через заданное время после некоего события. Таким событием может быть загрузка системы или запуск systemd, завершение предыдущей задачи или даже завершение работы сервиса, вызванного ранее по таймеру.

Таймеры, используемые для обслуживания системы

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

В качестве примера приведу здесь сведения о таймерах, которые имеются на виртуальной машине, использованной мной для экспериментов. Здесь, для получения списка всех таймеров, я использовал команду systemctl status *timer . Подстановочный символ в виде звёздочки играет здесь ту же роль, которую он играет в других подобных командах. А именно, он сообщает системе о том, что нас интересуют все таймеры (timer units, их ещё называют «unit-файлы таймера» или «юниты таймера») systemd:

С каждым таймером связано, по меньшей мере, шесть строк, содержащих сведения о нём:

• Первая строка содержит имя файла таймера и короткое описание цели существования этого таймера.
• Вторая строка выводит сведения о состоянии таймера. А именно, сообщает о том, загружен ли он, даёт полный путь к файлу таймера, показывает состояние vendor preset (disabled или enabled).
• В третьей строке показаны сведения об активности таймера, куда входят данные о том, когда именно таймер был активирован.
• В четвёртой строке содержатся дата и время следующего запуска таймера и примерное время, оставшееся до его запуска.
• Пятая строка сообщает имя сервиса или события, вызываемого таймером.
• Некоторые (но не все) файлы юнитов таймеров systemd содержат указатели на документацию. Такие указатели есть, в моём примере, в описаниях трёх таймеров.
• Последняя строка в описании таймера представляет собой запись журнала, которая связана с самым свежим экземпляром сервиса, вызванного таймером.

Если вы попробуете выполнить на своём компьютере команду systemctl status *timer , то представленный ей набор таймеров вполне может отличаться от моего.

Создание таймера

Хотя мы могли бы разобраться с особенностями работы таймеров, проанализировав какие-нибудь существующие таймеры, я предлагаю создать собственный unit-файл сервиса (файл конфигурации сервиса, service unit) и файл таймера, с помощью которого будет вызываться соответствующий сервис. Мы тут, чтобы не усложнять повествование, приведём довольно тривиальный пример. Но после того как мы с ним разберёмся, вам будет легче разобраться в работе других таймеров.

Для начала создадим простой файл конфигурации сервиса, который будет запускать что-то простое, вроде команды free . Например, это может понадобиться в том случае, если нам надо регулярно мониторить объём свободной памяти. Создадим unit-файл с именем myMonitor.service в папке /etc/systemd/system . Он не обязательно должен быть исполняемым.

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

А почему ничего не выводится в консоль? Дело в том, что по умолчанию стандартный вывод ( stdout ) от программ, запускаемых systemd с помощью unit-файлов сервисов, перенаправляется в журнал systemd. Благодаря этому, по крайней мере, до тех пор, пока соответствующие записи существуют, эти записи можно проанализировать. Заглянем в журнал и поищем записи, относящиеся к нашему сервису и к дню, когда мы проводили испытания. Соответствующая команда будет выглядеть так : journalctl -S today -u myMonitor.service . Ключ -S — это сокращённый вариант —since . Он позволяет указывать временной период, за который утилита journalctl ищет записи. Дело тут не в том, что нас не интересуют более ранние результаты. В нашем случае таких результатов просто не будет. Этот ключ использован для того чтобы сократить время, которое нужно утилите на поиск данных. Если компьютер работает уже давно, в журнале может накопиться очень много записей.

Задача, которая запускается с помощью файла конфигурации сервиса, может быть представлена отдельной программой, последовательностью программ, или скриптом, написанном на любом скриптовом языке. Добавим в unit-файл myMonitor.service ещё одну задачу, включив в него, в конце раздела [Service] , следующее:

Снова запустим сервис и проверим журнал. Там должно быть что-то, напоминающее то, что показано ниже. А именно, в журнал должны попасть данные, выводимые обеими командами:

Теперь, после того как мы уверились в том, что всё работает правильно, создадим, в папке /etc/systemd/system , unit-файл таймера, дав ему имя myMonitor.timer . В файл добавим следующее:

Указатель времени OnCalendar в этом файле, *-*-* *:*:00 , должен приводить к тому, что таймер выполняет вызов юнита myMonitor.service каждую минуту. Подробнее об OnCalendar мы поговорим ниже.

А пока мы можем взглянуть на записи журнала, имеющие отношение к запуску сервиса, вызываемого таймером. Мы, кроме того, можем включить режим наблюдения за таймером. Однако наблюдение за сервисом позволит видеть результаты практически в режиме реального времени. Для этого нужно запустить journalctl с ключом -f ( follow ):

Запустите таймер, но не включайте его в автозапуск при загрузке системы.

Понаблюдайте некоторое время за тем, что происходит.

Один из результатов появляется сразу же. А следующие будут выводиться с интервалом примерно в одну минуту. Понаблюдайте за журналом несколько минут.

Обязательно проверьте и состояние таймера, и состояние сервиса.

Удалось ли вам заметить тут то, что заметил я? Возможно, вы, читая журнал, обратите внимание как минимум на две вещи.

Во-первых — на то, что вам не нужно делать что-то особенное для логирования того, что ExecStart из myMonitor.service пишет в stdout . Эта возможность входит в стандартные функции systemd по запуску сервисов. Но это означает, что вам, вероятно, потребуется проявлять осторожность при запуске скриптов из файлов конфигурации сервисов, обращая внимание на то, каков объём данных, который они пишут в stdout .

Во-вторых, вы могли обратить внимание на то, что таймер запускается не точно в :00 секунд каждой минуты, и даже не в точности через одну минуту после предыдущего запуска. Это — одна из особенностей подобных таймеров, если это нужно (или если это задевает чувства системного администратора), такое поведение таймеров можно изменить, сделав их точнее.

Причина того, что таймер не запускается в :00 секунд каждой минуты, заключается в том, что система таким образом стремится предотвратить одновременный запуск нескольких сервисов. Например, при настройке указателя времени OnCalendar можно пользоваться такими значениями, как Weekly , Daily , да и другими подобными. Эти сокращённые способы именования моментов времени настроены так, чтобы таймеры, в которых они используются, запускались бы в 00:00:00 соответствующего дня. Когда так настроено множество таймеров, высока вероятность того, что все они сработают одновременно.

Именно поэтому таймеры systemd намеренно спроектированы так, чтобы они запускались бы не в точно указанное время, а с некоторым случайным отклонением от него. Это отклонение нельзя назвать совершенно случайным. Таймеры запускаются где-то во временном окне, которое начинается с указанного момента и заканчивается моментом, отстоящим от исходного на одну минуту. Это время, в соответствии с документацией к systemd.timer , поддерживается в стабильном состоянии с учётом всех остальных объявленных в системе таймеров. В вышеприведённом фрагменте журнала можно видеть, что таймер срабатывает сразу же после его запуска, а потом — примерно через 46 или 47 секунд после начала каждой следующей минуты.

Чаще всего такой вот вероятностный подход к определению точного времени срабатывания таймеров всех устраивает. При планировании таких задач, как, например, выполнение резервной копии чего-либо, до тех пор, пока подобные задачи выполняются в нерабочее время, никаких проблем это не вызывает. Системный администратор, настраивая задания cron, может указать чётко определённое время их запуска, нечто вроде 01:05:00 , стремясь к тому, чтобы эти задания не конфликтовали бы с другими. Существует большой набор способов указания времени, которые подобное позволяют. Случайные изменения во времени запуска задания, не превышающие минуту, обычно особой роли не играют.

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

Для указания желаемой точности таймера можно пользоваться особыми ключевыми словами. Эти ключевые слова можно применять и при настройке повторяющихся и «одноразовых» событий. Система понимает следующие ключевые слова:

• Микросекунда: usec , us , µs .
• Миллисекунда: msec , ms .
• Секунда: seconds , second , sec , s .
• Минута: minutes , minute , min , m .
• Час: hours , hour , hr , h .
• День: days , day , d .
• Неделя: weeks , week , w .
• Месяц: months , month , M (месяц определён как 30,44 дня).
• Год: years , year , y (год определён как 365,25 дня).

Все стандартные таймеры, которые имеются в /usr/lib/systemd/system , настроены с использованием гораздо более длительных диапазонов, задающих точность их запуска, так как в случае с этими таймерами срабатывание их в строго заданное время не особенно важно. Взгляните на спецификации некоторых таймеров, созданных системой:

Для того чтобы лучше познакомиться с внутренним устройством файлов таймеров из директории /usr/lib/systemd/system , вы можете просмотреть их содержимое.

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

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

Для того чтобы узнать подробности о точности таймеров, о способах указания времени вызова событий, о вызове событий, посмотрите документацию по systemd.timer и systemd.time .

Типы таймеров

Таймеры systemd обладают другими возможностями, которых нет у заданий cron, «одноразовых» или повторяющихся, которые вызываются только с привязкой к реальному времени и к реальным датам. Таймеры systemd можно настроить так, чтобы они вызывались бы на основании изменения состояния других юнитов systemd. Например, таймер можно настроить так, чтобы он срабатывал бы через заданное время после загрузки системы, после входа в неё пользователя, или через заданное время после активации определённого сервиса. Такие таймеры называют монотонными (monotonic). Эти таймеры сбрасываются после каждой перезагрузки системы.

В следующей таблице приведён список монотонных таймеров с краткой характеристикой каждого из них. Там же есть и описание таймера OnCalendar , который монотонным не является и применяется в тех случаях, когда нужно организовать единовременный или повторяющийся запуск чего-либо в будущем. Эта таблица основана на документации systemd.timer .

Таймер	Монотонный	Описание
	X	Время срабатывания таймера задаётся относительно момента активации таймера.
	X	Время срабатывания таймера задаётся относительно момента загрузки системы.
	X	Время срабатывания таймера определяется относительно первого запуска менеджера служб. В случае с системными таймерами это очень похоже на OnBootSec= , так как системный менеджер служб обычно запускается при загрузке очень рано. Подобные таймеры, преимущественно, ценны при использовании их с привязкой к менеджерам служб, относящимся к отдельным пользователям, так как такие менеджеры служб обычно запускаются только при первом входе пользователя в систему, а не в процессе загрузки системы.
	X	Время срабатывания таймера задаётся относительно того времени, когда таймер, который должен быть активирован, был активирован в последний раз.
	X	Время срабатывания таймера определяется относительно того времени, когда таймер, который должен быть активирован, был в последний раз деактивирован.
	Такой таймер привязан к реальному времени и ориентируется на события календаря. Подробности о синтаксисе описаний событий календаря можно найти в справке по systemd.time(7) . В остальном же семантика описаний таких таймеров похожа на таймеры OnActiveSec= . Это — именно такие таймеры systemd, которые сильнее всего похожи на те механизмы, которые применяются при настройке заданий cron.

При настройке монотонных таймеров могут использоваться те же ключевые слова, что были описаны выше при разговоре об AccuracySec . Но надо отметить, что systemd приводит соответствующие временные промежутки к секундам. Например, вам нужно задать таймер, который срабатывает один раз, через пять дней после загрузки системы. Выглядеть его описание может так: OnBootSec=5d . Если компьютер был загружен 2020-06-15 в 09:45:27 , то таймер сработает 2020-06-20 в 09:45:27 (или в пределах 1 минуты после этого момента времени).

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

Применение событий календаря — это ключевая часть описания таймеров, вызываемых через определённые промежутки времени. Разберём некоторые особенности таких событий, используемых при настройке указателя времени OnCalendar .

В systemd и в соответствующих таймерах используется формат описания времени и дат, отличающийся от того, который принят в crontab. Этот формат является более гибким, чем тот, что используется в crontab. Он позволяет указывать дату и время в упрощённом виде, в стиле команды at . Тому, кто знаком с at , будет несложно разобраться с настройками таймеров systemd.

При использовании OnCalendar= для настройки таймеров используется следующий базовый формат для указания даты и времени:

DOW (Day Of Week, день недели), это необязательная часть вышеприведённой конструкции. В других полях можно использовать символ звёздочки ( * ), символизирующий любое значение, которое может находиться в занимаемой им позиции. Все формы указания даты и времени приводятся к нормализованной форме. Если время не указано, предполагается, что это — 00:00:00 . Если дата не указана, а время указано, то таймер сработает либо в день его запуска (условно говоря, «сегодня»), либо на следующий день («завтра»). Это зависит от текущего времени. Для указания месяцев и дней недели могут использоваться их названия. Здесь можно использовать списки значений, разделяемые запятой. Диапазоны значений можно разделять тремя точками ( … ), которые ставят между начальным и конечным значением диапазона.

При указании дат в нашем распоряжении есть пара интересных возможностей. Так, тильда (

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

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

Пример представления события календаря DOW YYYY-MM-DD HH:MM:SS	Описание
	Каждый день каждого месяца каждого года, через 15 минут 30 секунд после полуночи.
	Каждый понедельник в 00:00:00 .
	То же самое, что и Weekly .
	То же самое, что и Weekly .
	Каждую среду 2020 года в 00:00:00 .
	Каждый будний день в 2021 году в 00:00:00 .
	1 и 15 июня, июля и августа 2022 года в 01:15:00 после полуночи.
	В следующий раз, в любой год, когда в мае понедельник будет днём, на 3 дня предшествующим концу месяца.
	В любом году, в 4 будний день, предшествующий концу августа.
	В 3 день, предшествующий концу мая, и затем — снова, через два дня. Повторяется ежегодно. Обратите внимание на то, что тут использован знак

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

Тестирование описаний времени, используемых в событиях календаря

В systemd имеется отличный инструмент для проверки и исследования спецификаций событий календаря. Речь идёт о команде systemd-analyze calendar , которая разбирает описания событий календаря и представляет их в нормализованной форме. Эта команда даёт и другую интересную информацию, такую, как дата и время наступления следующего такого события, и приблизительное время, оставшееся до достижения этого момента.

Для начала взглянем на спецификацию, которая содержит только дату, не содержит сведений о времени (обратите внимание на то, что время в полях Next elapse и (in UTC) различаются, это различие зависит от местного часового пояса):

Теперь добавим в описание сведения о времени. В данном примере дата и время анализируются раздельно, как сущности, не связанные друг с другом:

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

Теперь проверим что-нибудь из предыдущей таблицы. Мне особенно нравится такое описание из неё:

Теперь давайте взглянем на описание Mon *-05

3 , но в этот раз запросим у программы сведения о следующих 5 срабатываниях таймера, в котором использованы такие настройки:

Полагаю, мы рассмотрели достаточно примеров использования systemd-analyze calendar , что позволит вам приступить к тестированию собственных описаний событий календаря. Учитывайте то, что средство systemd-analyze обладает и другими интересными возможностями.

Дополнительные материалы

В интернете есть много публикаций по systemd, но они, в основном, слишком краткие, очень упрощённые, или даже содержат ошибки. В этой статье приведены некоторые хорошие источники информации по systemd. Ниже дан список ссылок ещё на некоторые качественные материалы по этой теме.

• Практическое руководство по systemd, подготовленное Fedora Project.
• Шпаргалка от Fedora Project, в которой сопоставлены команды старой системы SystemV и systemd.
• Подробности о systemd и о причинах создания этой системы.
• Материал со сведениями и советами, посвящённый systemd.
• Материалы Леннарта Поттеринга (Lennart Poettering), архитектора и основного разработчика systemd. Эти материалы предназначены для системных администраторов, они написаны между апрелем 2010 года и сентябрём 2011, но они всё ещё не потеряли актуальности. Практически все другие достойные публикации о systemd основаны на этих статьях.
• Материал об управлении датой и временем системы с помощью systemd.
• Статья об управлении запуском компьютера с использованием systemd.

Итоги

Таймеры systemd можно использовать для решения тех же задач, которые решают с помощью заданий cron. Но systemd даёт больше гибкости в плане настройки календарных и монотонных таймеров.

Даже хотя файлы конфигурации сервисов, созданные нами в ходе экспериментов, обычно вызываются с помощью таймеров, для их вызова можно, в любое время, воспользоваться командой вида systemctl start myMonitor.service . Одним таймером может запускаться несколько задач. Это могут быть, например, и Bash-скрипты, и утилиты Linux. Файл конфигурации сервиса можно составить так, чтобы при его вызове выполнялись бы несколько скриптов. Можно сделать и так, чтобы скрипты запускались бы по отдельности.

Если говорить о сосуществовании systemd, cron и at, то хочу отметить, что я пока не видел каких-либо признаков того, чтобы cron или at были бы признаны устаревшими. Я надеюсь, что их продолжат поддерживать, так как at, по крайней мере, гораздо легче, чем systemd, использовать для планирования единовременных задач.

Чем пользуетесь вы? Таймерами systemd или заданиями cron?

Источник