Conteúdo


Aprenda sobre o Linux, 101

Níveis de execução, destinos de inicialização, encerramento e reinicialização

Dê vida ao seu sistema

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Aprenda sobre o Linux, 101

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Aprenda sobre o Linux, 101

Fique ligado em conteúdos adicionais dessa série.

Visão geral

Neste artigo, aprenda como encerrar ou reinicializar seu sistema Linux, como avisar usuários que o sistema ficará inativo e como alternar para o modo de usuário único ou para um nível de execução ou destino de inicialização mais ou menos restritivo. Aprenda a:

  • Configurar o nível de execução ou o destino de inicialização padrão
  • Mudar entre níveis de execução ou destinos de inicialização
  • Mudar para o modo de usuário único
  • Encerrar ou reinicializar o sistema a partir da linha de comando
  • Alertar usuários sobre eventos importantes do sistema, inclusive a comutação para outro nível de execução ou destino de inicialização
  • Finalizar processos de maneira adequada

A menos que indicado de outra forma, os exemplos neste artigo usam um sistema Slackware 13.37 com kernel 2.6.37. Os exemplos de upstart usam Ubuntu 14.04 LTS com um kernel 3.16.0. Os exemplos de systemd usam Fedora 22 com um kernel 4.0.4. Seus resultados em outros sistemas poderão ser diferentes.

Executando o Linux

Na maior parte do tempo, um sistema Linux é executado como um sistema multiusuário, geralmente como um servidor com muitos processos diferentes em execução sob vários IDs do usuário diferentes. Às vezes, ele possui uma interface gráfica com o usuário e atende sobretudo um único usuário, noutras vezes ele é um servidor sem interface com o usuário que trabalha para vários usuários. Quando é preciso fazer alguns tipos de manutenção do sistema, você não deseja que todos esses usuários o façam a mesma coisa, então, é necessário estar apto a executar o sistema com um único usuário em vez de vários. Também é necessário alternar para esse modo claramente, fornecendo os avisos apropriados aos usuários registrados. E você precisa voltar para a operação normal o mais rápido possível. Este artigo mostra como fazer isso.

Este artigo o ajuda a se preparar para o Objetivo 101.3 no Tópico 101 do exame 101 do Linux Server Professional (LPIC-1). O objetivo possui um peso igual a 3.

Pré-requisitos

Para aproveitar ao máximo os artigos desta série, deve-se ter um conhecimento básico de Linux e um sistema Linux funcional no qual praticar os comandos cobertos neste artigo. Às vezes, versões diferentes de um programa formatarão a saída de maneira diferente, dessa forma, seus resultados poderão nem sempre corresponder exatamente às listagens e figuras mostradas aqui. Em particular, os sistemas upstart e systemd mais recentes estão mudando várias coisas que podem ser familiares para os usuários do processo init do System V tradicional (consulte Além do init do Drupal para obter detalhes). Este artigo começa com uma discussão sobre o processo init do System V tradicional e seus níveis de execução. Em seguida, discutimos upstart e systemd, que são os processos de inicialização mais recentes.

Níveis de execução de System V

Os Níveis de Execução de System V tradicionais definem quais tarefas podem ser realizadas no estado (ou nível de execução) atual de um sistema Linux. Os sistemas Linux tradicionais suportam três níveis básicos de execução, mais um ou mais níveis de execução para a operação normal. Os níveis básicos de execução são mostrados na Tablela 1.

Tablela 1. Níveis básicos de execução do Linux
NívelPropósito
0Encerrar (ou interromper) o sistema
1Modo de usuário único; geralmente com alias como s ou S
6Reiniciar o sistema

Além dos conceitos básicos, o uso de nível de execução difere entre as distribuições. Um uso comum configurado é mostrado na Tablela 2.

Tablela 2. Outros níveis de execução comuns do Linux
NívelPropósito
2Modo multiusuário sem rede
3Modo multiusuário com rede
5Modo multiusuário com rede e o X Window System

A distribuição Slackware usa o nível de execução 4 em vez de 5 para um sistema completo que executa o X Window System. Debian e derivativos, como Ubuntu, usam um único nível de execução para qualquer modo multiusuário, geralmente nível de execução 2. Certifique-se de consultar a documentação para sua distribuição.

Nível de execução padrão do System V

Quando um sistema Linux é iniciado, o nível de execução padrão é determinado na entrada id: em /etc/inittab. Lista 1 ilustra uma parte do arquivo /etc/inittab de um sistema Slackware configurado para execução em um modo multiusuário não gráfico.

Lista 1. Nível de execução padrão em /etc/inittab
# These are the default runlevels in Slackware:
#   0 = halt
#   1 = single user mode
#   2 = unused (but configured the same as runlevel 3)
#   3 = multiuser mode (default Slackware runlevel)
#   4 = X11 with KDM/GDM/XDM (session managers)
#   5 = unused (but configured the same as runlevel 3)
#   6 = reboot

# Default runlevel. (Do not set to 0 or 6)
id:3:initdefault:

Edite esse valor se deseja que seu sistema inicie em um nível de execução diferente, por exemplo, nível de execução 4.

Mudando os níveis de execução

Há várias maneiras de mudar os níveis de execução. Para fazer uma mudança permanente, é possível editar /etc/inittab e mudar o nível padrão que você acabou de ver acima.

Se você precisar apenas ativar o sistema em um nível de execução diferente para uma inicialização, poderá fazer isso. Por exemplo, suponha que você acabou de instalar um novo kernel e precisa construir alguns módulos do kernel após a inicialização do sistema com o novo kernel, mas antes de iniciar o X Window System. Você pode desejar ativar o sistema no nível de execução 3 para realizar isso. Isso é feito no momento da inicialização editando a linha do kernel (GRUB ou GRUB 2) ou incluindo um parâmetro após o nome do sistema selecionado (LILO). Use um único dígito para especificar o nível de execução desejado (3, nesse caso). Nós ilustraremos o processo com um exemplo de GRUB. Suponha que seu arquivo /boot/grub/menu.lst contém a sub-rotina mostrada em Lista 2 para inicializar o CentOS. Nós quebramos a linha longa do kernel para publicação usando o caractere de barra invertida (\).

Lista 2. Sub-rotina GRUB típica para inicializar o CentOS 8
title CentOS (2.6.32-504.23.4.el6.x86_64)
	root (hd0,10)
	kernel /boot/vmlinuz-2.6.32-504.23.4.el6.x86_64 ro \
        root=UUID=2f60a3b4-ef6c-4d4c-9ef4-50d7f75124a2 rd_NO_LUKS \
        rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 \
        crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet

Para ativar esse sistema no nível de execução 3, aguarde até que as entradas de inicialização sejam exibidas, selecione essa entrada e insira 'e' para editá-la. Dependendo de suas opções de GRUB, pode ser necessário pressionar uma tecla para exibir as entradas de inicialização, além de inserir 'p' e uma senha para desbloquear a edição. A tela de GRUB em nosso sistema CentOS 6 é semelhante a Figura 1.

Figura 1. Selecionando uma opção de inicialização no GRUB
Selecionando uma opção de boot no GRUB
Selecionando uma opção de boot no GRUB

Nesse exemplo, agora você deverá ver a exibição da raiz, do kernel e das linhas de initrd. Mova o cursor para a linha que começa com "kernel" e pressione 'e' para editar a linha. A tela do GRUB em nosso sistema CentOS 6 agora é semelhante a Figura 2.

Figura 2. Selecionando a entrada de kernel para edição
Selecionando a entrada do kernel para edição
Selecionando a entrada do kernel para edição

Por fim, mova o cursor até o final da linha e inclua um espaço e o dígito '3'. É possível remover 'quiet', se desejar, ou modificar quaisquer outros parâmetros conforme necessário. A tela do GRUB em nosso sistema CentOS 6 agora é semelhante a Figura 3.

Figura 3. Configurando o nível de execução inicial para 3
Configurando o runlevel inicial para 3
Configurando o runlevel inicial para 3

Por fim, pressione Enter para salvar as mudanças, em seguida, digite 'b' para inicializar o sistema.

Notas:

  1. As etapas para executar isso usando LILO ou GRUB 2 diferem daquelas para GRUB, mas o princípio básico de editar a maneira como o kernel é iniciado permanece. Até mesmo as telas de GRUB em outros sistemas ou em outras distribuições podem ser um pouco diferentes daquelas mostradas aqui. Geralmente haverá prompts disponíveis para ajudá-lo.
  2. Em sistemas que usam upstart ou systemd, os níveis de execução são simulados e algumas coisas podem não funcionar exatamente como o esperado. Isso é particularmente verdadeiro se você tenta mudar um nível de execução usando telinit

Assim que você tiver concluído seu trabalho de configuração no nível de execução 3, provavelmente desejará alternar para o nível de execução 5. Em um sistema de inicialização System V tradicional, não é necessário reinicializar o sistema. É possível usar o comando telinit para alternar para outro nível de execução. Use o comando runlevel para mostrar os níveis de execução anterior e atual. Se o primeiro caractere de saída for 'N', o nível de execução não foi mudado desde a inicialização do sistema. Lista 3 ilustra a verificação e a mudança do nível de execução.

Lista 3. Verificando e mudando o nível de execução
[root@attic4-cent ~]# runlevel
N 3
[root@attic4-cent ~]# telinit 5

Após inserir telinit 5 você verá várias mensagens piscando e sua exibição será alternada para a tela gráfica de login configurada. Abra uma janela do terminal e verifique se o nível de execução foi mudado, conforme mostrado em Lista 4.

Lista 4. Confirmando o novo nível de execução
[ian@attic4-cent ~]$ runlevel
3 5

Se você usar o comando ls para exibir uma listagem longa do comando telinit em um sistema que usa a inicialização System V, tal como Slackware 37, verá que ele realmente é um link simbólico para o comando init . Nós ilustramos isso em Lista 5. Se seu sistema usar upstart de systemd, esse provavelmente não será o caso.

root@attic4:~# # Slackware 37
root@attic4:~# ls -l $(which telinit)
lrwxrwxrwx 1 root root 4 Aug 28  2011 /sbin/telinit -> init*

O executável init sabe se ele foi chamado como init ou telinit e se comporta de acordo. Como init é executado como PID 1 no momento da inicialização, ele também é inteligente o suficiente para saber quando você o chama subsequentemente usando init em vez de telinit. Nesse caso, ele assumirá que você deseja que ele se comporte como se telinit tivesse sido chamado. Por exemplo, você pode usar init 5 em vez de telinit 5 para alternar para o nível de execução 5.

Modo de usuário único

Ao contrário dos sistemas operacionais de computador pessoal como DOS ou Windows, o Linux é inerentemente um sistema multiusuário. No entanto, há momentos em que isso pode ser um problema, como quando é necessário recuperar um sistema de arquivos ou banco de dados importante ou instalar e testar algum novo hardware. O nível de execução 1, ou modo de usuário único, é sua resposta para essas situações. A implementação efetiva varia por distribuição, mas você geralmente iniciará em um shell apenas com um sistema mínimo. Geralmente, não haverá rede e nenhum (ou muito pouco) daemon estará em execução. Em alguns sistemas, deve-se autenticar efetuando login, mas em outros você vai direto para uma linha de comando do shell como raiz. O modo de usuário único pode ser um salva-vidas, mas também pode destruir seu sistema, portanto, seja cauteloso sempre que estiver executando com autoridade de administrador. Reinicie para o modo multiusuário normal assim que tiver concluído a tarefa.

Assim como a comutação para níveis de execução multiusuário regulares, também é possível alternar para o modo de usuário único usando telinit 1. Conforme observado na Tablela 1, 's' e 'S' são aliases para o nível de execução 1, portanto, seria possível, por exemplo, usar telinit s no lugar.

Encerramento simples

Embora seja possível usar telinit ou init para parar a atividade multiusuário e alternar para o modo de usuário único, isso pode ser muito abrupto e causar a perda de trabalho dos usuários e o encerramento anormal de processos. O método preferencial para encerrar ou reinicializar o sistema é usar o comando shutdown , que primeiro envia uma mensagem de aviso para todos os usuários com login efetuado e bloqueia quaisquer logins posteriores. Em seguida, ele sinaliza ao init para alternar os níveis de execução. O processo init , então, envia um sinal SIGTERM a todos os processos em execução, dando-lhes a chance de salvar dados ou, de outra forma, encerrar adequadamente. Após 5 segundos, ou outro atraso especificado, init envia um sinal SIGKILL para encerrar forçosamente cada processo remanescente.

Por padrão, shutdown alterna para o nível de execução 1 (modo de usuário único). É possível especificar a opção -h para parar o sistema ou a opção -r para reinicializar. Uma mensagem padrão é emitida além de qualquer mensagem especificada. O tempo pode ser especificado como um tempo absoluto no formato hh:mm ou como um tempo relativo, n, em que n é o número de minutos até o encerramento. Para encerramento imediato, use now, que é equivalente a +0.

Se você tiver emitido um encerramento adiado e o tempo ainda não tiver expirado, será possível cancelar o encerramento pressionando Ctrl-c se o comando estiver em execução no primeiro plano, ou emitindo shutdown com a opção -c para cancelar um encerramento pendente. Lista 6 mostra vários exemplos do uso de shutdown, juntamente com as maneiras de cancelar o comando.

Lista 6. Exemplos de encerramento
[root@attic4-cent ~]# shutdown 5 File system recovery needed

Broadcast message from ian@attic4-cent
	(/dev/pts/1) at 18:11 ...

The system is going down for maintenance in 5 minutes!
File system recovery needed
^Cshutdown: Shutdown cancelled
[root@attic4-cent ~]# shutdown -r 10 Reloading updated kernel&
[1] 5667
[root@attic4-cent ~]#
Broadcast message from ian@attic4-cent
	(/dev/pts/1) at 18:11 ...

The system is going down for reboot in 10 minutes!
Reloading updated kernel
fg
shutdown -r 10 Reloading updated kernel
^Cshutdown: Shutdown cancelled
[root@attic4-cent ~]# shutdown -h 23:59&
[1] 5669
[root@attic4-cent ~]#
Broadcast message from ian@attic4-cent
	(/dev/pts/1) at 18:11 ...

The system is going down for halt in 348 minutes!

[root@attic4-cent ~]# shutdown -c
shutdown: Shutdown cancelled
[1]+  Done                    shutdown -h 23:59

No último exemplo, observe que nossa mensagem de transmissão foi emitida às 18h11min, mas solicitamos o encerramento às 23h59min, cerca de 6,5 horas mais tarde. A implementação do encerramento do System V tradicional não envia uma mensagem de aviso se o encerramento ocorrer em mais de 15 minutos. Em vez disso, ele espera até 15 minutos antes do encerramento planejado e, em seguida, envia a mensagem. Lista 7 mostra um exemplo de System V no Slackware 37 e também mostra o uso da opção -t para aumentar o atraso padrão entre os sinais SIGTERM e SIGKILL de 5 segundos para 60 segundos.

Lista 7. Outro exemplo de encerramento
root@attic4:~# date;shutdown -t60 17 Time to do backups&
Tue Jul 14 18:27:08 EDT 2015
[1] 2240
root@attic4:~#
Broadcast message from root (tty1) (Tue Jul 14 18:29:08 2015):

Time to do backups
The system is going DOWN to maintenance mode in 15 minutes!
 

Notificando os usuários com wall

Se você cancelar um encerramento, deverá usar o comando wall para enviar um aviso para todos os usuários alertando-os sobre o fato de o sistema não ser encerrado. O comando wall recebe um aviso na linha de comando ou envia uma mensagem de um arquivo. Uma maneira rápida de enviar uma mensagem multilinhas é usar echo -e e canalizar a saída para wall. Nós ilustramos isso em Lista 8.

Lista 8. Usando wall para avisar usuários
[root@atticf22 ~]# wall Scheduled outage at 23:59 has been canceled
                                                                               
Broadcast message from ian@atticf22 (pts/1) (Tue Jul 14 21:07:05 2015):

Scheduled outage at 23:59 has been canceled

[root@atticf22 ~]# echo -e "We are experiencing system problemsOutage rescheduled to 02:30" | wall
                                                                               
Broadcast message from ian@atticf22 (pts/1) (Tue Jul 14 21:07:36 2015):

We are experiencing system problems
Outage rescheduled to 02:30

Como dissemos anteriormente, também é possível usar telinit (ou init) para encerrar ou reinicializar o sistema. Como em outros usos do telinit, nenhum aviso é enviado aos usuários e o comando entra em vigor imediatamente, embora ainda haja um atraso entre os sinais SIGTERM e SIGKILL. Para obter opções adicionais de telinit, init e shutdown, consulte as páginas do manual apropriadas.

Se você não deseja aborrecer seus usuários com indisponibilidades repentinas do sistema, precisa notificá-los usando wall e todos os outros meios à sua disposição.

Halt, reboot e poweroff

Você deve conhecer alguns comandos adicionais relacionados ao encerramento e à reinicialização.

  • O comando haltpara o sistema.
  • O comando poweroff é um link simbólico para o comando halt , que para o sistema e, em seguida, tenta desligá-lo.
  • O comando rebooté outro link simbólico para o comando halt , que para o sistema e, em seguida, reinicializa-o.

Se qualquer um deles for chamado quando o sistema não estiver no nível de execução 0 ou 6, o comando shutdown correspondente será chamado no lugar.

Para obter opções adicionais que podem ser usadas com esses comandos, bem como informações mais detalhadas sobre suas operações, consulte a página do manual.

/etc/inittab do System V

Agora, você pode estar se perguntando por que pressionar Ctrl-Alt-Delete em alguns sistemas causa uma reinicialização ou como toda essa coisa de nível de execução é configurada. Lembra-se do campo id em /etc/inittab que vimos anteriormente? Há vários outros campos em /etc/inittab, juntamente com um conjunto de scripts init em diretórios como rc1.d ou rc5.d, em que o dígito identifica o nível de execução para o qual os scripts nesse diretório são aplicados. Lista 9 mostra o inittab completo de nosso sistema Slackware 37.

Lista 9. Inittab completo de Slackware 37
#
# inittab	This file describes how the INIT process should set up
#		the system in a certain run-level.
#
# Version:	@(#)inittab		2.04	17/05/93	MvS
#                                       2.10    02/10/95        PV
#                                       3.00    02/06/1999      PV
#                                       4.00    04/10/2002      PV
#                                      13.37    2011-03-25      PJV
#
# Author:	Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
# Modified by:	Patrick J. Volkerding, <volkerdi@slackware.com>
#

# These are the default runlevels in Slackware:
#   0 = halt
#   1 = single user mode
#   2 = unused (but configured the same as runlevel 3)
#   3 = multiuser mode (default Slackware runlevel)
#   4 = X11 with KDM/GDM/XDM (session managers)
#   5 = unused (but configured the same as runlevel 3)
#   6 = reboot

# Default runlevel. (Do not set to 0 or 6)
id:3:initdefault:

# System initialization (runs when system boots).
si:S:sysinit:/etc/rc.d/rc.S

# Script to run when going single user (runlevel 1).
su:1S:wait:/etc/rc.d/rc.K

# Script to run when going multi user.
rc:2345:wait:/etc/rc.d/rc.M

# What to do at the "Three Finger Salute".
ca::ctrlaltdel:/sbin/shutdown -t5 -r now

# Runlevel 0 halts the system.
l0:0:wait:/etc/rc.d/rc.0

# Runlevel 6 reboots the system.
l6:6:wait:/etc/rc.d/rc.6

# What to do when power fails.
pf::powerfail:/sbin/genpowerfail start

# If power is back, cancel the running shutdown.
pg::powerokwait:/sbin/genpowerfail stop

# These are the standard console login getties in multiuser mode:
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

# Local serial lines:
#s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
#s2:12345:respawn:/sbin/agetty -L ttyS1 9600 vt100

# Dialup lines:
#d1:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS0 vt100
#d2:12345:respawn:/sbin/agetty -mt60 38400,19200,9600,2400,1200 ttyS1 vt100

# Runlevel 4 also starts /etc/rc.d/rc.4 to run a display manager for X.
# Display managers are preferred in this order:  gdm, kdm, xdm
x1:4:respawn:/etc/rc.d/rc.4

# End of /etc/inittab

Como de costume, as linhas que começam com # são comentários. Outras linhas possuem vários campos com o seguinte formato:
id:runlevels:action:process

id
é um identificador exclusivo de um a quatro caracteres. As versões mais antigas limitavam isso a dois caracteres, portanto, você poderá ver apenas dois caracteres sendo usados.
runlevels
lista os níveis de execução para os quais a ação para esse id deve ser executada. Se nenhum nível de execução for listado, execute a ação para todos os níveis de execução.
action
descreve qual das várias ações possíveis deve ser executada.
process
informa qual processo, se houver, deve ser executado quando a ação nessa linha for executada.

Algumas das ações comuns que podem ser especificadas em /etc/inittab são mostradas em Tablela 3. Consulte as páginas do manual para inittab para obter outras possibilidades.

Tablela 3. Algumas ações comuns de inittab
AçãoPropósito
respawnReinicia o processo sempre que ele é finalizado. Usada geralmente para processos getty, que monitoram logins.
waitInicia o processo uma vez quando entra no nível de execução especificado e aguarda seu encerramento antes de init continuar.
onceInicia o processo uma vez quando entra no nível de execução especificado.
initdefaultEspecifica em qual nível de execução entrar após a inicialização do sistema.
ctrlaltdelExecuta o processo associado quando init recebe o sinal SIGINT, por exemplo, quando alguém no console do sistema pressiona CTRL-ALT-DEL.

Lista 10 mostra apenas a entrada para Ctrl-Alt-Delete a partir de Lista 9. Agora você vê por que pressionar Ctrl-Alt-Delete causa a reinicialização do sistema.

Lista 10. Pressionando Ctrl-Alt-Delete
# What to do at the "Three Finger Salute".
ca::ctrlaltdel:/sbin/shutdown -t5 -r now

Scripts de inicialização do System V

Você deve ter observado várias linhas em Lista 9, como:

# Script to run when going multi user.
rc:2345:wait:/etc/rc.d/rc.M

Neste exemplo, init executará o script /etc/rc.d/M (ou comando) sempre que entrar no nível de execução 2, 3, 4 ou 5. init esperará até que esse comando seja concluído antes de executar qualquer outra coisa.

Esses scripts usados por init ao iniciar o sistema, mudar os níveis de execução ou encerrar geralmente são armazenados no diretório /etc/init.d ou /etc/rc.d. Uma série de links simbólicos nos diretórios rcn.d, um diretório para cada nível de execução n, geralmente controlam se um script é iniciado ao entrar em um nível de execução ou parado ao sair dele. Esses links iniciam com um K ou um S, seguido por um número de dois dígitos e, em seguida, o nome do serviço. Alguns exemplos de um sistema mais antigo são mostrados em Lista 11.

Lista 11. Scripts init
[root@pinguino ~]# find /etc -path "*rc[0-9]*.d/???au*"
/etc/rc.d/rc2.d/S27auditd
/etc/rc.d/rc2.d/K72autofs
/etc/rc.d/rc4.d/S27auditd
/etc/rc.d/rc4.d/S28autofs
/etc/rc.d/rc5.d/S27auditd
/etc/rc.d/rc5.d/S28autofs
/etc/rc.d/rc0.d/K72autofs
/etc/rc.d/rc0.d/K73auditd
/etc/rc.d/rc6.d/K72autofs
/etc/rc.d/rc6.d/K73auditd
/etc/rc.d/rc1.d/K72autofs
/etc/rc.d/rc1.d/K73auditd
/etc/rc.d/rc3.d/S27auditd
/etc/rc.d/rc3.d/S28autofs
[root@pinguino ~]# cd /etc/rc.d/rc5.d
[root@pinguino rc5.d]# ls -l ???a*
lrwxrwxrwx 1 root root 16 2008-04-07 11:29 S27auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 16 2008-04-01 07:51 S28autofs -> ../init.d/autofs
lrwxrwxrwx 1 root root 15 2008-04-01 14:03 S44acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root 13 2008-04-01 07:50 S95atd -> ../init.d/atd
lrwxrwxrwx 1 root root 22 2008-04-01 07:54 S96avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 17 2008-11-17 13:40 S99anacron -> ../init.d/anacron

Aqui você vê que os serviços audit e autofs possuem entradas Knn em todos os níveis de execução e entradas Snn para os níveis de execução 3 e 5. O S indica que o serviço é iniciado quando esse nível de execução é inserido, enquanto a entrada K indica que ele deve ser parado. O componente nn do nome do link indica a ordem de prioridade na qual o serviço deve ser iniciado ou parado. Nesse exemplo, audit é iniciado antes de autofs e é parado posteriormente. Como os links K e S geralmente vinculam-se ao mesmo script, o script sabe se está entrando ou saindo de um nível examinando o nome do link pelo qual foi chamado.

No entanto, Slackware usa uma abordagem um pouco diferente, conforme mostrado em Lista 12. Observe que os diretórios /etc/rc[0-9].d estão todos vazios. A entrada em um nível de execução específico é controlada por um script, tal como o script para multiusuário /etc/rc.d/rc.M, que é usado ao entrar nos níveis de execução 2, 3, 4 ou 5.

Lista 12. Scripts init do Slackware 37
root@attic4:~# find /etc/rc[0-9].*
/etc/rc0.d
/etc/rc1.d
/etc/rc2.d
/etc/rc3.d
/etc/rc4.d
/etc/rc5.d
/etc/rc6.d
root@attic4:~# ls /etc/rc.*/???a*
/etc/rc.d/rc.acpid*  /etc/rc.d/rc.atalk
/etc/rc.d/rc.alsa*   /etc/rc.d/rc.autofs

Compare o script /etc/rc.d/rc.autofs com os links simbólicos /etc/rc.d/rc2.d/K72autofs e /etc/rc.d/rc4.d/S28autofs que apontam para /etc/init.d/autofs no exemplo anterior.

Consulte as páginas do manual init e inittab para obter mais informações.

Além do init

Como vimos aqui, o método tradicional de inicialização de um sistema Linux é baseado no processo init do System V do UNIX. Isso envolve o carregamento de um disco RAM inicial (initrd) e, em seguida, a transmissão do controle para um programa chamado init, um programa que geralmente é instalado como parte do pacote sysvinit. O programa init é o primeiro processo no sistema e possui PID (ID do Processo) 1. Ele executa uma série de scripts em uma ordem predefinida para ativar o sistema. Se algo esperado não está disponível, o processo init geralmente aguarda até que esteja. Embora isso funcione bem para sistemas onde tudo é conhecido e conectado quando o sistema é iniciado, sistemas modernos com dispositivos hot-plug, sistemas de arquivo de rede e até mesmo interfaces de rede que podem não estar disponíveis no momento da inicialização apresentam novos desafios. Certamente, esperar por um hardware que pode não se tornar disponível por um período longo ou relativamente longo não é desejável.

Nas seções seguintes deste artigo descreveremos duas alternativas para o init do System V, upstart e systemd.

Se você não tiver certeza de qual inicialização do sistema você possui, lembre-se de que o primeiro processo iniciado em seu sistema possui o ID do Processo (PID) 1. Descubra qual programa está em execução como PID1. Se ele se chama "init", descubra qual pacote o fornece. Lista 13 mostra como fazer isso em vários sistemas.

Lista 13. Localizando o pacote que fornece init
[ian@atticf22 lpic-1]$ # Fedora 22
[ian@atticf22 lpic-1]$ ps -p 1 -o comm=
systemd
[ian@atticf22 lpic-1]$ # Ah! It's systemd

ian@attic4:~$ # Slackware 37
ian@attic4:~$ ps -p 1 -o comm=
init
ian@attic4:~$ grep  sbin/init /var/log/packages/*
/var/log/packages/sysvinit-2.86-x86_64-6:sbin/init.new
/var/log/packages/sysvinit-2.86-x86_64-6:sbin/initscript.sample
/var/log/packages/sysvinit-functions-8.53-x86_64-2:sbin/initlog
ian@attic4:~$ # System V style init

ian@attic-u14:~$ # Ubuntu 14
ian@attic-u14:~$ ps -p 1 -o comm=
init
ian@attic-u14:~$ dpkg -S `which init`
upstart: /sbin/init
ian@attic-u14:~$ # Upstart

ian@yoga-u15:~$ # Ubuntu 15.04
ian@yoga-u15:~$ ps -p 1 -o comm=
systemd
ian@yoga-u15:~$ # Ubuntu has switched from upstart to systemd

[ian@attic4-cent ~]$ # CentOS 6
[ian@attic4-cent ~]$ ps -p 1 -o comm=
init
[ian@attic4-cent ~]$ rpm -q --whatprovides `which init`
upstart-0.6.5-13.el6_5.3.x86_64
[ian@attic4-cent ~]$ # Another upstart system

Com upstart e systemd, vestígios de Init do System V permanecem, particularmente /etc/fstab e um /etc/inittab estrutural. O conceito de nível de execução não é suportado diretamente. Os comandos do System V, como telinit, são suportados, mas suas funções são mapeadas internamente para ativação e desativação de tarefas upstart ou unidades systemd. Não é preciso dizer que, às vezes, o mapeamento pode ser menos que perfeito, portanto, se você inicializar no nível de execução 3 e, em seguida, usar telinit para alternar para o nível de execução 5, seu sistema poderá ou não funcionar exatamente como funcionaria caso você tivesse reinicializado. A "Folha de consultas do SysVinit para Systemd" (consulte Recursos) pode ajudá-lo a mapear os conceitos e comandos de init do System V para o systemd.

Upstart

Um novo processo de inicialização chamado upstart foi introduzido pela primeira vez no Ubuntu 6.10 ("Edgy Eft") em 2006. O Fedora 9 a 14 e o Red Hat Enterprise Linux (RHEL) 6 usam upstart, assim como as distribuições que derivam deles. Atualmente, o upstart suplantou o processo init no Ubuntu, entre outros, embora vestígios de init permaneçam e a capacidade total do upstart ainda não tenha sido totalmente reconhecida.

Ao contrário do conjunto estático de scripts init usados em sistemas anteriores, o sistema upstart é orientado por eventos. Os eventos podem ser acionados por mudanças de hardware, pelo início ou parada de tarefas ou por qualquer outro processo no sistema. Os eventos são usados para acionar tarefas ou serviços, conhecidos coletivamente como tarefas. Portanto, por exemplo, a conexão de uma unidade USB pode fazer com que o serviço udev envie um evento block-device-added, que faria com que uma tarefa definida verificasse /etc/fstab e montasse a unidade, se apropriado. Como outro exemplo, um servidor da web Apache pode ser iniciado apenas quando uma rede e os recursos necessários de um sistema de arquivos estão disponíveis.

O programa de inicialização upstart substitui /sbin/init. As tarefas de upstart estão definidas no diretório /etc/init e em seus subdiretórios. O sistema upstart atualmente processará /etc/inittab e scripts init do System V. Em sistemas como as liberações recentes de Fedora, /etc/inittab provavelmente contém apenas a entrada de ID para a ação initdefault. Os sistemas Ubuntu recentes não têm /etc/inittab por padrão, embora seja possível criar um se você desejar especificar um nível de execução padrão.

O upstart também possui o comando initctl para permitir a interação com o daemon init do upstart. Isso permite iniciar ou parar tarefas, listar tarefas, obter o status de tarefas, emitir eventos, reiniciar o processo init, e assim por diante. Lista 14 mostra como usar initctl para obter uma lista de tarefas upstart em um sistema Fedora 13.

Lista 14. Interagindo com o daemon init do upstart usando initctl
ian@attic-u14:~/data/lpic-1$ # Ubuntu 14
ian@attic-u14:~/data/lpic-1$ initctl list
gnome-keyring-gpg stop/waiting
indicator-application start/running, process 1935
unicast-local-avahi stop/waiting
update-notifier-crash stop/waiting
update-notifier-hp-firmware stop/waiting
xsession-init stop/waiting
dbus start/running, process 1734
update-notifier-cds stop/waiting
gnome-keyring-ssh stop/waiting
gnome-session (Unity) start/running, process 1802
ssh-agent stop/waiting
unity7 stop/waiting
unity-voice-service stop/waiting
upstart-dbus-session-bridge start/running, process 1837
indicator-messages start/running, process 1884
logrotate stop/waiting
indicator-bluetooth start/running, process 1885
unity-panel-service start/running, process 1835
hud start/running, process 1798
im-config start/running
unity-gtk-module stop/waiting
session-migration stop/waiting
upstart-dbus-system-bridge start/running, process 1789
at-spi2-registryd start/running, process 1801
indicator-power start/running, process 1889
update-notifier-release stop/waiting
indicator-datetime start/running, process 1891
unity-settings-daemon start/running, process 1794
indicator-sound start/running, process 1894
upstart-file-bridge start/running, process 1790
gnome-keyring stop/waiting
window-stack-bridge start/running, process 1754
indicator-printers start/running, process 1902
re-exec stop/waiting
upstart-event-bridge start/running, process 1745
unity-panel-service-lockscreen stop/waiting
indicator-session start/running, process 1918

Para saber mais sobre upstart, consulte Tópicos relacionados.

Systemd

Outro novo sistema de inicialização chamado systemd também está surgindo. O systemd foi desenvolvido por Lennart Poettering no início de 2010. Ele descreveu a lógica e o design em um post do blog (consulte Tópicos relacionados. Os primeiros a adotarem foram Fedora 15, openSUSE 12.1 e Mandriva 2011, entre outros. Com a liberação 15.04, o Ubuntu mudou do upstart para o systemd.

Muitos processos de daemon se comunicam usando soquetes. Para ganhar velocidade e aprimorar o paralelismo na inicialização do sistema, systemd cria esses soquetes na inicialização, mas inicia a tarefa associada apenas quando recebe uma solicitação de conexão para serviços nesse soquete. Dessa maneira, os serviços podem ser iniciados apenas quando são requeridos pela primeira vez e não necessariamente na inicialização do sistema. Os serviços que precisam de algum outro recurso ficarão bloqueados até que ele esteja disponível, portanto, apenas os serviços que estão aguardando algum outro processo precisam ser bloqueados enquanto esse processo inicia.

Estendendo o conceito de aguardar os serviços, o systemd usa autofs para definir pontos de montagem, portanto, o ponto de montagem para um sistema de arquivos fica disponível, mas a montagem efetiva pode ser atrasada até que algum processo tente abrir um arquivo no sistema de arquivos ou de outra forma usá-lo.

Esses conceitos não apenas atrasam a inicialização dos serviços até que sejam necessários, eles também reduzem a necessidade de verificação de dependência entre serviços, pois a interface para o serviço pode estar pronta muito antes de o serviço em si precisar estar disponível.

Semelhante ao upstart, systemd pode processar a inicialização existente de /etc/inittab. Ele também pode processar /etc/fstab para controlar a montagem do sistema de arquivos. A inicialização do systemd nativo gira em torno do conceito de unidades, que podem ser agrupadas em grupos de controle ou cgroups. Entre os vários tipos de unidades, você pode localizar o seguinte:

  • Unidades de serviço são daemons que podem ser iniciados, parados, reiniciados, recarregados.
  • Unidades de soquete encapsulam um soquete no sistema de arquivos ou na Internet.
  • Unidades de dispositivo encapsulam um dispositivo na árvore de dispositivos Linux.
  • Unidades de montagem encapsulam um ponto de montagem na hierarquia do sistema de arquivos.
  • Unidades de montagem automática encapsulam um ponto de montagem automática na hierarquia do sistema de arquivos.
  • Unidades de destino agrupam outras unidades, fornecendo uma única unidade de controle para diversas outras unidades.
  • Unidades de captura instantânea referenciam outras unidades e podem ser usadas para salvar e recuperar o estado de todos os serviços e unidades do sistema de inicialização (por exemplo, durante a suspensão).

As unidades são configuradas usando um arquivo de configuração, que inclui o tipo de unidade como um sufixo. Por exemplo, cups.service, rpcbind.socket ou getty.target. O local dos arquivos de configuração do sistema (por exemplo, /etc/systemd/system) pode ser determinado usando o comando pkg-config conforme mostrado em Lista 14, que mostra o local em um sistema Fedora 17. Systemd também verifica /usr/local/lib/systemd/system e /usr/lib/systemd/system para obter informações de configuração.

Lista 15. Localizando o diretório de configuração do sistema systemd
[ian@atticf22 ~]$ pkg-config systemd --variable=systemdsystemconfdir
/etc/systemd/system

O comando systemctl permite interrogar e controlar o daemon de systemd, além de iniciar e parar unidades ou listar seus status. Lista 16 ilustra o uso de systemctl para exibir o status de algumas das unidades de systemd em meu sistema Fedora 22.

Lista 16. Saída parcial de systemctl
[ian@atticf22 ~]$ systemctl --no-pager
  UNIT                          LOAD   ACTIVE SUB       DESCRIPTION
  proc-sys-fs-binfmt_misc.automount loaded active running   Arbitrary Executable File Form
  sys-devices-pci0000:00-0000:00:02.0-0000:01:00.1-sound-card1.device loaded active plugged
GF119 HDMI Audio Controller
  sys-devices-pci0000:00-0000:00:06.0-0000:03:00.0-net-enp3s0.device loaded active plugged
RTL8111/8168/8411 PCI Express
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device
loaded active plugged   WDC_WD6401AALS-00L3B2 /grubfil
...
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda9.device
loaded active plugged   WDC_WD6401AALS-00L3B2 9
  sys-devices-pci0000:00-0000:00:11.0-ata1-host0-target0:0:0-0:0:0:0-block-sda.device
loaded active plugged   WDC_WD6401AALS-00L3B2
...
  sys-devices-pci0000:00-0000:00:12.2-usb1-1\x2d6-1\x2d6:1.2-sound-card2.device loaded
active plugged   Webcam C310
  sys-devices-pci0000:00-0000:00:14.1-ata6-host5-target5:0:0-5:0:0:0-block-sr0.device loaded
active plugged   Optiarc_DVD_RW_AD-7240S
...
  sys-module-configfs.device    loaded active plugged   /sys/module/configfs
  sys-module-fuse.device        loaded active plugged   /sys/module/fuse
...
  sys-subsystem-net-devices-enp3s0.device loaded active plugged   RTL8111/8168/8411 PCI Express
  sys-subsystem-net-devices-virbr0.device loaded active plugged   /sys/subsystem/net/devices/vir
  sys-subsystem-net-devices-virbr0\x2dnic.device loaded active plugged   /sys/subsystem/net/devices/vir
  -.mount                       loaded active mounted   /
...
  cups.path                     loaded active waiting   CUPS Scheduler
  systemd-ask-password-plymouth.path loaded active waiting   Forward Password Requests to P
  systemd-ask-password-wall.path loaded active waiting   Forward Password Requests to W
  session-1.scope               loaded active abandoned Session 1 of user ian
  session-2.scope               loaded active running   Session 2 of user ian
  session-c1.scope              loaded active running   Session c1 of user gdm
...
  crond.service                 loaded active running   Command Scheduler
  cups.service                  loaded active running   CUPS Scheduler
  dbus.service                  loaded active running   D-Bus System Message Bus
  dracut-shutdown.service       loaded active exited    Restore /run/initramfs on shut
  fedora-import-state.service   loaded active exited    Import network configuration f
  fedora-readonly.service       loaded active exited    Configure read-only root suppo
...
● mcelog.service                loaded failed failed    Machine Check Exception Loggin
  NetworkManager.service        loaded active running   Network Manager
  nfs-config.service            loaded active exited    Preprocess NFS configuration
  packagekit.service            loaded active running   PackageKit Daemon
...
  cups.socket                   loaded active running   CUPS Scheduler
  dbus.socket                   loaded active running   D-Bus System Message Bus Socke
  dm-event.socket               loaded active listening Device-mapper event daemon FIF
...
  sockets.target                loaded active active    Sockets
  sound.target                  loaded active active    Sound Card
  swap.target                   loaded active active    Swap
  sysinit.target                loaded active active    System Initialization
  timers.target                 loaded active active    Timers
  dnf-makecache.timer           loaded active waiting   dnf makecache timer
  systemd-tmpfiles-clean.timer  loaded active waiting   Daily Cleanup of Temporary Dir

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

164 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

A última parte do nome da unidade (como dispositivo, caminho, destino) é o tipo de unidade.

O comando systemctl permite interrogar e controlar as unidades do sistema. Nós mostramos alguns exemplos em Lista 17 onde primeiro interrogamos o daemon do servidor SSH (sshd.service). Em seguida, nós o paramos e verificamos o status novamente. Por fim, nós o iniciamos novamente.

Lista 17. Algumas ações de systemctl
[root@atticf22 ~]# # Fedora 22
[[root@atticf22 ~]# systemctl status sshd.service
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2015-07-15 10:24:03 EDT; 5h 42min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 765 (sshd)
   CGroup: /system.slice/sshd.service
           └─765 /usr/sbin/sshd -D

Jul 15 10:24:03 atticf20 systemd[1]: Started OpenSSH server daemon.
Jul 15 10:24:03 atticf20 systemd[1]: Starting OpenSSH server daemon...
Jul 15 10:24:03 atticf20 sshd[765]: Server listening on 0.0.0.0 port 22.
Jul 15 10:24:03 atticf20 sshd[765]: Server listening on :: port 22.
[root@atticf22 ~]# systemctl stop sshd.service
[root@atticf22 ~]# systemctl status sshd.service
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Wed 2015-07-15 16:06:28 EDT; 3s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 765 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 765 (code=exited, status=0/SUCCESS)

Jul 15 10:24:03 atticf20 systemd[1]: Started OpenSSH server daemon.
Jul 15 10:24:03 atticf20 systemd[1]: Starting OpenSSH server daemon...
Jul 15 10:24:03 atticf20 sshd[765]: Server listening on 0.0.0.0 port 22.
Jul 15 10:24:03 atticf20 sshd[765]: Server listening on :: port 22.
Jul 15 16:06:28 atticf22 systemd[1]: Stopping OpenSSH server daemon...
Jul 15 16:06:28 atticf22 systemd[1]: Stopped OpenSSH server daemon.
[root@atticf22 ~]# systemctl start sshd.service

Para saber mais sobre systemd, consulte Tópicos relacionados.

Isso completa sua introdução aos níveis de execução, encerramento e reinicialização do Linux.


Recursos para download


Temas relacionados

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux
ArticleID=1063020
ArticleTitle=Aprenda sobre o Linux, 101: Níveis de execução, destinos de inicialização, encerramento e reinicialização
publish-date=09192018