Отложенный запуск сервисов
Внимательно пролистал ман к 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 секунд он начинает работать сразу.
Источник
Справочная информация
про свой опыт решения некоторых проблем и использования ряда возможностей ОС и приложений
пятница, 16 декабря 2016 г.
Отложенный автозапуск (автостарт) в XFCE
В XFCE управление автозапускаемыми приложениями осуществляется через «Сеансы и запуск» и далее вкладку «Автозапуск» раздела «Система». Однако, в отличие от управления автозапускаемыми приложениями в Cinnamon, в XFCE, на первый взгляд, невозможно указать задержку автозапуска желаемого приложения.
А ведь при большом количестве автозапускаемых приложений возникает желание немного разгрузить систему, так как одновременный старт программ в своей грубой аналогии может быть сопоставлен желанию 3-4 человек одновременно пройти через обычные двери.
Для решения задачи по организации отложенного автозапуска в XFCE необходимо знать 2 вещи: точную команду на запуск желаемого приложения и через сколько секунд это приложение должно стартовать.
Была поставлена частная задача обеспечить плавный (для системы) автозапуск приложений Dropbox и pCloud, чтобы начать получать материалы, которые могли быть помещены в папки совместной работы.
Как было указано выше, выясним команды запуска этих приложений.
Dropbox – dropbox start -i
Задержка автозапуска Dropbox была определена мной в 2 минуты, а задержка автозапуска pCloud – в 4 минуты.
Примечание. В Cinnamon средство графического управления автозапуском не позволяло мне установить задержку более 99 секунд.
Автозапуск команды с задержкой выглядит следующим образом:
sh -c «sleep время_в_секундах && команда»
Поэтому для решения стоящей передо мной задачи необходимо в автозапуск добавить 2 команды:
sh -c «sleep 120 && dropbox start -i»
sh -c «sleep 240 && psyncgui»
Имя – это просто наименование того, что Вы запускаете. Можно, конечно, дать любое имя. Главное, чтобы для Вас было понятным, чему оно соответствует.
Описание – не обязательный к указанию параметр. Можно это поле заполнять, а можно и не заполнять. На функциональность это не повлияет.
Теперь целесообразно обзавестись перед глазами часами с секундной стрелкой и проверить правильность введённых Вами команд.
Источник
Власть над демонами или автозапуск в Linux
Для реализации автозапуска в Linux написано уже немало и на разных языках, но приходится искать, потому постарался свести большую часть тут. Здесь не рассказывается полностью весь процесс с нуля, но предоставлено достаточно информации и ссылок, чтобы сделать атоматический запуск программ в Linux реальностью.
Стоит сразу заметить — чтобы программа была полноценным сервисом/демоном, она должна быть соответствующе написана (link1, link2). Впрочем такое делают не всегда, хотя возможно это и не совсем правильно.
Существуют несколько способов сделать автозапуск программ в Linux:
- записать вызов программы/скрипта запуска в /etc/rc.local в фоновом режиме (&) (в разных дистрибутивах может лежать в разных местах, например, /etc/rc.d/rc.local) с перенаправленными потоками ввода/вывода в /dev/null. Например, «/home/user/my_prog 1 > /dev/null 2 > /dev/null &». Также, дополнительно, можно воспользоваться командой nohup;
- внести вызов в /etc/inittab, согласно правилам его оформления. В отличие от первого способа тут можно указать уровень запуска для программы;
- написать скрипт, позволяющий запускать/останавливать/перезапускать программу как демона, а также получать информацию о её состоянии.
Первый способ самый лёгкий, но и самый проблемный. Файл rc.local есть не во всех дистрибутивах. В нём нельзя задать уровень запуска. Если там записано несколько программ, то сложно ими управлять как сервисами (разве что запустить или остановить все одновременно). И, под конец, запуск из него подрывает устойчивость системы от взлома (примеры можно легко найти в поисковике).
Второй метод довольно экзотичный, сам узнал о нём совсем недавно, хотя пишут, что им пользуются многие администраторы. Тем не менее, используя его, нельзя оперировать запущенными таким способом программами как демонами, что довольно неудобно. Да и загромождать inittab некрасиво.
Последний метод на текущий момент самый «кошерный», но немного сложнее предыдущих (возможно, на первый взгляд). Именно им представлены все системные демоны, что говорит само за себя. Потому его и рассмотрю ниже.
Также есть способ автозапуска графических программ, но его опишу в конце, отдельно от остальных, т.к. он имеет недемоническую сущность.
Сразу обмолвлюсь, что у меня стоит Debian 6 и в других дистрибутивах пути могут несколько различаться.
Автозапуск программы как демона
Обычно в системе уже есть много подсказок как это сделать, но всё-таки приходится лазить по разным файлам и искать в интеренете дополнительную информацию. Это не значит, что я опишу тут каждую букву, но искать придётся меньше, надеюсь.
Для начала стоит заглянуть в каталог /etc/init.d. Здесь содержатся запускные скрипты всех сервисов, а также два файла для желающих написать себе такой же:
README и skeleton
skeleton содержит в себе болванку скрипта запуска с довольно подробными комментариями, а README его неплохо дополняет, не смотря на его небольшой размер. Также можно посмотреть и другие файлы и попытаться найти там что-то, что прояснит непонятную ситуацию.
В 6-ом debian`е для запускных скриптов демонов используется LSB (Linux Script Base) Init Standart. Почитать о нём подробнее можно тут. Для систем, где LSB не используется стоит взглянуть сюда.
Рассмотрим поближе файл skeleton. Первое с чего он должен начинаться, конечно же «#!/bin/sh», т.к. init-скрипт — запускной файл. Далее идёт комментированный заголовок:
Может показаться, что это просто лишняя информация от автора, но это не так. То, что указано здесь используется при прописывании скрипта в систему. Тут как раз пригодится файл README, который показывает, что в заголовке skeleton перечислены не все возможные параметры. Как минимум есть ещё следующие:
Все параметры и их полное описание (на английском) можно увидеть тут, а на русском тут и тут (спасибо awzrno за новые ссылки ^_^). К русскому варианту добавлю, что в Required-Start: можно прописать $all, тогда текущий скрипт будет запускаться после всех остальных (иногда это бывает нужно). Также X-Interactive: true показывает, что этот скрипт может взаимодействовать с пользователем, запросом на ввод чего-нибудь, например пароля.
Далее в skeleton идёт инициализация переменных, используемых в самом скрипте. Часть из них нужно будет настроить под свои нужды. Потом проверки на то, что сам демон существует и попытка прочитать конфигурационный файл (их имена должны быть указаны в переменных выше), далее загрузка переменных rcS, а потом идёт одна из самых интересных частей init-файла:
. /lib/lsb/init-functions
это определение LSB функций работы с логами, LSB-статусом сервиса, работы с процессом. В некоторых дистрибутивах этот файл может находиться в каталоге /etc/init.d. Названия и часть подробностей можно узнать непосредственно из комментариев к функциям в этом файле, а также тут.
Следующая часть — непосредственно тело скрипта. Тело состоит из условных частей, которые являются командами для демона: start, stop, restart/reload/force-reload, status. Кто-то выделяет их в отдельные функции, кто-то нет. На мой взгляд, функциями они выглядят эстетичнее и код более понятен. Все эти команды объединяет оператор выбора case, который и выбирает для исполнения нужный кусок кода, в зависимости от команды (параметра) с которой был запущен init-скрипт.
Таким образом для создания обычного скрипта достаточно подставить в переменные в начале файла нужные значения и, возможно, немного добавить кода в функции start/stop (например загрузку/выгрузку драйвера).
После того как файл будет готов его нужно скопировать в /etc/init.d и добавить в автозагрузку:
update-rc.d defaults
(или insserv для debian 6 stable и выше)
Удалить из автозагрузки можно так:
update-rc.d -f remove
(или insserv -r для debian 6 stable и выше)
Далее также можно использовать команды sysv-rc-conf в debian или service в fedora core, чтобы включить/выключить автозагрузку сервиса.
Автозапуск графического ПО без ввода паролей
Сама по себе реализация такой возможности понижает уровень защищённости ОС, т.к. войти может любой. Но бывают ситуации, когда это необходимо. Рассмотрю тут варианты только для двух основных графических менеджеров, т.к. других установленных под рукой нет.
Убрать запрос пароля на вход можно в центре управления (kcontrol) -> системное администрирование -> менеджер входа в систему -> удобства. Там выбрать пользователя, под которым входить (кроме рута) и поставить нужные галочки (разрешить автовход и вход без ввода пароля).
Чтобы сделать автозапуск программы нужно в каталог /home/ /.kde/Autostart добавить ссылку на запускной файл/скрипт нужного ПО.
Тут убрать запрос пароля на вход можно также в центре управления (gnome-control-center) -> Login Screen. Там, под рутом (ткнуть на замок, ввести пароль) выбрать пользователя, под которым входить (кроме суперпользователя).
Для автозапуска программы опять же в центре управления выбрать Startup Applications -> Add и заполнить маленькую форму.
Для обоих графических менеджеров:
Если нужно запустить под обычным пользователем, но от рута, то ещё надо настроить правила в /etc/sudoers на запуск конкретной программы/набора программ от имени суперпользователя (манами рекомендуется для безопасности делать это с помощью visudo). Как это делать рассказывать не буду, т.к. в man sudoers всё хорошо расписано.
Источник
