debian скрипты запуска автозагрузка init d
Управление автозагрузкой в debian
Скрипты инициализации также важны во время запуска и останова системы (в *nix системах просто меняется“runlevel”). Если вы посмотрите на список процессов, запущенных на вашей машине (попробуйте команду ps auwx), то есть вероятность, что процесс с наименьшим PID будет называться “init”. Это родительский процесс для всех процессов, это первая программа которую ядро запускает при загрузке. Программа init, которую можно найти по пути /sbin/init, ответственна за в рабочее состояние после того, как загрузится ядро.
Существует три простые утилиты для управления стартовыми и инициализационными скриптами:
Далее мы рассмотрим их все и приведем несколько примеров их использования.
update-rc.d
Синтаксис update-rc.d
update-rc.d [-n] [-f] name remove
update-rc.d [-n] name defaults [NN | NN-start NN-stop]
update-rc.d [-n] name start|stop NN runlevel runlevel start|stop NN runlevel runlevel
Когда запускается с опциями defaults, start или stop, update-rc.d создает ссылки /etc/rcrunlevel.d/[SK]NNname указывающие на скрипт /etc/init.d/name. Если какие-либо файлы уже существуют, то update-rc.d ничего не делает. Это объясняется тем, что системный администратор может изменить порядок ссылок, при условии, что как минимум одна ссылка сохранится, без того чтобы конфигурация была перезаписана.
Доступные опции.
Примеры использования update-rc.d
Вставить ссылки с использованием defaults:
Эквивалентная команда с использованием явных наборов аргументов:
Если вы хотите удалить скрипт из автозагрузки, то используйте следующую команду:
Если вы хотите узнать о команде update-rc.d больше, то прочтите страницу man.
rcconf
Rcconf позволяет управлять тем, какие сервисы будут запускаться когда система загружается или уходит в перезагрузку. Утилита показывает меню, содержащее все сервисы, которые должны быть запущены при загрузке. Те, которые должны запускаться помечены и вы можете включить или выключить отдельные сервисы. Эта утилита конфигурирует системные сервисы во взаимодействии с системными уровнями загрузки (runlevels). Она включает или выключает сервисы с применением скриптов в /etc/init.d/. Rcconf работает с конфигурацией уровней загрузки в стиле System-V. Фактически это TUI(Text User Interface) к команде update-rc.d
Rcconf получает список сервисов от /etc/init.d и просматривает директории /etc/rc?.d чтобы определить запущен сервис или нет.
Если число (NN в /etc/rc?.d/NNname) не равно 20 (по умолчанию), то rcconf сохраняет имя сервиса и число в /var/lib/rcconf/services так что возможно восстановить конфигурацию сервиса в исходном состоянии.
Установка rcconf в Debian.
Эта команда выполнит установку. Теперь вы можете использовать утилиту с помощью команды:
Если будет выводится сообщение rcconf needs dialog or whiptail, то необходимо будет установить утилиту dialog:
Теперь запустив rcconf Вы увидите на экране следующее:
Важные файлы:
Если вы хотите узнать больше об утилите rcconf, то ознакомьтесь со страницей man.
file-rc
Этот пакет предоставляет альтернативный механизм для загрузки или остановки системы и смены уровней загрузки. Ссылки /etc/rc?.d/* будут сконвертированы в единый конфигурационный файл /etc/runlevel.conf который легче администрировать, чем символьные ссылки и который более гибок. Пакет автоматически сконвертирует ваши существующие символьные ссылки в файл во время установки и конвертирует файл обратно в символьные ссылки при удалении. Оба механизма совместимы посредством скриптов /etc/init.d/rc, /etc/init.d/rc*, /usr/sbin/update-rc.d и /usr/sbin/invoke-rc.d
Установка file-rc в Debian.
В ходе установки в русифицированной версии Debian выводятся следующие сообщения:
Следующие НОВЫЕ пакеты будут установлены:
file-rc
0 пакетов обновлено, 1 установлено новых, 0 пакетов отмечено для удаления, и 42 пакетов не обновлено.
Необходимо получить 39,2 kB архивов. После распаковки 184 kB будет занято.
Следующие пакеты имеют неудовлетворённые зависимости:
sysv-rc: Конфликтует: file-rc но устанавливается 0.8.12.
Следующие действия разрешат зависимости:
Удалить следующие пакеты:
1) sysv-rc
Текущее состояние: 41 обновлён [-1].
Конфигурационный файл file-rc расположен в /etc/runlevel.conf. Если вы хотите посмотреть конфигурационный файл по умолчанию, то это можно сделать здесь.
Пример:
Если вы хотите узнать больше деталей о file-rc, то читайте страницу man.
Debian автозагрузка скрипта
Есть скрипт /root/project/test Добавил файл запуска в /etc/init.d/test :
Зделал reboot но скрипт не запускается!?
2 ответа 2
В ранних версиях там описанно всё внутри этого файла. Нужно только исправить на своё.
Вам нужно реализовать, минимум, чтоб работала функция start.
Существуют несколько способов сделать автозапуск программ в Linux. За автозагрузку отвечает файл /etc/rc.local как раз название говорит о само за себя, имеется ввиду локальный файл для администратора что бы не лезть в глубь системы, это более простой и универсальный способ. Чаще всего его вполне достаточно и не нужно изобретать велосипед.
Добавление скрипта в автозагрузку:
Удаление скрипта из автозагрузки:
Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux debian или задайте свой вопрос.
Похожие
Подписаться на ленту
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.9.23.40286
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Власть над демонами или автозапуск в Linux
Для реализации автозапуска в Linux написано уже немало и на разных языках, но приходится искать, потому постарался свести большую часть тут. Здесь не рассказывается полностью весь процесс с нуля, но предоставлено достаточно информации и ссылок, чтобы сделать атоматический запуск программ в Linux реальностью.
Стоит сразу заметить — чтобы программа была полноценным сервисом/демоном, она должна быть соответствующе написана (link1, link2). Впрочем такое делают не всегда, хотя возможно это и не совсем правильно.
Второй метод довольно экзотичный, сам узнал о нём совсем недавно, хотя пишут, что им пользуются многие администраторы. Тем не менее, используя его, нельзя оперировать запущенными таким способом программами как демонами, что довольно неудобно. Да и загромождать inittab некрасиво.
Последний метод на текущий момент самый «кошерный», но немного сложнее предыдущих (возможно, на первый взгляд). Именно им представлены все системные демоны, что говорит само за себя. Потому его и рассмотрю ниже.
Также есть способ автозапуска графических программ, но его опишу в конце, отдельно от остальных, т.к. он имеет недемоническую сущность.
Сразу обмолвлюсь, что у меня стоит Debian 6 и в других дистрибутивах пути могут несколько различаться.
Автозапуск программы как демона
Обычно в системе уже есть много подсказок как это сделать, но всё-таки приходится лазить по разным файлам и искать в интеренете дополнительную информацию. Это не значит, что я опишу тут каждую букву, но искать придётся меньше, надеюсь.
Для начала стоит заглянуть в каталог /etc/init.d. Здесь содержатся запускные скрипты всех сервисов, а также два файла для желающих написать себе такой же:
skeleton содержит в себе болванку скрипта запуска с довольно подробными комментариями, а README его неплохо дополняет, не смотря на его небольшой размер. Также можно посмотреть и другие файлы и попытаться найти там что-то, что прояснит непонятную ситуацию.
В 6-ом debian`е для запускных скриптов демонов используется LSB (Linux Script Base) Init Standart. Почитать о нём подробнее можно тут. Для систем, где LSB не используется стоит взглянуть сюда.
Рассмотрим поближе файл skeleton. Первое с чего он должен начинаться, конечно же «#!/bin/sh», т.к. init-скрипт — запускной файл. Далее идёт комментированный заголовок:
Может показаться, что это просто лишняя информация от автора, но это не так. То, что указано здесь используется при прописывании скрипта в систему. Тут как раз пригодится файл README, который показывает, что в заголовке skeleton перечислены не все возможные параметры. Как минимум есть ещё следующие:
Далее в skeleton идёт инициализация переменных, используемых в самом скрипте. Часть из них нужно будет настроить под свои нужды. Потом проверки на то, что сам демон существует и попытка прочитать конфигурационный файл (их имена должны быть указаны в переменных выше), далее загрузка переменных rcS, а потом идёт одна из самых интересных частей init-файла:
. /lib/lsb/init-functions
это определение LSB функций работы с логами, LSB-статусом сервиса, работы с процессом. В некоторых дистрибутивах этот файл может находиться в каталоге /etc/init.d. Названия и часть подробностей можно узнать непосредственно из комментариев к функциям в этом файле, а также тут.
Следующая часть — непосредственно тело скрипта. Тело состоит из условных частей, которые являются командами для демона: start, stop, restart/reload/force-reload, status. Кто-то выделяет их в отдельные функции, кто-то нет. На мой взгляд, функциями они выглядят эстетичнее и код более понятен. Все эти команды объединяет оператор выбора case, который и выбирает для исполнения нужный кусок кода, в зависимости от команды (параметра) с которой был запущен init-скрипт.
Таким образом для создания обычного скрипта достаточно подставить в переменные в начале файла нужные значения и, возможно, немного добавить кода в функции start/stop (например загрузку/выгрузку драйвера).
Далее также можно использовать команды sysv-rc-conf в debian или service в fedora core, чтобы включить/выключить автозагрузку сервиса.
Автозапуск графического ПО без ввода паролей
Сама по себе реализация такой возможности понижает уровень защищённости ОС, т.к. войти может любой. Но бывают ситуации, когда это необходимо. Рассмотрю тут варианты только для двух основных графических менеджеров, т.к. других установленных под рукой нет.
Чтобы сделать автозапуск программы нужно в каталог /home/ /.kde/Autostart добавить ссылку на запускной файл/скрипт нужного ПО.
Для обоих графических менеджеров:
Если нужно запустить под обычным пользователем, но от рута, то ещё надо настроить правила в /etc/sudoers на запуск конкретной программы/набора программ от имени суперпользователя (манами рекомендуется для безопасности делать это с помощью visudo). Как это делать рассказывать не буду, т.к. в man sudoers всё хорошо расписано.
Учимся управлять автозагрузкой в linux
Написанием данной статьи меня побудила банальная задача: отключить графическую оболочку при старте системы. Казалось бы, поменять одну цифру в /etc/inittab. Но как выяснилось, все намного сложнее. Итак, разберем по полочкам, что такое inittab и systemd, для чего они нужны и как управлять автозагрузкой приложений в linux. Как человек, который самостоятельно пытается найти ответы, пришлось прочитать не одну статью, информации на эту тему много, но понимание приходит не сразу. На русскоязычных форумах как правило развернутого ответа нет. Скажу сразу, я не системный администратор и статья больше рассчитана на людей, кто относительно недавно познакомился с linux. Кому интересна данная тема, добро пожаловать.
Это моя первая статья, если есть замечания прошу в комментарии.
Что такое inittab
По сути inittab представляет из себя файл в котором можно посмотреть/поменять уровень загрузки операционной системы в /etc/inittab. Давайте разберем его
В linux существуют 7 уровней загрузки операционной системы. В нашем случае нулевой уровень — это режим восстановления, первый — это запуск в одиночном режиме под root. 2-5 загрузка в мульти пользовательском режиме (т.е. обычный режим). Отличаются они лишь набором стартовых скриптов. 6 уровень это перезагрузка. Скрипты берутся из директорий, которые расписаны в inittab. Наша система по умолчанию загружается на 5 уровне, посмотрим что-же находится в директории /etc/init.d/rc 5:
Скрипты в этом каталоге выполняются каждый раз при старте системы. А если быть точнее это лишь символьные ссылки на сами скрипты. Первая буква означает S(start) K(kill или stop) для изменения порядка скриптов меняется цифра, т.е. запуск скриптов выполняется по возрастанию. Руками менять можно, но рекомендуется менять через «update-rc.d»
Все просто и прозрачно.
Что такое systemd
Systemd является заменой старой традиционной загрузки inittab. Был разработан чтобы обеспечить лучшую обработку зависимостей. В настоящее время systemd поставляется по умолчанию с популярными дистрибутивами linux таких как Fedora, Mandira, Arch Linux, CentOS 7, Red Hat 7.0 и на удивление для меня в Debian 8.9.
Плюсы и минусы в явном виде для меня не понятны. Интересен в первую очередь функционал. Итак разбираемся дальше. Две вещи, которые нам нужно знать:
Чтобы посмотреть уровень загрузки, введем команду:
Как правило graphical.target аналог 5 уровня, запуск системы в графическом режиме.
Чтобы посмотреть все доступные нам уровни, введем:
проведем аналогию c inittab
При старте системы linux смотрит в файл (который является ссылкой)
Таким образом чтобы загрузиться в многопользовательском режиме, нам нужно сменить ссылку или использовать systemctl (делает тоже самое)
Автозагрузка проложений
Как мы уже поняли в каталогах /etc/rc3.d/* лежат символьные ссылки на скрипты. Где цифры от 6 это уровень загрузки у inittab или systemd. Мы можем менять руками порядок запуска, убирать и добавлять. По сути systemd пробежится по всем файлам и попытается их инициализировать при старте системы. Теперь разберем управление через команды:
chkconfig — нужна для просмотра сервисов(программ). Поддерживает режим изменения для любого уровня загрузки.
update-rc.d — служит для запуска/остановки скриптов, при старте/выключении системы. Собственно через нее мы и будем менять автозапуск графической оболочки KDE(kdm). Так уж получилось, что у меня запуск окружения KDE включен для 2-5 уровней по умолчанию.
При старте системы я отключаю 2-4 уровень загрузки и проверяю что у меня стоит 3-й уровень загрузки
Перезагружаюсь и вижу приглашение консоли tty. profit
На самом деле, это чуть больше чем консоль. Мы можем переключаться между вкладками.
CTRL+ALT+(F1-F6)
команда startx запустит графику KDE.
Вывод: Тут должен быть вывод, но вместо него я вставлю кота
Debian Squeeze: параллельный автозапуск скриптов при старте системы
Введение
Осознание проблемы
Утром я поставил систему, установил все необходимые пакеты, дальше начинаю прикручивать к системе скрипты (собственно сервер же заводим не для того чтобы им любоваться, а для работы). Сразу же уточню: cкрипт настраивал проксирование пользователей в интернет, все настройки он брал из PostgreSQL. Таким образом он должен запускаться после того как будет сконфигурирована сеть и запущен демон СУБД. И тут начинается мистика, создаю символическую ссылку на скрипт:
ln /usr/proxy/scripts/start /etc/rc1.d/S99proxy
ln /usr/proxy/scripts/start /etc/rc2.d/S99proxy
ln /usr/proxy/scripts/start /etc/rc3.d/S99proxy
ln /usr/proxy/scripts/start /etc/rc4.d/S99proxy
ln /usr/proxy/scripts/start /etc/rc5.d/S99proxy
Перезагружаю сервер, и обнаруживаю что скрипт не запустился, во всяком случае нужных мне действий произведено не было. Начинаю хмуриться, в это время вспоминаю о статье, которую читал несколько дней назад. Помещаю симлинк в другое место:
ln /usr/proxy/scripts/start /etc/network/if-up.d/proxy
Перезагружаю систему, скрипт начинает выполняться, но снова провал. Скрипт настройки сети запускается раньше чем стартует демон СУБД, и соответственно содержимое /etc/network/if-up.d выполняется тоже раньше (собственно оно так и должно быть). Далее решаю поместить в директории rc*.d скрипт со следующим содержанием:
#!/bin/bash
echo «Run test» >> /var/log/test.log
Снова перезагружаю систему, результат нулевой. Помня все туже статью, в голову приходи дикая мысль о том что локальная файловая система не успела примонтироваться. Применяю метод админа-шамана:
#!/bin/bash
sleep 20
echo «Run test» >> /var/log/test.log
После перезагрузки обнаруживаю отсутствие файла /var/log/test.log. От такого облома я решаю схитрить — дописываю в скрипт запуска демона ssh строку с echo. После перезагрузки как и полагается обнаружил то что ждал, файл создался и строчка «Run test» в нем присутствует. Начинаю активно шевелить мозгами, в уме появляется уравнение: запуск скрипта не работает + новая система запуска скриптов при старте системы = неожиданное поведение. Вывод напрашивается один: надо гуглить искать решение в технических статьях и документации.
Вот где собака зарыта
В ходе исследования было выяснено что в Debian Squeeze используется система LSBInitScripts для запуска скриптов при загрузке ОС. Ее особенностью является — по возможности параллельный запуск скриптов. В предыдущем предложении слова «по возможности» являются ключевыми. Нельзя просто взять и параллельно запустить все скрипты, часть скриптов имеет определенные зависимости от других служб. В моем случае скрипт должен выполняться только после запуска СУБД и настройки сети. Для этого LSBInitScripts строит граф зависимостей. Его графическое представление можно увидеть выполнив команды:
В моем случае это получилась полнейшая кракозябра. Встал вопрос о том где же хранятся эти зависимости. В вики Debian’на выяснилось, что зависимости указываются в комментариях у скриптов в директории /etc/init.d, вот пример такого комментария для ssh:
Provides — это имя или несколько имен того с чем работает(запускает/останавливает) скрипт. Имена должны быть уникальны.
Required-Start— а вот это как раз и есть наша зависимость, которая указывает что потребуется скрипту для запуска.
Default-Start — показывает на каких уровнях нужно выполнять загрузку скрипта.
Более детальное описание параметров есть здесь.
Создаем свой скрипт
Теперь, когда мы знаем нашего врага в лицо можно попробовать написать пару простеньких скриптов. Вот первый, назовем его test:
echo «Run test» >> /var/log/test.log
echo «Run test2» >> /var/log/test.log
Файлы называются test и test2 соответственно. В данном примере test2 зависит от test, и поэтому test будет запускаться первым, а затем только test2. Поместим их в директорию /etc/init.d. Но этого еще мало, и даже мало будет создания симлинков в /etc/rc*.d. Что бы заставить все это дело работать необходимо выполнить построение нового графа зависимостей, делается это командами:
update-rc.d test defaults
update-rc.d test2 defaults
Со своим скриптом я больше сегодня не экспериментировал — голова уже начала плохо думать и время рабочее закончилось, займусь им завтра.
Заключение
В данной статье я не пытался полностью описать новый процесс запуска скриптов в Debian. Моей целью было дать отправную точку для изучения проблемы, сэкономить время других людей (у меня ушло несколько часов на поиск причины, чтение манов и эксперименты).