Finalidade e uso típico do /etc/rc.local

73

O cabeçalho fica assim:

#!/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 o motivo desse arquivo (ele não contém muito) e quais comandos você costuma colocar nele? O que é um "nível de execução multiusuário"? (Eu acho que rcé "executar comandos"?)

debian configuration startup

— Emanuel Berg
fonte

2

Não sei se esse é o objetivo "oficial" do arquivo, mas descobri que posso usá-lo para o que deve acontecer na inicialização e exigiria acesso de superusuário, mas sem precisar fornecer a senha. Isso normalmente envolveria cores, teclado e outras coisas desse tipo. Confira alguns exemplos aqui .

— Emanuel Berg

66

Um nível de execução é um estado do sistema, indicando se está em processo de inicialização, reinicialização ou encerramento, ou no modo de usuário único, ou em execução normal. O programa init tradicional lida com essas ações alternando para o nível de execução correspondente. No Linux, os níveis de execução são por convenção :

S durante a inicialização,
0 ao desligar,
6 durante a reinicialização,
1 no modo de usuário único e
2 a 5 em operação normal.

Os níveis de execução 2 a 5 são conhecidos como níveis de execução multiusuário, pois permitem que vários usuários efetuem login, ao contrário do nível de execução 1, destinado apenas ao administrador do sistema.

Quando o nível de execução muda, o init executa scripts rc (em sistemas com um init tradicional - existem alternativas, como Upstart e Systemd ). Esses scripts rc normalmente iniciam e interrompem os serviços do sistema e são fornecidos pela distribuição.

O script /etc/rc.localé para ser usado pelo administrador do sistema. É tradicionalmente executado depois que todos os serviços normais do sistema são iniciados, no final do processo de mudança para um nível de execução multiusuário. Você pode usá-lo para iniciar um serviço personalizado, por exemplo, um servidor instalado /usr/local. A maioria das instalações não precisa /etc/rc.local, é fornecida para a minoria de casos em que é necessária.

— Gilles 'SO- parar de ser mau'
fonte

2

Eu descobri hoje que no FreeBSD atual, o rc.local pode ser executado muito cedo. Definitivamente, não após todos os serviços normais do sistema serem iniciados. Eu queria um bipe quando o acesso sshd a uma máquina sem cabeça estivesse disponível e rc.localnão era adequado por esse motivo. Como a pergunta original é sobre o Debian, esse comentário provavelmente é irrelevante para o OP.

— MvG 05/03

11

@MvG Obrigado pela informação. rc.localera tradicionalmente executado por último, mas vejo que o FreeBSD parou de fazer isso quando eles mudaram para um sistema baseado em dependência. Lembre-se, mesmo que rc.localfosse invocado depois /etc/rc.d/sshd, isso não funcionaria perfeitamente: rc.localseria invocado logo após o início do sshdprocesso, poderia ser invocado antes de sshdcomeçar a ouvir a rede (mas estaríamos falando décimos de segundo em mais em uma configuração típica).

— Gilles 'SO- stop be evil'

Estou tentando usá-lo para configurar a rede para contêineres lxc e iniciá-los automaticamente. Mas para depois iptables-apply /root/iptables. Estou no processo de descobrir o que há de errado (aguardando a próxima reinicialização). Mas se você tiver alguma sugestão, sou todo ouvidos.

— X-yuri

11

@ x-yuri Isso requer muito mais informações do que as que você postou aqui. Eu nem sei o que é "isso" em "ele pára". Faça uma nova pergunta que explique o que você fez.

— Gilles 'SO- stop be evil'

14

rc denota "controle de execução",

O multiusernível de execução seria definido como o nível em que a rede está disponível e, portanto, as conexões com o servidor poderiam ser feitas usando esses serviços, em vez de conexões de console com fio.

Lembre-se, os servidores geralmente são gerenciados por um processador de serviço (sob vários nomes) que suporta conexões de rede e, por sua vez, age como se você realmente tivesse um console com fio.

Quanto ao rc.localarquivo, é uma conveniência permitir que você especifique todos os objetos "locais" (específicos do site) (daemons e / ou scripts de inicialização) que deseja iniciar. Você pode optar por usar esse paradigma ou realmente preencher '/etc/init.d' com scripts de início / parada, adequadamente.

— JRFerguson
fonte

11

Tudo bem, mas por que o arquivo está lá, e quando você normalmente o usa, e como (por exemplo, quais comandos fazem sentido colocá-lo)?

— Emanuel Berg

4

Eu o uso principalmente para duas coisas:

para registrar a data e a versão do kernel de cada reinicialização. um one-liner simples que pode ser facilmente adicionado aos sistemas sem se preocupar com isso ... e muito menos propenso a que o histórico de inicialização seja corrompido do que em execução uptimed.
reviver o antigo diretório /etc/rc.boot/ que estava no debian até alguns anos atrás. Eu ainda tenho alguns scripts simples que não valem o esforço de reescrever como um script init.d (por exemplo, um script de Q&D para enviar dmesg para o root e outro para usar o hdaparm para desativar a rotação ociosa e o blockdev para definir o read- tamanho antecipado) e fico feliz que eles sejam executados após todos os outros scripts de inicialização.

por exemplo

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

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

Além disso, escrevi scripts /etc/rc.local no início deste ano para distribuições centos e debian para obter os metadados no estilo ec2 do openstack (on http://169.254.169.254/), para que as VMs obtenham seus IP, nome do host, chaves ssh e outras informações específicas da instância . Desde então, o cloud-init foi portado para essas distribuições; portanto, os scripts estão obsoletos agora.

— cas
fonte

3

O rc.localarquivo no Debian é principalmente para compatibilidade com sistemas no estilo não-init. Você não deve usá-lo.

Em vez disso, é recomendável que você copie /etc/init.d/Skeletonpara um novo script init para o que você deseja que aconteça ao alterar os níveis de execução e use-o inservpara habilitá-lo.

Atualização: conforme o comentário abaixo, esta resposta não é mais recomendada. No entanto, esta resposta foi publicada vários anos antes da depreciação do esqueleto, e esse esqueleto ainda existe no Debian instável a partir de janeiro de 2019.

— bahamat
fonte

unix.stackexchange.com/a/480897/5132 /etc/init.d/skeleton não é o caminho.

— JdeBP