Ao executar para um nível de execução, ele executa os níveis de execução anteriores?

Question

Se eu disser ao meu sistema para executar o nível 3, isso significa que ele é executado primeiro no nível de execução 0, 1, 2 e, finalmente, executado no nível de execução 3?

Eu achei que a resposta para essa pergunta era sim. Mas quando eu olho no meu sistema RHEL 6, vejo que muitos dos diretórios rcX.d contêm os mesmos links simbólicos.

Em Meu /etc/rc.d/rc0.d /

[root@centos6 rc.d]# ls -lah /etc/rc.d/rc0.d/
total 8.0K
drwxr-xr-x.  2 root root 4.0K Jun 27 11:59 .
drwxr-xr-x. 10 root root 4.0K Jul  9 15:06 ..
lrwxrwxrwx.  1 root root   13 Jun 12 13:02 K05atd -> ../init.d/atd
lrwxrwxrwx.  1 root root   14 Jun 12 13:01 K10cups -> ../init.d/cups
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K10saslauthd -> ../init.d/saslauthd
lrwxrwxrwx.  1 root root   18 Jun 12 12:51 K15svnserve -> ../init.d/svnserve
lrwxrwxrwx.  1 root root   14 Jun 12 10:58 K25sshd -> ../init.d/sshd
lrwxrwxrwx.  1 root root   17 Jun 12 10:57 K30postfix -> ../init.d/postfix
lrwxrwxrwx.  1 root root   17 Jun 12 12:26 K50dnsmasq -> ../init.d/dnsmasq
lrwxrwxrwx.  1 root root   20 Jun 12 10:57 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx.  1 root root   15 Jun 12 10:57 K60crond -> ../init.d/crond
lrwxrwxrwx.  1 root root   25 Jun 27 11:59 K65vboxadd-service -> ../init.d/vboxadd-service
lrwxrwxrwx.  1 root root   17 Jun 27 11:58 K70vboxadd -> ../init.d/vboxadd
lrwxrwxrwx.  1 root root   21 Jun 27 11:59 K70vboxadd-x11 -> ../init.d/vboxadd-x11
lrwxrwxrwx.  1 root root   17 Jun 12 12:26 K73winbind -> ../init.d/winbind
lrwxrwxrwx.  1 root root   19 Jun 12 12:26 K74haldaemon -> ../init.d/haldaemon
lrwxrwxrwx.  1 root root   26 Jun 12 10:58 K75blk-availability -> ../init.d/blk-availability
lrwxrwxrwx.  1 root root   15 Jun 12 11:15 K75netfs -> ../init.d/netfs
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K75udev-post -> ../init.d/udev-post
lrwxrwxrwx.  1 root root   24 Jun 12 12:26 K84NetworkManager -> ../init.d/NetworkManager
lrwxrwxrwx.  1 root root   24 Jun 27 11:59 K84wpa_supplicant -> ../init.d/wpa_supplicant
lrwxrwxrwx.  1 root root   19 Jun 12 10:58 K85mdmonitor -> ../init.d/mdmonitor
lrwxrwxrwx.  1 root root   20 Jun 12 12:25 K85messagebus -> ../init.d/messagebus
lrwxrwxrwx.  1 root root   20 Jun 12 10:58 K87multipathd -> ../init.d/multipathd
lrwxrwxrwx.  1 root root   21 Jun 12 10:57 K87restorecond -> ../init.d/restorecond
lrwxrwxrwx.  1 root root   16 Jun 12 10:58 K88auditd -> ../init.d/auditd
lrwxrwxrwx.  1 root root   15 Jun 27 11:59 K88iscsi -> ../init.d/iscsi
lrwxrwxrwx.  1 root root   17 Jun 12 10:57 K88rsyslog -> ../init.d/rsyslog
lrwxrwxrwx.  1 root root   16 Jun 12 10:58 K89iscsid -> ../init.d/iscsid
lrwxrwxrwx.  1 root root   21 Jun 12 13:01 K89portreserve -> ../init.d/portreserve
lrwxrwxrwx.  1 root root   15 Jun 12 11:15 K89rdisc -> ../init.d/rdisc
lrwxrwxrwx.  1 root root   17 Jun 12 11:15 K90network -> ../init.d/network
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K92ip6tables -> ../init.d/ip6tables
lrwxrwxrwx.  1 root root   18 Jun 12 10:57 K92iptables -> ../init.d/iptables
lrwxrwxrwx.  1 root root   22 Jun 12 10:58 K99lvm2-monitor -> ../init.d/lvm2-monitor
lrwxrwxrwx.  1 root root   17 Jun 12 11:15 S00killall -> ../init.d/killall
lrwxrwxrwx.  1 root root   14 Jun 12 11:15 S01halt -> ../init.d/halt
lrwxrwxrwx.  1 root root   15 Jun 26 12:32 S95jexec -> ../init.d/jexec

E em /etc/rc.d/rc1.d / eu vejo o mesmo conjunto de links simbólicos que em rc0.d além de links extras. Isso parece indicar que os diretórios rc0.d, rc1.d são independentes e que, para executar o nível 1, ele não executa o material no nível de execução 0. O que significa que coisas ruins podem acontecer se, de alguma forma, os links simbólicos em rc0 .d não foram exatamente replicados em rc1.d, ... etc.

Então, como isso realmente funciona? Ele apenas verifica os arquivos em um diretório específico do rc.X ou executa todos os diretórios do rc.X que possuem um nível mais baixo que o nível do rc transmitido ao init?

[root@centos6 rc.d]# ls -lah /etc/rc.d/rc1.d/
total 8.0K
drwxr-xr-x.  2 root root 4.0K Jun 27 11:59 .
drwxr-xr-x. 10 root root 4.0K Jul  9 15:06 ..
lrwxrwxrwx.  1 root root   13 Jun 12 13:02 K05atd -> ../init.d/atd
lrwxrwxrwx.  1 root root   14 Jun 12 13:01 K10cups -> ../init.d/cups
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K10saslauthd -> ../init.d/saslauthd
lrwxrwxrwx.  1 root root   18 Jun 12 12:51 K15svnserve -> ../init.d/svnserve
lrwxrwxrwx.  1 root root   14 Jun 12 10:58 K25sshd -> ../init.d/sshd
lrwxrwxrwx.  1 root root   17 Jun 12 10:57 K30postfix -> ../init.d/postfix
lrwxrwxrwx.  1 root root   17 Jun 12 12:26 K50dnsmasq -> ../init.d/dnsmasq
lrwxrwxrwx.  1 root root   20 Jun 12 10:57 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx.  1 root root   15 Jun 12 10:57 K60crond -> ../init.d/crond
lrwxrwxrwx.  1 root root   25 Jun 27 11:59 K65vboxadd-service -> ../init.d/vboxadd-service
lrwxrwxrwx.  1 root root   17 Jun 27 11:58 K70vboxadd -> ../init.d/vboxadd
lrwxrwxrwx.  1 root root   21 Jun 27 11:59 K70vboxadd-x11 -> ../init.d/vboxadd-x11
lrwxrwxrwx.  1 root root   17 Jun 12 12:26 K73winbind -> ../init.d/winbind
lrwxrwxrwx.  1 root root   19 Jun 12 12:26 K74haldaemon -> ../init.d/haldaemon
lrwxrwxrwx.  1 root root   15 Jun 12 11:15 K75netfs -> ../init.d/netfs
lrwxrwxrwx.  1 root root   24 Jun 12 12:26 K84NetworkManager -> ../init.d/NetworkManager
lrwxrwxrwx.  1 root root   24 Jun 27 11:59 K84wpa_supplicant -> ../init.d/wpa_supplicant
lrwxrwxrwx.  1 root root   19 Jun 12 10:58 K85mdmonitor -> ../init.d/mdmonitor
lrwxrwxrwx.  1 root root   20 Jun 12 12:25 K85messagebus -> ../init.d/messagebus
lrwxrwxrwx.  1 root root   20 Jun 12 10:58 K87multipathd -> ../init.d/multipathd
lrwxrwxrwx.  1 root root   21 Jun 12 10:57 K87restorecond -> ../init.d/restorecond
lrwxrwxrwx.  1 root root   16 Jun 12 10:58 K88auditd -> ../init.d/auditd
lrwxrwxrwx.  1 root root   15 Jun 27 11:59 K88iscsi -> ../init.d/iscsi
lrwxrwxrwx.  1 root root   17 Jun 12 10:57 K88rsyslog -> ../init.d/rsyslog
lrwxrwxrwx.  1 root root   16 Jun 12 10:58 K89iscsid -> ../init.d/iscsid
lrwxrwxrwx.  1 root root   21 Jun 12 13:01 K89portreserve -> ../init.d/portreserve
lrwxrwxrwx.  1 root root   15 Jun 12 11:15 K89rdisc -> ../init.d/rdisc
lrwxrwxrwx.  1 root root   17 Jun 12 11:15 K90network -> ../init.d/network
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 K92ip6tables -> ../init.d/ip6tables
lrwxrwxrwx.  1 root root   18 Jun 12 10:57 K92iptables -> ../init.d/iptables
lrwxrwxrwx.  1 root root   22 Jun 12 10:58 S02lvm2-monitor -> ../init.d/lvm2-monitor
lrwxrwxrwx.  1 root root   26 Jun 12 10:58 S25blk-availability -> ../init.d/blk-availability
lrwxrwxrwx.  1 root root   19 Jun 12 10:57 S26udev-post -> ../init.d/udev-post
lrwxrwxrwx.  1 root root   15 Jun 26 12:32 S95jexec -> ../init.d/jexec
lrwxrwxrwx.  1 root root   16 Jun 12 11:15 S99single -> ../init.d/single

    

Answer 1

Quando você alterna o nível de execução, as únicas coisas executadas são os scripts em /etc/rc.d/rc${NEW_LEVEL}.d/ .

Isso significa que você está certo: o diretório Every rc*.d precisa ser capaz de lidar com todas as alterações de processo / serviço ao alternar de outro nível de execução. Portanto, todo diretório rc contém um conjunto completo de scripts para alcançar esse nível de execução.

Digamos que você esteja alternando para o nível de execução 3. Os scripts /etc/rc.d/rc3.d/K* tentarão eliminar todos os processos em execução no que foi o nível de execução anterior (pode ser qualquer número) e /etc/rc.d/rc3.d/S* scripts iniciarão qualquer processo que precise para ser iniciado (e já não foi iniciado no runlevel anterior).

Claramente, gerenciar todos esses links simbólicos seria um problema real, por isso há utilitários para ajudar a gerenciar isso. No Debian e no Ubuntu (pelo menos, talvez outros), você pode usar update-rc.d para ativar / desativar seletivamente os scripts encontrados em /etc/init.d , ou configurá-los para "padrão" ou configurações recomendadas para cada script. Isso criará e atualizará todos os links simbólicos para você, para refletir quaisquer alterações de configuração que você queira colocar em prática. No CentOS, eu entendo que você pode usar ntsysv ou chkconfig para fazer a mesma coisa.

Efetivamente, você nunca toca nos arquivos em /etc/rc*.d/ (ou /etc/rc.d/rc*.d/ ) você mesmo; você sempre usa a ferramenta (por exemplo, update-rc.d , ntsysv , chkconfig ) para fazer alterações.

    

Answer 2

If I tell my system to go to run level 3 does that mean that it first runs through run level 0, 1, 2, and then finally runs through run level 3?

Não, isso não acontece. Runlevels não são consecutivos dessa maneira.

Caso em questão: runlevel 0 é geralmente o nível de execução "shutdown", que interrompe todos os serviços e, eventualmente, pára (e possivelmente desliga) o sistema. Não seria muito bom se, para chegar a um sistema totalmente em execução, o init fosse primeiro no nível de execução 0.

Dito isto, há geralmente uma progressão durante o processo de inicialização . O kernel inicializa no nível de execução 1, depois passa o controle para init que normalmente é configurado de tal forma que ele entra no nível de execução 2 (multiusuário sem rede) seguido pelo nível de execução 3 (modo de texto totalmente operacional) e possivelmente no nível de execução 5 modo gráfico). Mas isso é realmente completamente configurável, e as especificidades do que entra em qual runlevel é principalmente por convenção. Eu acho que pelo menos no passado, o Debian usou o runlevel 4 para o modo gráfico totalmente operacional, por exemplo, e no meu Debian Wheezy, os runlevels 2 e 3 parecem ser idênticos ( diff <(ls /etc/rc2.d) <(ls /etc/rc3.d) não produz nada). O que exatamente corresponde a cada nível de execução é do administrador.

Também por convenção, o runlevel 6 é geralmente configurado para reinicializar o sistema; você pode pular diretamente para o runlevel 6 a partir de runlevel 1, particularmente durante a manutenção do sistema, se algo impedir o sistema operacional de inicializar normalmente.

É importante notar também que sistemas não-Linux podem ter idéias diferentes sobre o que são os diferentes níveis de runlevels, ou ter um número diferente de runlevels disponíveis. O conceito é praticamente universal no mundo * nix, mas a implementação e o uso real podem diferir muito.

Em suma, "runlevels" é simplesmente uma maneira conveniente de agrupar processos relacionados e estado do sistema em bundles gerenciáveis que podem ser selecionados pelo administrador. (E como um aparte, o Windows tem um conceito muito similar com seu modo fail-safe, fail-safe com rede, fail-safe com prompt de comando, boot normal, e assim por diante.)