Цель и типичное использование /etc/rc.local

Заголовок выглядит так:

#!/bin/sh -e
#
# rc.local - executed at the end of each multiuser runlevel
#
# Make sure that the script will "exit 0" on success or any other
# value on error.

Какова причина этого файла (он не содержит много), и какие команды вы обычно помещаете в него? Что такое «многопользовательский уровень запуска»? (Я полагаю, rcэто "команды запуска"?)

Уровень запуска является состояние системы, указывающий , является ли он в процессе загрузки или перезагрузки или выключения, или в режиме одного пользователя, или работает в обычном режиме. Традиционная программа init обрабатывает эти действия, переключаясь на соответствующий уровень выполнения. Под Linux уровни выполнения по соглашению :

• S во время загрузки,
• 0 при выключении,
• 6 при перезагрузке,
• 1 в однопользовательском режиме и
• От 2 до 5 в обычном режиме.

Уровни выполнения со 2 по 5 известны как многопользовательские уровни выполнения, поскольку они позволяют нескольким пользователям войти в систему, в отличие от уровня запуска 1, который предназначен только для системного администратора.

Когда уровень запуска изменяется, init запускает сценарии rc (в системах с традиционным init - есть альтернативы, такие как Upstart и Systemd ). Эти сценарии rc обычно запускают и останавливают системные службы и предоставляются дистрибутивом.

Скрипт /etc/rc.localпредназначен для использования системным администратором. Он традиционно выполняется после запуска всех обычных системных служб, в конце процесса перехода на многопользовательский уровень выполнения. Вы можете использовать его для запуска пользовательской службы, например, сервера, на котором она установлена /usr/local. Большинство установок не нужно /etc/rc.local, это предусмотрено для меньшего количества случаев, когда это необходимо.

rc обозначает «контроль выполнения»,

Уровень multiuserвыполнения будет определяться как уровень, на котором сеть доступна, и, таким образом, соединения с сервером могут быть установлены с использованием этих служб вместо проводных консольных соединений.

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

Что касается rc.localфайла, это удобство, позволяющее вам указать все «локальные» (специфичные для сайта) объекты (демоны и / или скрипты, запускаемые при загрузке), которые вы хотите запустить. Вы можете выбрать использование этой парадигмы или заполнить '/etc/init.d' сценариями запуска / остановки соответственно.

Я в основном использую его для двух вещей:

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

2. восстановить старый каталог /etc/rc.boot/, который был в Debian несколько лет назад. У меня все еще есть несколько простых сценариев, которые не стоит переписывать как сценарий init.d (например, сценарий Q & D для отправки dmesg по почте в root, и другой сценарий, использующий hdaparm для отключения простоя spindown и blockdev для установки read- впереди размера), и я рад за их запуск после всех других сценариев загрузки.

например

echo "$(date +%s),$(date),$(uname -a)"  >> /var/log/reboot.log

[ -d /etc/rc.boot ] && run-parts /etc/rc.boot

Кроме того, в начале этого года я написал сценарии /etc/rc.local для дистрибутивов centos и debian для получения метаданных в стиле ec2 из openstack (on http://169.254.169.254/), чтобы виртуальные машины могли получать свои IP, имя хоста, ключи ssh и другую информацию, специфичную для экземпляра. , С тех пор cloud-init был перенесен в эти дистрибутивы, поэтому сценарии устарели.

rc.localФайл на Debian в основном для совместимости с системами типа без инициализации. Вы не должны использовать это.

Вместо этого рекомендуется скопировать /etc/init.d/Skeletonв новый сценарий инициализации то, что вы хотите, чтобы происходило при изменении уровней выполнения, а затем использовать inservдля его включения.

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