Как добавить скрипт в автозагрузку Ubuntu
Иногда возникает необходимость выполнить свой скрипт во время загрузки системы. Например, чтобы запустить определенную программу, поменять настройки разрешения экрана или выполнить обновление необходимой программы.
Сделать это можно несколькими способами. С помощью графической оболочки или с помощью системы инициализации systemd, которая используется сейчас практически во всех дистрибутивах.
Автозагрузка с помощью стандартной утилиты Ubuntu
Создайте скрипт в удобном месте и сделайте его выполняемым:
sudo gedit /путь_к_скрипту/имя_скрипта.sh
#!/bin/bash
echo «Hello world»
Наш скрипт просто выводит строчку Hello world на экран, более подробно о создании скриптов читайте в статье написание скриптов на Bash. Когда скрипт будет готов, сделайте его исполняемым:
sudo chmod ugo+x /путь_к_скрипту/имя_скрипта.sh
Запустите утилиту Автоматически запускаемые приложения в главном меню системы:
Нажмите кнопку Добавить и в поле Команда введите полный путь к файлу вашего скрипта или выберите его с помощью кнопки Обзор, затем нажмите Добавить:
Скрипт будет выполнен после загрузки графической оболочки Ubuntu.
Автозагрузка скриптов Linux в systemd
Создайте файл сервиса systemd с помощью следующей команды:
Добавьте в него такое содержимое:
[Unit]
Description=My Script Service
After=multi-user.target
[Service]
Type=idle
ExecStart=/полный/путь/к/скрипту/имя_скрипта.sh
[Install]
WantedBy=multi-user.target
В строчке ExecStart можно прописать либо путь к скрипту, который надо выполнить, либо саму команду. Теперь добавьте этот скрипт в автозагрузку:
sudo systemctl daemon-reload
sudo systemctl enable mysrcipt
Автозапуск python скрипта на Raspberry Pi.
Сегодня будет статья / заметка / ответ на часто задаваемый вопрос. Итак, кратчайшая предыстория 🙂 На нашем форуме был опубликован вопрос по поводу автозапуска скрипта при включении Raspberry. И внезапно пришло осознание, что вопрос этот возникает достаточно часто, так, почему бы, собственно, не оформить ответ на него более глобально. То есть в виде заметки на основном сайте. Так что, переходим к реализации.
Итак, способы решения поставленной задачи многообразны и разнообразны. Разберем несколько из них, может пару-тройку… Кстати любые комментарии по данной теме крайне приветствуются – другие варианты, плюсы/минусы, идеи, вопросы )
Создаем подопытный скрипт на python’е – script.py. Что он будет делать в данном случае вообще не важно, я возьму тестовый скрипт с ШИМ:
Останавливаться на его работе не будем, в общем-то в статье про ШИМ все это есть. Физически файл у меня находится в:
Для запуска скрипта соответственно:
Переходим к сути дела – автозапуску.
Вариант 1. Автозапуск скрипта через /etc/profile.
При запуске оболочки bash последняя использует набор стандартизированных файлов для создания окружения. К этим файлам относится и /etc/profile. Мы под шумок можем поместить в этот файл дополнительную команду, выполняющую запуск нашего скрипта. Открываем файл в редакторе:
И добавляем в конец файла строку:
Сохраняем файл, закрываем – на этом все, задача решена. Но тут необходимо упомянуть два дополнительных нюанса.
Первый связан с тем, что в соответствии с механизмом, который мы использовали, команда будет выполняться каждый раз при запуске bash в интерактивном режиме. То есть, в частности, при запуске терминала, либо при подключении к плате по SSH. Скрипт в данных случаях будет запускаться каждый раз. Дальше уже нужно смотреть по конкретной цели – нужно это или нет.
Второй нюанс заключается в том, что работать с командной строкой можно будет лишь по окончанию выполнения скрипта. И если скрипт, например, содержит бесконечный цикл, либо операции, требующие некоторого времени, то в конце команды нужно добавить амперсанд – &:
Эта модификация приведет к выполнению команды в отдельном потоке, что решает обозначенную выше проблему.
Вариант 2. Автозапуск скрипта через /etc/rc.local.
В данном случае команда, добавленная в этот файл, будет выполняться уже однократно – при запуске ОС (т. е. при включении платы). Сам процесс организации автозапуска по сути идентичен, открываем файл для редактирования:
И в конце файла, но(!) перед “exit 0” добавляем запуск скрипта:
Обращаем внимание на & в конце строки – причина его использования все в том же – обеспечить выполнение скрипта в отдельном потоке. В данном случае это еще более важно. Поскольку команды из rc.local будут выполняться в процессе загрузки системы, то запуск пользовательского скрипта с бесконечным циклом приведет попросту к тому, что система не стартанет. Так что бдительность и внимательность! 👍
По той же причине, что скрипт будет выполняться при загрузке системы, получить обратную связь от него проблематично. И если там будет ошибка, и ОС не запустится, то поиск этой ошибки может стать непростой задачей. К счастью, очень просто организовать логирование выполнения скрипта. Для этого модифицируем команду запуска:
Теперь в файл /home/pi/PythonScripts/script_log.txt будет записан, во-первых, вывод скрипта (то, что там находится в print() ), и, во-вторых, ошибки, если таковые имели место при его выполнении.
Так, на этом и заканчиваем тогда обзор данной проблемы, спасибо за внимание, прочтение, обратную связь 🙂
Как запустить python скрипт на ubuntu чтобы он не отключался?
Вариантов много, вот то, что придумал с ходу:
1. Запустить скрипт в bash с nohup.
2. Запускать скрипт в сессии tmux и просто детачиться из неё. Сессия продолжит работать. Это всё тот же ручной запуск скрипта.
3. Создать сервис systemd.
4. Запускать в фоне с помощью supervisor.
Если нужно, чтобы скрипт работал и запускался без участия человека, то варианты 3 и 4.
Systemd конечно оч. хорошо, но и Supervisor прекрасно справляется с такими задачами.
Я, например, и многие мои собратья по Проксе-Пепсика (на Python3) запускаем её, как раз через Supervisor, что весьма удобно.
Всё просто.
Сначала устанавливаете его:
sudo apt install supervisor
Если этого не сделать, то в папке /etc/supervisor будет лежать очень урезанный и бедный на настройки supervisord.conf файл и многие параметры придётся дописывать руками!
Судите сами:
— это урезанный файл после установки Supervisor
— а это полный файл со всеми параметрами, после его создания командой
Можно все настройки сделать в этом файле, но это не очень хороший тон!
Там же, в папке /etc/supervisor, после его (Supervisor) установки создаётся папка conf.d.
Полный путь:
/etc/supervisor/conf.d
Вот в неё-то, по правилам хорошего тона и ложат на каждый сервис/процесс отдельный Воркер/Юнит, в котором и прописывают запуск Python2/3 скрипта.
В моём случае:
Для примера, мои:
— конфигурационный файл supervisord.conf
— Воркер в /etc/supervisor/conf.d
Апосля всех правок конфигурационного файла и создания Воркера, обязательно перезапуск Supervisor:
И усё.
После каждого старта системы, всё будет работать.
Веб-морда Supervisor по адресу:
(доступна при условии, что у вас установлен веб-сервер)
http://localhost:9001/
Dr. Bacon, мне накидать вам холиваров о systemd, чтобы вам угодить?!
Также могу накидать холиваров и про Supervisor.
У Supervisor есть свои преимущества и Systemd по своему хорош и это тот самый случай, когда надо начинать мериться 3,14сюнами, у кого круче?!
Как вариант Supervisor и он нисколько не хуже Systemd.
Проблема с автозагрузкой python-скрипта?
1. а это именно ваш скрипт? Скрипт только в /etc/init.d/? тогда ещё команда требуется update-rc.d имяскрипта defaults 80 чтобы создались симлинки в /etc/rc?.d
3. посмотрите — какие есть ошибки от этого скрипта.
1. Именно мой. В /etc/init.d/ не сам скрипт, а bash-скрипт со строкой «/usr/bin/python /path/to/script.py». update-rc.d делал.
2. И от рута, и от обычного пользователя вручную стартует без нареканий.
3. Как именно это посмотреть?
И права на файл-устройство порта проверить бы тоже.
А с top’ом еще употребить lsof / fuser /… чтобы посмотреть, открыт ли порт на самом деле.
Ну и вывод из самого скрипта — суровое, проверенное средство.
Вам в лог надо отписывать не только вывод print, но и ошибки.Для этого строка запуска должна быть такая
/usr/bin/python /path/to/script.py >>/tmp/pyscript.log 2>&1
Runscript — утилита для запуска python скриптов
Думаю многим знакома следующая ситуация. В вашем проекте есть различные действия, которые нужно выполнять время от времени. Для каждого действия вы создаёте отдельный скрипт на питоне. Чтобы далеко не лазить, скрипт кладёте в корень проекта. Через некоторое время вся корневая директория проекта замусоривается этими скриптами и вы решаете сложить их в отдельную директорию. Теперь начинаются проблемы. Если указать интерпретатору python путь до скрипта, включающий эту новую директорию, то внутри скрипта не будут работать импорты пакетов, находящися в корне проекта т.к. корня проекта не будет в sys.path. Эту проблему можно решить несколькими способами. Можно изменять sys.path в каждом скрипте, добавляя туда корень проекта. Можно написать утилитку для запуска ваших скриптов, которая будет изменять sys.path перед запуском скрипта или просто будет лежать в корне проекта. Можно ещё что-то придумать. Мне надоело каждый раз изобретать колесо и я создал велосипед runscript на котором с удовольствием катаюсь.
Установить библиотеку можно с помощью pip:
После установки библиотеки runscript, вы получаете в вашей системе новую консольную команду run с помощью которой можно запускать скрипты. По-умолчанию, команда run ищет скрипты в под-каталоге script текущего каталога.
Давайте рассмотрим простой пример. Создадим каталог script. Создадим пустой файл script/__init__.py, превратив этот каталог в python-пакет. Теперь создадим файл script/preved.py со следующим содержимым:
Скрипт готов. Теперь мы можем его запустить:
Ура! Скрипт работает. Вот собственно и всё, что делает библиотека runscript. Я серьёзно 🙂 Команда run запускает функцию main из файла, имя которого вы ей передали в командной строке. Оказалось, что даже такой простой фунционал очень удобен. Я с удивлением заметил, что пользуюсь утилиткой run в каждом своём проекте т.к. везде есть простенькие скрипты, которые нужно запускать.
Со временем утилита run обросла рядом полезных полезностей, о которых я сейчас расскажу.
Получение параметров через командную строку
Чтобы передать вашему скрипту какие-либо параметры через командную строку, вам нужно описать эти параметры в функции setup_arg_parser внутри вашего скрипта. Эта функция получает на вход объект ArgumentParser, в который вы можете добавить нужные опции. Далее, когда скрипт будет вызван, значения параметров командной строки будут переданы фунции main. Пример скрипта:
Обратите внимание, как фунция main получила параметры командной строки — в виде обычных именованных параметров. Всегда нужно указывать **kwargs т.к. кроме нужных вам параметров, передаются значения всех глобальных для утитилы run параметров (читайте о них ниже).
Активация Django
Если вы пытались использовать фреймворк Django в ваших консольных скриптах, то знаете, что нужно сделать кое-что, иначе ничего не будет. Кое-что заключается в создании environment переменной DJANGO_SETTINGS_MODULE, cодержащей путь до модуля с настройками. Обычно в python скрипт добавляют следующие строки:
Начиная с django 1.7 нужно также выполнить