Scopo e uso tipico di /etc/rc.local

73

L'intestazione è simile alla seguente:

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

Qual è la ragione di questo file (non contiene molto) e quali comandi di solito ci metti? Che cos'è un "runlevel multiutente"? (Immagino rcsia "esegui comandi"?)

debian configuration startup

— Emanuel Berg
fonte

2

Non so se questo è lo scopo "ufficiale" del file, ma ho scoperto che posso usare il file per quello che dovrebbe accadere all'avvio e richiederei l'accesso da superutente, ma senza dover fornire la password. Ciò implicherebbe in genere i colori, la tastiera e altre cose del genere. Dai un'occhiata ad alcuni esempi qui .

— Emanuel Berg,

66

Un runlevel è uno stato del sistema, indicando se è in fase di avvio o il riavvio o lo spegnimento, o in modalità utente singolo, o in esecuzione normalmente. Il programma init tradizionale gestisce queste azioni passando al runlevel corrispondente. Sotto Linux, i runlevel sono per convenzione :

S durante l'avvio,
0 durante lo spegnimento,
6 durante il riavvio,
1 in modalità utente singolo e
Da 2 a 5 durante il normale funzionamento.

I runlevel da 2 a 5 sono noti come runlevel multiutente in quanto consentono l'accesso a più utenti, a differenza del runlevel 1, destinato esclusivamente all'amministratore di sistema.

Quando il runlevel cambia, init esegue gli script rc (sui sistemi con un init tradizionale - ci sono alternative, come Upstart e Systemd ). Questi script rc in genere avviano e arrestano i servizi di sistema e sono forniti dalla distribuzione.

Lo script /etc/rc.localè per l'uso da parte dell'amministratore di sistema. Viene eseguito tradizionalmente dopo l'avvio di tutti i normali servizi di sistema, al termine del processo di passaggio a un runlevel multiutente. È possibile utilizzarlo per avviare un servizio personalizzato, ad esempio un server in cui è installato /usr/local. La maggior parte delle installazioni non è necessaria /etc/rc.local, è fornita per la minoranza di casi in cui è necessaria.

— Gilles 'SO- smetti di essere malvagio'
fonte

2

Oggi ho scoperto che su FreeBSD attuale, rc.local potrebbe essere eseguito abbastanza presto. Sicuramente non dopo l'avvio di tutti i normali servizi di sistema. Volevo un segnale acustico quando sarebbe diventato disponibile l'accesso sshd a una macchina senza testa, e rc.localnon era adatto per questo motivo. Poiché la domanda originale riguarda Debian, questo commento è probabilmente irrilevante per l'OP.

— MvG

1

@MvG Grazie per le informazioni. rc.localè stato eseguito tradizionalmente per ultimo, ma vedo che FreeBSD ha smesso di farlo quando sono passati a un sistema basato sulla dipendenza. Intendiamoci, anche se rc.localfosse stato invocato dopo /etc/rc.d/sshd, che non avrebbe funzionato perfettamente: rc.localsarebbe stato invocato subito dopo l' sshdavvio del processo, potrebbe essere invocato prima di sshdaver iniziato ad ascoltare la rete (ma parleremmo decimi di secondo a la maggior parte in una configurazione tipica).

— Gilles 'SO- smetti di essere malvagio'

Sto cercando di usarlo per configurare la rete per i contenitori lxc e avviarli automaticamente. Ma si ferma dopo iptables-apply /root/iptables. Sono in procinto di capire cosa c'è che non va (in attesa del prossimo riavvio). Ma se hai qualche suggerimento, sono tutto orecchie.

— x-yuri,

1

@ x-yuri Ciò richiede molte più informazioni rispetto a quelle che hai pubblicato qui. Non so nemmeno cosa sia "esso" in "si ferma". Fai una nuova domanda che spiega cosa hai fatto.

— Gilles 'SO- smetti di essere malvagio'

14

rc denota "controllo di marcia",

Il multiuserrunlevel sarebbe definito come il livello al quale è disponibile la rete e quindi le connessioni al server potrebbero essere fatte usando quei servizi al posto delle connessioni della console cablata.

Intendiamoci, i server sono generalmente gestiti da un processore di servizi (con vari nomi) che supportano le connessioni di rete e, a loro volta, agiscono come se aveste davvero una console cablata.

Per quanto riguarda il rc.localfile, questa è una comodità che consente di specificare tutti gli oggetti "locali" (specifici del sito) (daemon e / o script di avvio all'avvio) che si desidera avviare. Puoi scegliere di usare questo paradigma o popolare effettivamente '/etc/init.d' con script start / stop, in modo appropriato.

— JRFerguson
fonte

1

Va bene, ma perché il file è lì, e quando lo usi in genere, e come (ad esempio, quali comandi ha senso inserirvi)?

— Emanuel Berg,

4

Lo uso principalmente per due cose:

per registrare la data e la versione del kernel di ogni riavvio. un semplice one-liner che può essere facilmente aggiunto ai sistemi senza alcun riempimento ... e molto meno soggetto alla cronologia di avvio corrotta che in esecuzione uptimed.
per ripristinare la vecchia directory /etc/rc.boot/ che era in debian fino a pochi anni fa. Ho ancora alcuni script semplici che non valgono lo sforzo di riscrivere come script init.d (ad esempio uno script di domande e risposte per inviare dmesg a root e un altro per usare hdaparm per disabilitare lo stato di inattività e blockdev per impostare read- dimensioni anticipate) e sono felice che vengano eseguiti dopo tutti gli altri script di avvio.

per esempio

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

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

Inoltre, ho scritto gli script /etc/rc.local all'inizio di quest'anno per centos e distro debian per ottenere i metadati in stile ec2 da openstack (on http://169.254.169.254/) in modo che le macchine virtuali possano ottenere il loro IP, nome host, chiavi ssh e altre informazioni specifiche dell'istanza . da allora cloud-init è stato portato su queste distro, quindi gli script ora sono obsoleti.

— cas
fonte

3

Il rc.localfile su Debian è principalmente per compatibilità con sistemi di tipo non init. Non dovresti usarlo.

Al contrario, si consiglia di copiare /etc/init.d/Skeletonin un nuovo script init per qualsiasi cosa si desideri che si verifichi durante la modifica dei runlevel, quindi utilizzarlo inservper abilitarlo.

Aggiornamento: come da commento di seguito, questa risposta non è più consigliata. Tuttavia, questa risposta è stata pubblicata diversi anni prima della deprecazione dello scheletro, e lo scheletro esiste ancora in Debian instabile a gennaio 2019.

— bahamat
fonte

unix.stackexchange.com/a/480897/5132 /etc/init.d/skeleton non è il modo.

— JdeBP,