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

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"?)

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.

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.

Eu o uso principalmente para duas coisas:

1. 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.

2. 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.

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.