Debian 10 rc, локальный нет

Обновлено: 02.07.2024

У меня есть новый RPi-Zero-W со свежей установкой последней версии 2021-05-07-raspios-buster-armhf-full.zip, которая была полностью обновлена. Я настроил машину для загрузки в CLI, где пользователь pi может затем войти в систему.

По завершении процесса загрузки и до того, как кто-либо войдет в систему, я хочу отобразить IP-адрес, полученный через DHCP, в интерфейсе командной строки. Я просмотрел файл /etc/rc.local по умолчанию и обнаружил, что это именно то, что должно происходить, но это не работает на моей машине.

Пока я не нашел решения.

Вот файл /etc/rc.local по умолчанию:

Но «биты выполнения» — это 755 root/root, который может запустить любой (см. мой пример выше как пользователь pi без sudo). Так что же означают эти комментарии? Какие «исполнительные биты» нужно изменить, чтобы /etc/rc.local заработал? Я знаю, что /etc/rc.local — это пережиток совместимости с System V, и некоторые говорят, что никогда не пытайтесь заставить /etc/rc.local работать в systemd. Если это так, какова лучшая альтернатива запуску чего-то вроде команды «ifconfig» или «hostname -I» в конце процесса загрузки, прежде чем кто-либо войдет в систему?

Спасибо, Дэвид

В настоящее время выполнение rc.local контролируется systemd. По умолчанию на Raspios он запускается ближе к концу загрузки. Вроде, как бы, что-то вроде.
Я помню, что видел машины с Ubuntu, на которых служба rc.local systemd не была включена по умолчанию.
Возможно, вы можете проверить, действительно ли systemd пытается запустить rc.local, и при необходимости повторно включить службу.

"В настоящее время выполнение rc.local контролируется systemd. По умолчанию на Raspios он запускается ближе к концу загрузки. Вроде того."

Через raspi-config > 1 Параметры системы > Экран-заставка S7 > Вы хотите показывать заставку при загрузке? Я отключил заставку, чтобы точно видеть, что происходит в командной строке во время процесса загрузки. Я не вижу, чтобы /etc/rc.local когда-либо выполнялся на протяжении всего процесса загрузки, а тем более «ближе» к концу. Этого просто не происходит.

"Я помню, что видел машины Ubuntu, на которых служба rc.local systemd не была включена по умолчанию. Может быть, вы можете проверить, действительно ли systemd пытается запустить rc.local, и при необходимости снова включить службу."

Я подозреваю, что то же самое/похожее происходит с ОС RPi, но я не знаю, как проверить, действительно ли systemd пытается запустить /etc/rc.local, или, если нет, как повторно включить его. Вот почему я публикую здесь вопрос, почему файл /etc/rc.local не работает и как это исправить. Возможно, вы можете помочь с этим?

Raspios выполняет его, то есть в только что установленной системе.
Боюсь, я не смогу помочь, systemd не очень моя сильная сторона.

Биты выполнения rc.local уже установлены по умолчанию. Больше ничего делать не нужно.

Для примера в rc.local требуется сеть. Поэтому, чтобы заставить его работать, вам нужно установить параметр ожидания сети при загрузке в sudo raspi-config.
Простой способ проверки — изменить строку printf, как показано ниже.

Если не указано иное, мой ответ основан на последней и полностью обновленной ОС RPi Bullseye с ОС для настольных ПК.

РЕШЕНО: /etc/rc.local не запускается в конце процесса загрузки – почему?

"Для примера в rc.local требуется сеть. Поэтому, чтобы он работал, вам нужно установить параметр ожидания сети при загрузке в sudo raspi-config."

В raspi-config> 1 Параметры системы> Сеть S6 при загрузке> Вы хотите, чтобы загрузка ждала, пока не будет установлено сетевое подключение? по умолчанию установлено значение «Нет», я изменил его на «Да». Я перезагрузился. Теперь начиная с восьмой строки до окончания процесса загрузки я вижу это:

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

@klricks, большое спасибо за помощь.

У меня есть несколько общих предложений по этому вопросу. Я оставлю их здесь как напоминание себе:

<р>1. Эти странные комментарии в /etc/rc.local:

Должен быть удален. Нет ничего плохого в разрешениях по умолчанию /etc/rc.local. В /etc/rc.local следует добавить комментарий, объясняющий, как raspi-config > 1 Параметры системы > Сеть S6 при загрузке > Вы хотите, чтобы загрузка ждала, пока не будет установлено сетевое соединение? чтобы параметр /etc/rc.local работал по умолчанию, необходимо установить значение «Да».

Должно быть обновлено, чтобы объяснить, как raspi-config> 1 Параметры системы> Сеть S6 при загрузке> Вы хотите, чтобы загрузка ждала, пока не будет установлено сетевое подключение? чтобы параметр /etc/rc.local работал по умолчанию, необходимо установить значение «Да».

Иногда я видел, как эта штука сообщала мне, что мой адрес 169.254.something. Так что зависимость от сети, я думаю, не так очевидна.

<р>.
В /etc/rc.local следует добавить комментарий, объясняющий, как raspi-config > 1 Параметры системы > Сеть S6 при загрузке > Вы хотите, чтобы загрузка ждала, пока не будет установлено сетевое соединение? для параметра по умолчанию должно быть установлено значение «Да» для файла /etc/rc.местный для работы.

Это неправда. rc.local запускается независимо от параметра ожидания сети. Это только пример кода в rc.local, который не будет работать без включения настройки сети. Я проверил это с кодом, который не нуждается в сети, и он работает в любом случае.

rc.local запускается службой systemd с именем «rc.local» и запускается независимо от параметра ожидания сети, как упоминал @klricks.

Вы сказали: "Это неправда. rc.local работает независимо от параметра ожидания сети. Это только пример кода в rc.local, который не будет работать без включения параметра ожидания сети. Я тестировал это с кодом, который не нуждается в сети и работает в любом случае."

Именно поэтому в моем сообщении, которое вы процитировали, я сказал: ". option должно быть установлено значение Yes, чтобы /etc/rc.local по умолчанию работал". Ключевое слово здесь — «по умолчанию», когда речь идет о скрипте /etc/rc.local, который поставляется с ОС RPi. Я сделаю отдельный пост, чтобы прояснить это.

Вы сказали, что "rc.local запускается службой systemd с именем "rc.local" и работает независимо от параметра ожидания сети, как упоминал @klricks".

Спасибо за объяснение и предоставление кода. Я согласен, /etc/rc.local работает независимо от состояния сети. См. мой пост ниже, где я разъясняю это.

Я хотел бы здесь кое-что прояснить. Другие уже упоминали об этом (спасибо), но я не видел сообщения, пока работал над этим сообщением.

Установка параметра «ожидание сетевой загрузки» в raspi-config в значение «Да» необходимо для работы сценария /etc/rc.local по умолчанию, поскольку все, что делает /etc/rc.local, — это показывает IP-адрес и если сеть еще не готова, IP-адрес не доступен для отображения.

Установка параметра raspi-config «ожидание сетевой загрузки» в значение «Да» или «Нет» не влияет на запуск /etc/rc.local или нет. В обоих случаях запустится файл /etc/rc.local.

Простой тест: добавьте одну строку в /etc/rc.local, например, "echo "Hello World"", установите для параметра ожидания сетевой загрузки значение "Нет", затем перезагрузите компьютер. Теперь при запуске /etc/rc.local IP-адрес не будет отображаться, но появится «Hello World». Это доказывает, что /etc/rc.local все еще работает.

Вот как я просто изменил свой сценарий /etc/rc.local, чтобы напомнить себе об этом:

Вот как выглядит результат, если для параметра «Ожидать загрузки по сети» в raspi-config установлено значение «Да» и с доступной сетью:

У меня есть несколько общих предложений по этому вопросу. Я оставлю их здесь как напоминание себе:

<р>1. Эти странные комментарии в /etc/rc.local:

Эти комментарии полностью действительны. Они расскажут вам, как включить и отключить сценарий, если вы захотите сделать это позже.

Технически это верно, но все равно вводит в заблуждение. Я могу понять, как предыдущий автор может законно утверждать, что они «странные» (обратите внимание на орфографию).

Если вы используете дистрибутив Linux, использующий Systemd, вы можете обнаружить, что ваша команда в файле /etc/rc.local не будет выполняться во время загрузки системы. В этом руководстве объясняется, как включить запуск сценария /etc/rc.local при запуске системы.

Включить /etc/rc.local в Systemd

Если вы введете следующую команду в терминале:

Вы можете получить следующий вывод:

И если вы попытаетесь включить /etc/rc.local для запуска при загрузке системы с помощью команды:

Решение

Как вы можете видеть выше, файл модуля не имеет раздела [Install]. Таким образом, Systemd не может его включить. Сначала нам нужно создать файл:

Затем добавьте к нему следующий контент.

Сохраните и закройте файл. Чтобы сохранить файл в текстовом редакторе Nano, нажмите Ctrl+O , затем нажмите Enter для подтверждения. Чтобы выйти из файла, нажмите Ctrl+X. Затем выполните следующую команду, чтобы убедиться, что файл /etc/rc.local является исполняемым.

Примечание. Начиная с версии 16.10 Ubuntu больше не поставляется с файлом /etc/rc.local. Вы можете создать файл, выполнив эту команду.

Затем добавьте разрешение на выполнение в файл /etc/rc.local.

После этого включите службу при загрузке системы:

Теперь запустите сервис и проверьте его статус:

Крон при перезагрузке

Если описанный выше метод вам не подходит или вы просто хотите, чтобы некоторые простые команды выполнялись при загрузке системы, вы также можете использовать функцию @reboot в cron для автоматического выполнения команды при загрузке системы. Например, я хочу, чтобы мой клиент shadowsocks запускался автоматически, поэтому я открываю файл cron пользователя root:

И поместите следующую строку в конце.

Сохраните и закройте файл.

В некоторых дистрибутивах Linux, таких как archlinux, демон cron не включен по умолчанию. Поэтому вам нужно включить его вручную. Чтобы включить его в archlinux, введите следующую команду в терминале.

Shadowsocks — это прокси-сервер socks5, который можно использовать для обхода интернет-брандмауэров. Если вам интересно, нажмите на ссылку ниже, чтобы узнать, как настроить собственный сервер shadowsocks.

Как использовать Systemd

Хотите узнать больше о systemd для эффективного управления вашей системой? Прочтите следующее руководство.

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

Опубликовано: 1 октября 2019 г. | Дэвид Бот

Недавно я столкнулся с двумя разными проблемами на двух разных хостах Linux. Каждый требовал уникального обхода, потому что мне еще предстоит найти реальное решение. Однако метод обхода обхода был одинаковым: запускайте команду во время или вскоре после запуска Linux.

Дополнительные ресурсы по Linux

Файл rc.local был — и в некоторых случаях до сих пор остается — местом, где системные администраторы Linux могли помещать команды, которые необходимо запускать при запуске. Использование файла rc.local не только не рекомендуется, но и после нескольких часов попыток не работает в любом случае. И это несмотря на то, что в документации systemd упоминается использование «генератора», который генерирует службы systemd из файла rc.local, если он существует. (Кажется, это хороший способ добиться устаревания — сделать так, чтобы он не работал.)

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

Загрузка и запуск

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

В целом процесс загрузки и запуска Linux довольно прост для понимания. Он состоит из следующих шагов, которые будут описаны более подробно позже:

Самопроверка BIOS при включении питания (POST)
Загрузчик (GRUB2)
Ядро
системный

Более подробное описание последовательности загрузки и запуска см. в моей статье Введение в процессы загрузки и запуска Linux.

Локальный запуск

Системные администраторы иногда добавляют в последовательность запуска команды, полезные локально. Эти дополнения могут быть направлены на запуск или запуск локальных процессов, которые не являются частью стандартного запуска systemd. Можно добавить новую единицу службы systemd для запуска каждой программы, необходимой при запуске, но старый метод rc.local предоставлял один исполняемый файл для любых локальных потребностей запуска. Мы тоже можем использовать этот подход с одним файлом с systemd. Элегантность этого решения заключается в том, что оно упрощает добавление дополнительных команд запуска в более позднее время без необходимости добавления дополнительных сервисных единиц в systemd .

Наше решение состоит в том, чтобы создать единую единицу службы systemd и поместить все необходимые команды Linux в исполняемый файл. Это решение состоит из двух частей. Одно очевидно: нам нужен исполняемый файл. Во-вторых, нам нужно создать сервисный модуль для systemd, который запускает исполняемый файл.

Создайте исполняемый файл

Это простое упражнение для любого системного администратора, знакомого с программированием на Bash. На самом деле мы создадим программу Bash и поместим ее в расположение иерархического стандарта файловой системы Linux (FHS) для локальных исполняемых файлов, /usr/local/bin . Можно привести аргумент в пользу размещения этого исполняемого файла в другом месте, но /usr/local/bin — это то, что имеет для меня наибольший смысл, поскольку это расположение позволяет системному администратору легко запускать скрипт из командной строки, если это необходимо. . Каталог /usr/local/bin всегда находится в $PATH каждого пользователя, включая пользователя root.

Создайте показанный здесь файл mystartup.sh и поместите его в /usr/local/bin (не забудьте сделать его исполняемым). Обязательно используйте расположение для Bash, правильное для вашего дистрибутива. Например, дистрибутивы на основе Debian располагают Bash по адресу /bin/bash .

Примечание. Комментарии во включенных файлах сообщают вам, где они должны располагаться.

Обязательно протестируйте этот исполняемый файл, запустив его из командной строки. При первом запуске этого сценария оболочки вы должны увидеть новый файл /root/mystartup.log со временем и датой вместе с текстом «Запуск сработал».Мы создаем этот файл журнала и добавляем в него строки каждый раз, когда скрипт запускается в качестве простого теста, чтобы убедиться, что наш скрипт работает.

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

Создайте службу systemd

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

Создайте новый файл /usr/local/lib/systemd/system/mystartup.service и добавьте содержимое, показанное ниже:

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

Теперь перейдите в /etc/systemd/system и создайте символическую ссылку в файле сервисного модуля:

Протестируйте блок обслуживания

Мы должны протестировать окончательный файл сервисного модуля перед перезагрузкой хоста Linux для финального теста. Во-первых, давайте проверим, что systemd видит службу:

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

Проверьте содержимое файла журнала, чтобы убедиться, что новая строка была добавлена.

Включить службу

Осталось только включить службу, чтобы она запускалась при запуске:

Заключительный тест

Перед перезагрузкой давайте рассмотрим команду journalctl и то, как мы можем использовать ее для просмотра записей журнала, относящихся к mystartup.service . Мы также можем использовать команду journalctl, чтобы проверить это, потому что systemd ведет журнал всего, что делает.

В следующей команде параметр -u показывает только записи для модуля mystartup:

Теперь перезагрузите хост Linux и проверьте файл журнала, чтобы убедиться, что была добавлена новая строка:

Заключение

Сценарий оболочки Bash, который мы создали для этого эксперимента, запускается один раз при запуске, а затем закрывается. Он не остается в памяти как демон, потому что он не был предназначен для этого.

Если вы не заметили, процедура, которую мы использовали для создания нашей локальной службы запуска, также может быть использована для создания любой новой службы для systemd. Это не так сложно, если мы знаем, как это сделать.

Обновить

Вскоре после публикации этой статьи я получил электронное письмо от Тома Мерфи, который сообщил мне о существовании службы rc-local, которая является частью systemd. Я ценю это письмо, потому что я не знал об этой услуге, поэтому я узнал что-то новое.

Сценарий rc.local в некоторых дистрибутивах Linux и системах Unix представляет собой сценарий запуска суперпользователя, обычно расположенный в каталоге /etc/etc/rc.d. Имя файла rc относится к Run Control.

Rc.local — это устаревший скрипт, сохраненный в целях совместимости с системами systemV.

Когда-то это был универсальный файл, присутствующий в большинстве дистрибутивов Linux из-за простоты, позволявшей администраторам Linux определять сценарии запуска или дополнительные службы для запуска.
Файл rc.local не содержит информации о компонентах запуска системы, а только о компонентах, определенных суперпользователем/корневым пользователем. Однако в rc.local описаны не все программы запуска root, а только те, которые не мешают компонентам системы. Обычно rc.local выполняется после запуска обычных служб.

В более новых системах Linux, включая Systemd, сценарий rc.local заменен, но его можно восстановить, несмотря на то, что это рекомендуемое решение. В этом руководстве показано, как восстановить и использовать скрипт rc.local, а также использовать rc-local by systemd в новых дистрибутивах Linux.

Включение /etc/rc.local в дистрибутивах Linux с помощью Systemd:

ВАЖНО: важно помнить, что файл /etc/rc.local больше не поддерживается и заменен. Текущий метод запуска сценариев при загрузке описан после инструкций по включению /etc/rc.local. Это руководство предназначено для пользователей с особыми потребностями.

Для начала создайте файл /etc/rc.local, используя нужный редактор и sudo (или root):

Вставьте приведенный ниже код в файл и замените его командой, которую вы хотите запускать при запуске. Не используйте судо. Если команда, включенная в этот сценарий, не будет выполнена, служба, которая вызовет rc.local (rc-local.service), перестанет работать.

выход 0

В моем примере я буду использовать сценарий rc.local для обновления базы данных vuls сканирования безопасности при каждом запуске системы. Вы можете написать любой сценарий, который должен выполняться при запуске, за исключением сетевых сценариев (таких как iptables), которые могут мешать нормальному процессу запуска и иметь свои собственные сценарии запуска или каталоги.

Сохраните файл (CTRL+X и Y) и предоставьте ему права на выполнение, выполнив следующую команду:

Создайте файл /etc/systemd/system/rc-local.service, запустите:

Вставьте следующие команды и выйдите из сохранения, нажав CTRL+X и Y.

ExecStart = /etc/rc.local start
TimeoutSec = 0
StandardOutput = tty
RemainAfterExit = yes
SysVStartPriority = 99

[ Установить ]
WantedBy =multi-user.target

Теперь вы можете запустить rc-local.service, который будет читать файл /etc/rc.local. Запустите команду, показанную ниже:

Вы можете проверить правильность загрузки rc-local, выполнив следующее:

Правильный способ (Systemd):

Описанный выше процесс устарел и может привести к сбою некоторых служб.
В этом разделе показан текущий процесс запуска сценариев или служб при загрузке дистрибутивов Linux с использованием Systemd.

Systemd — это диспетчер служб, который назначает группы управления службами (cgroup) и отслеживает процессы. Systemd — это процесс (PID) 1, отвечающий за запуск системы.

Чтобы добавлять службы или сценарии при запуске, необходимо создать модуль systemd.
Системные единицы включают службы (.service), точки подключения (.mount), устройства (.device) или сокеты (. гнездо). В отличие от старого процесса, описанного ранее с rc.local, вместо редактирования того же файла, содержащего информацию о пользовательских скриптах, вам нужно создать служебную единицу Systemd для каждого скрипта, который вы хотите запускать при запуске.

Модули systemd расположены в /etc/systemd/system, и именно там нам нужно создать модуль systemd для скрипта, который мы хотим запускать при загрузке.

На следующем изображении показано содержимое модуля TeamViewer.service.

Где директивы [Unit]:

Description= Эта директива описывает устройство; вы можете задать имя устройства.
Requires= Здесь можно указать зависимости для предотвращения сбоев при запуске.
Wants= Как и в предыдущем случае, он поддерживает работу службы, даже если не находит определенные зависимости.
After= Устройство запустится после указанного в этой директиве времени.

Некоторые директивы, используемые в разделе [Service], могут использоваться совместно с [Unit].

Type= В показанном выше примере разветвление указывает на то, что служба будет остановлена, оставив дочерние процессы, которым должен быть назначен PID.
Директива PIDFile= Forking требует директивы PIDFile, которая должна содержать путь к pid файла дочернего процесса, чтобы Systemd мог его идентифицировать.
ExecStart= Здесь вы указываете путь и команды, которые хотите выполнить. Это похоже на файл rc.local.
Restart= Эта директива указывает Systemd, когда перезапускать устройство. Доступны следующие варианты: при сбое, при прекращении, всегда, при успехе, при контроле или при отклонении от нормы.
StartLimitInterval= Эта директива указывает, что у устройства есть 60 секунд на 10 попыток перезапуска в случае сбоя.
StartLimitBurst= Эта директива указывает лимит попыток, в приведенном выше примере 10 попыток за 60 секунд.

Единственная директива [Install] в приведенном выше примере — WantedBy.

WantedBy= Здесь вы можете указать этот блок как зависимость; она аналогична директиве Wants, но определение текущей единицы считается зависимостью другой единицы.

Добавление собственного модуля Systemd:

Чтобы запустить скрипт при запуске, создайте его в /etc/systemd/system, указав его имя, за которым следует точка и сервис, например, linuxhint. Служба. Вы можете использовать nano, как в следующем примере:

Вставьте следующее, заменив описанием вашего скрипта, а вместо /usr/sbin/linuxhint.sh напишите правильный путь.

[ Unit ]
Description = имя или описание сценария >

[ Установить ]
WantedBy =multi-user.target

Затем включите новую службу, выполнив:

Запустите службу и проверьте ее работу, выполнив:

Ваш скрипт готов к запуску при запуске.

Вывод:

Хотя Systemd кажется намного сложнее, чем старый rc.local, каждая служба или скрипт представляет собой уникальный модуль, гарантирующий большую стабильность системы.

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

Кроме того, Systemd предоставляет инструменты, которых нет в rc.local, для решения большего количества ситуаций и спецификаций.

Другие преимущества Systemd включают простоту контроля и управления процессами (что не было объяснено в этом руководстве). Systemd также позволяет группировать службы и содержит более подробные выходные данные об ошибках.

Надеюсь, это руководство оказалось для вас полезным. Продолжайте следовать Linux Hint, чтобы получить дополнительные советы и руководства по Linux.

Об авторе

Дэвид Адамс

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

Читайте также: