Como gerenciar runlevel em sistemas Unix e distribuições Linux
Fala galera, resolvi comentar o que é runlevel de uma maneira bem abrangente em sistemas UNIX e Linux.
RUNLEVEL ou no português, os níveis de execução do sistema UNIX/Linux refere-se como e modo o sistema UNIX/Linux vai correr com o boot. É nele que o administrador de sistema determina o “perfil” do gerenciamento dos daemons (serviços), que o sistema vai automaticamente INICIAR ou INTERROMPER os determinados serviços no procedimento de boot. (antes de continuar, nao me compare pelo amor de Deus ao que a Micro$oft fez com a utilização do f8 no procedimento de boot nao, pelo amor de Deus).
Para cada versão do UNIX e distribuição Linux o esquema de runlevel é totalmente diferente do outro. Como por exemplo, no UNIX existem praticamente 8 níveis de runlevel pois existe a especial S (que varia muito dependendo da versão como no Solaris por exemplo), que no Linux da no mesmo que a runlevel 1 que é o single user (como muitos chamam de modo de segurança ou modo emergêncial). Em sistemas UNIX como o Solaris por exemplo o proprio comando shutdown com o flag ” -i “, determina qual a runlevel vai ser chamada acompanhada e em quantos segundos isso vai ocorrer. Configurado com o flag ” -g ” do shutdown do solaris (exemplo): #shutdown -i0 -g40 -y (que vai jogar o Solaris para a runlevel 0 que desliga a maquina em 40 segundos em contagem regressiva e dizendo sim para tudo com a opcao -y).
Ao contrario dos sistemas baseados padrão BSD init, como o caso do FreeBSD e OpenBSD. Ambos não possui o esquema complicado de runlevels como no Linux e Solaris. No FreeBSD e OpenBSD todo o procedimento é centralizado no /etc/rc.conf ou /etc/rc.conf.local (openbsd). Onde habilitamos os arquivos para serem gerenciados. No FreeBSD o sistema portou o mesmo esquema de utilização de daemons do netBSD com o diretorio /etc/rc.d (como nos casos de distribuições baseados no padrao BSD Init como o Slackware/ArchLinux). Coisa que não aconteceu no OpenBSD (que bom!). Por exemplo em sistemas UNIX BSD para habilitar o ssh no próximo boot edite o arquivo /etc/rc.conf e adcione o atributo sshd_enable=YES OU (no caso de netbsd e freebsd) é só iniciar /etc/rc.d/sshd start. Mas e as Runlevels no BSD? ESQUEÇA!! Caso precise de algo sendo inicializado automaticamente no próximo boot, não sendo no arquivo /etc/rc.conf vc poderia adcionar em /etc/rc.local.
O FreeBSD trabalha com o sistema no single user (usuario mono) OU multi-user (multiusuario) tendo o init como pai dos processos e encarregador disso. O FreeBSD usa o init que consulta a variável “init_path” e a configuração em /etc/defaults/rc.conf e então lê alguns recursos adcionais de referência a alguns daemons no arquivo /etc/rc.conf e cuida de todo o procedimento de inicialização e boot do sistema.
Ja em distribuições Linux baseadas em Red Hat como o Fedora, e em distribuições baseadas em Debian como o Ubuntu e outras distribuições baseadas em slackware o sistema de runlevels funciona como no arquivo abaixo. (de acordo com a tabela abaixo)
tabela de runlevel que eu roubei de outro site (preguiça é um problema serio).
Nas distribuições Linux seja ela baseada em Debian ou Red Hat ambos utilizam os recursos baseados em Runlevel, mas infelizmente runlevel no Debian é uma verdadeira bagunça sem alsa. Cara, na boa vcs ja viram o /etc/rcS.d ? Daemon para configurar o hostname e varias outras coisas. Isso nao acontece da mesma maneira no Red Hat, porem no SEL (SuSE Enterprise Linux), runlevel e daemon é sinonimo de ORGANIZAÇÃO.
Para cada RUNLEVEL existe o seu respectivo diretorio como em /etc/rcX.d (trocando o X pelo numero do nível da RN). Dentro de cada diretorio de runlevel possui LINKS SIMBÓLICOS que apontam para o diretorio de daemons como em /etc/rc.d(red hat) ou /etc/init.d (debian/ubuntu/suse), com o determinado nível de PRIORIDADE DE EXECUÇÃO. Sendo S para iniciar e K para matar o serviço toda vez que a runlevel for iniciado. Por exemplo:
/etc/rc2.d/S28daemon –> /etc/init.d/daemon
NOTA: nesse exemplo acima o tal “daemon” inicia mediante a prioridade 28, que é a ordem de execução de tudo que será inciado mediante as runlevels. Por exemplo, inicia tudo ate 27 e então inicia esse “tal” serviço chamado de daemon (como no caso do seu apache,samba,squid,syslogd e outros). Muito maneiro isso, no debian a gente possui o comando update-rc.d para gerenciar os serviços e no red hat o chkconfig.
Vale lembrar também que no SuSE Enterprise ou OpenSuSE os diretorios de runlevels se encontra no diretorio /etc/init.d ao contrario de outras distribuições no SuSE o diretorio da runlevel 2 (por exemplo), e seus scripts estao em /etc/init.d/rc2.d ao contrario das outras distros que se encontra em /etc/rc2.d (por exemplo). O SuSE enterprise tambem possui o script de inicialização alterado, pois no SuSE nao é no /etc/rc.local e sim em /etc/rc.d/boot.local que é totalmente contra os padrões do FHS do Linux.
Ja no UNIX da HP, o bom e velho HP-UX, utiliza o diretorio /etc/rc.config.d/ para configurar cada variável que será utilizada em daemons. Como o arquivo netconf onde o administrador de sistema encontra varias variaveis para gerenciar e complementar rotas e endereços de rede. No HP-UX a configuração de daemons esta em /sbin/init.d (ao contrario dos outros sistemas, vc pode achar isso meio estranho), como a configuração do cron em /sbin/init.d/cron ou do ssh em /sbin/init.d/sshd.
Para gerenciar runlevels vc pode trocar de runlevel utilizando o comando init ou telinit. Vamos imaginar que vc teve um problema no sistema, para arrumar vc deve se conectar na runlevel 1 ou S para tratar “coisas” emergênciais com o seguinte comando:
#init 1
Lembrando que na runlevel 1 ou S por ser considerado no Linux como usuario mono ou “single user”, somente a conta do root consegue se logar e os outros terminais fora o tty1 não funcionarão. Nada de interface gráfica e nada de serviços de rede, porem isso tb vai muito de distribuição para distribuição. Para saber a runlevel que vc esta conectado execute o comando:
#runlevel ( que informa a runlevel anterior que vc estava conectado e a runlevel atual)
#who -r
Existe também o arquivo de configuração da runlevel e todo o sistema de inicialização em /etc/inittab. O arquivo inittab é na verdade o arquivo de configuração do daemon init ou alguma coisa assim, onde dizemos ao sistema qual a runlevel PADRÃO para o próximo boot. Note o interior do arquivo inittab:
/etc/inittab
id:X:initdefault:
onde o valor “id:X:initdefault:” define no lugar do X o NÍVEL que será o padrão para o próximo boot, assim como 2(debian/ubuntu), 3(red hat no modo shell) e 5(red hat no modo X11).
NOTA: em distribuições como Ubuntu e derivados o arquivo /etc/inittab não existe, agora a configuração esta sob o upstart que é totalmente configurado no diretorio /etc/event.d. Existem varios arquivos de configuração oque antes era tudo somente no inittab (que eu acho muito melhor). O upstart é um evento/base para o daemon do /sbin/init (pai de todos os processos). Ele assegura o começo e parada das tarefas e serviços durante o boot, bem como uma parada programada, além de supervisionar os sistemas em execução. O upstart pretende substituir todos os daemons, como o inetd, conde e etc. O upstart é pretendido por várias distribuições Linux. Além do Ubuntu, já há registros de teste com o Gentoo. Mas vale a pena entender o esquema do Ubuntu, pelo menos a canonical tomou vergonha na cara quanto ao uso de runlevels no Debian.
No Ubuntu o upstart e o seu diretorio possui uma configuração muito próximo ao método antigo:
em /etc/event.d/tty2
respawn /sbin/getty 38400 tty2
Mas as coisas continuam e seja como forem feitas daqui pra frente a única conclusão que podemos tomar é que o gerenciamento do bom e velho UNIX continua sendo até hoje a melhor solução de sistema operacional bom e com o gerenciamento muito avançado dando liberdade ao administrador de gerenciar bem o seu procedimento de boot, otimização e MÉTODO E MODO para o seu boot.
é o poder!
