Призначення та типове використання /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 відомі як багатокористувацькі рівні запуску, оскільки вони дозволяють увійти в систему декільком користувачам, на відміну від runlevel 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 сценарії на початку цього року для центів та debian дистрибутивів, щоб отримати метадані в стилі ec2 з opentack (увімкнено http://169.254.169.254/), щоб VM отримали свої IP, ім'я хоста, ssh-ключі та іншу специфічну інформацію . cloud-init з тих пір переноситься на ці дистрибутиви, тому сценарії зараз застаріли.

rc.localФайл на Debian в основному для сумісності з системами типу без ініціалізації. Не слід його використовувати.

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

Оновлення: Відповідно до коментаря нижче, ця відповідь більше не рекомендується. Однак ця відповідь була розміщена за кілька років до знецінення скелета, і цей скелет все ще існує в Debian нестабільно станом на січень 2019 року.