Cel i typowe użycie /etc/rc.local

Nagłówek wygląda następująco:

#!/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.

Jaki jest powód tego pliku (nie zawiera dużo) i jakie polecenia zwykle w nim umieszczasz? Co to jest „poziom uruchamiania dla wielu użytkowników”? (Chyba rc„uruchom polecenia”?)

Poziom pracy jest stan systemu, ze wskazaniem, czy jest on w trakcie uruchamiania lub restartowania lub wyłączania lub w trybie pojedynczego użytkownika, czy działa normalnie. Tradycyjny program init obsługuje te akcje, przełączając się na odpowiedni poziom działania. W systemie Linux poziomy uruchamiania są zgodne z konwencją :

• S podczas uruchamiania,
• 0 podczas zamykania,
• 6 podczas ponownego uruchamiania,
• 1 w trybie pojedynczego użytkownika oraz
• 2 do 5 podczas normalnej pracy.

Poziomy pracy od 2 do 5 są znane jako poziomy pracy dla wielu użytkowników, ponieważ pozwalają na zalogowanie się wielu użytkownikom, w przeciwieństwie do poziomu pracy 1, który jest przeznaczony tylko dla administratora systemu.

Kiedy zmienia się poziom działania, init uruchamia skrypty rc (w systemach z tradycyjnym init - istnieją alternatywy, takie jak Upstart i Systemd ). Te skrypty rc zwykle uruchamiają i zatrzymują usługi systemowe i są dostarczane przez dystrybucję.

Skrypt /etc/rc.localjest przeznaczony do użytku przez administratora systemu. Jest to tradycyjnie wykonywane po uruchomieniu wszystkich normalnych usług systemowych, pod koniec procesu przełączania na poziom uruchamiania dla wielu użytkowników. Możesz go użyć do uruchomienia usługi niestandardowej, na przykład zainstalowanego serwera /usr/local. Większość instalacji nie potrzebuje /etc/rc.local, jest przewidziana w mniejszości przypadków, w których jest potrzebna.

rc oznacza „kontrolę biegu”,

Poziom działania multiuserbyłby zdefiniowany jako poziom dostępności sieci, a zatem połączenia z serwerem mogłyby być nawiązywane za pomocą tych usług zamiast przewodowych połączeń konsoli.

Pamiętaj, że serwerami zarządza zazwyczaj procesor serwisowy (pod różnymi nazwami), który obsługuje połączenia sieciowe, a z kolei działa tak, jakbyś miał konsolę przewodową.

Jeśli chodzi o rc.localplik, jest to wygodna funkcja pozwalająca na określenie wszystkich „lokalnych” (specyficznych dla witryny) obiektów (demonów i / lub skryptów uruchamianych przy rozruchu), które chcesz uruchomić. Możesz użyć tego paradygmatu lub właściwie wypełnić /etc/init.d odpowiednio skryptami start / stop.

Używam go głównie do dwóch rzeczy:

1. aby zapisać datę i wersję jądra każdego ponownego uruchomienia. prosty jednowarstwowy, który można łatwo dodać do systemu bez konieczności grzebania się w nim ... i znacznie mniej podatny na uszkodzenie historii uruchamiania niż uruchomienie uptimed.

2. aby ożywić stary katalog /etc/rc.boot/, który był w Debianie jeszcze kilka lat temu. Wciąż mam tam kilka prostych skryptów, które nie są warte przepisywania jako skrypt init.d (np. Skrypt Q&D do wysyłania dmesg do roota, a inny do używania hdaparm do wyłączania bezczynnego spindown i blockdev do ustawiania read- rozmiar z wyprzedzeniem) i cieszę się, że mogą być uruchamiane po wszystkich innych skryptach uruchamiających się podczas uruchamiania.

na przykład

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

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

Ponadto napisałem /etc/rc.local skrypty dla dystrybucji centos i debian, aby uzyskać metadane w stylu ec2 z openstack (on http://169.254.169.254/), aby maszyny wirtualne otrzymywały swoje IP, nazwę hosta, klucze ssh i inne informacje specyficzne dla instancji . cloud-init został już przeniesiony do tych dystrybucji, więc skrypty są już przestarzałe.

rc.localPlik na Debianie jest głównie pod kątem zgodności z systemami typu non-startowych. Nie powinieneś go używać.

Zamiast tego zaleca się skopiowanie /etc/init.d/Skeletondo nowego skryptu inicjującego w celu zmiany tego, co ma się zdarzyć podczas zmiany poziomów uruchamiania, a następnie użycie go w inservcelu włączenia.

Aktualizacja: zgodnie z poniższym komentarzem ta odpowiedź nie jest już zalecana. Jednak ta odpowiedź została opublikowana kilka lat przed wycofaniem szkieletu, a szkielet ten nadal istnieje w Debianie niestabilny od stycznia 2019 r.