Propósito e uso típico de /etc/rc.local

Question

O cabeçalho é 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 é a razão para este arquivo (ele não contém muito) e quais comandos você normalmente coloca nele? O que é um "runlevel multiusuário"? (Eu acho que rc é "comandos de execução"?)

    

Answer 1

Um runlevel é um estado do sistema, indicando se ele está no processo de inicialização, reinicialização ou desligamento , ou no modo de usuário único, ou executando normalmente. O programa tradicional init lida com essas ações mudando 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 durante o desligamento, 6 durante a reinicialização, 1 no modo de usuário único e 2 até 5 na operação normal. Os níveis de execução de 2 a 5 são conhecidos como níveis de execução multiusuário, pois permitem que vários usuários efetuem login, diferentemente do nível de execução 1, que é destinado apenas ao administrador do sistema.

Quando o nível de execução é alterado, o init é executado rc scripts (em sistemas com um init tradicional - existem alternativas, como Upstart e Systemd . Esses scripts rc geralmente iniciam e param 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 após todos os serviços normais do sistema serem 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 em /usr/local . A maioria das instalações não precisa de /etc/rc.local , é fornecida para a minoria de casos em que é necessário.

    

Answer 2

rc denota "controle de execução",

O nível de execução multiuser seria definido como o nível no qual 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 suportam conexões de rede e, por sua vez, agem como se você realmente tivesse um console com fio.

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

    

Answer 3

O arquivo rc.local em Debian é principalmente para compatibilidade com sistemas de estilo não-init. Você não deve usá-lo.

Em vez disso, é recomendado que você copie /etc/init.d/Skeleton para um novo script de inicialização para o que quer que você queira enquanto estiver alterando os níveis de execução, e então use inserv para ativá-lo.

    

Answer 4

Eu uso principalmente para duas coisas:

1. para registrar a data e a versão do kernel de cada reinicialização. um simples one-liner que pode ser facilmente adicionado a sistemas sem nenhum recheio ... e muito menos propenso a corromper o histórico de inicialização do que executar uptimed .

2. para reviver o antigo diretório /etc/rc.boot/ que estava no debian até alguns anos atrás. Eu ainda tenho alguns scripts simples lá que não valem o esforço de reescrever como um script init.d (por exemplo, um Q & D script para enviar dmesg para root, e outro para usar hdaparm para desativar spindown ocioso e blockdev para definir tamanho de leitura antecipada), e estou feliz por eles serem executados depois de todos os outros scripts de tempo 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, eu escrevi scripts /etc/rc.local no início deste ano para as distribuições centos e debian para obter os metadados no estilo ec2 de openstack (em http://169.254.169.254/ ) para que as VMs obtivessem seu IP, hostname, chaves ssh, e outras informações específicas da instância. O cloud-init já foi portado para essas distros, então os scripts estão obsoletos agora.