Vamos começar este artigo com uma revisão geral e breve do que acontece desde o momento em que você pressiona o botão Power para ligar seu servidor RHEL 7 até ser apresentado com a tela de login em uma interface de linha de comando.
Por favor, note que:
1. os mesmos princípios básicos se aplicam, com talvez pequenas modificações, a outras distribuições Linux também, e
2. a descrição a seguir não tem a intenção de representar uma explicação exaustiva do processo de inicialização, mas apenas os fundamentos.
Processo de inicialização do Linux
1. O POST (Power On Self Test) inicializa e realiza verificações de hardware.
2. Quando o POST termina, o controle do sistema é passado para o primeiro estágio do carregador de inicialização, que está armazenado no setor de inicialização de um dos discos rígidos (para sistemas mais antigos que usam BIOS e MBR), ou uma partição dedicada (U)EFI.
3. O primeiro estágio do carregador de inicialização então carrega o segundo estágio do carregador de inicialização, mais comumente GRUB (GRand Unified Boot Loader), que reside dentro de /boot, que por sua vez carrega o kernel e o sistema de arquivos inicial baseado em RAM (também conhecido como initramfs, que contém programas e arquivos binários que realizam as ações necessárias para, em última análise, montar o sistema de arquivos raiz real).
4. Somos apresentados com uma tela de inicialização que nos permite escolher um sistema operacional e um kernel para inicializar:
5. O kernel configura o hardware conectado ao sistema e, uma vez que o sistema de arquivos raiz tenha sido montado, inicia o processo com PID 1, que por sua vez inicializará outros processos e nos apresentará um prompt de login.
Observação: Se desejarmos fazer isso em um momento posterior, podemos examinar os detalhes desse processo usando o comando dmesg e filtrando sua saída usando as ferramentas que explicamos em artigos anteriores desta série.
No exemplo acima, usamos o conhecido comando ps para exibir uma lista de processos atuais cujo processo pai (ou em outras palavras, o processo que os iniciou) é o systemd (o gerenciador de sistema e serviço para o qual a maioria das distribuições Linux modernas mudou) durante a inicialização do sistema:
# ps -o ppid,pid,uname,comm --ppid=1
Lembre-se de que a opção -o (abreviação de –format) permite que você apresente a saída do ps em um formato personalizado para atender às suas necessidades usando as palavras-chave especificadas na seção ESPECIFICADORES DE FORMATO PADRÃO em man ps.
Outro caso em que você desejará definir a saída do ps em vez de usar o padrão é quando precisa encontrar processos que estão causando uma carga significativa na CPU e/ou memória e classificá-los adequadamente:
# ps aux --sort=+pcpu # Sort by %CPU (ascending) # ps aux --sort=-pcpu # Sort by %CPU (descending) # ps aux --sort=+pmem # Sort by %MEM (ascending) # ps aux --sort=-pmem # Sort by %MEM (descending) # ps aux --sort=+pcpu,-pmem # Combine sort by %CPU (ascending) and %MEM (descending)
Uma Introdução ao SystemD
Poucas decisões no mundo Linux causaram mais controvérsias do que a adoção do systemd pelas principais distribuições Linux. Os defensores do systemd citam como suas principais vantagens os seguintes fatos:
Leia também: A História por Trás de ‘init’ e ‘systemd’
1. O systemd permite que mais processamento seja feito em paralelo durante a inicialização do sistema (ao contrário do antigo SysVinit, que sempre tende a ser mais lento porque inicia processos um por um, verifica se um depende do outro e depois espera que os daemons sejam lançados para que mais serviços possam iniciar), e
2. Funciona como gerenciamento dinâmico de recursos em um sistema em execução. Assim, os serviços são iniciados quando necessário (para evitar o consumo de recursos do sistema se eles não estiverem sendo usados) em vez de serem lançados sem motivo válido durante a inicialização.
3. Compatibilidade com scripts SysVinit antigos.
O systemd é controlado pela utilidade systemctl. Se você vem de um ambiente SysVinit, é provável que esteja familiarizado com:
- a ferramenta service, que – nessas sistemas mais antigos – era usada para gerenciar scripts SysVinit, e
- a utilidade chkconfig, que servia para atualizar e consultar informações de runlevel para serviços do sistema.
- Desligar, que você deve ter usado várias vezes para reiniciar ou desligar um sistema em execução.
A tabela a seguir mostra as semelhanças entre o uso dessas ferramentas legadas e systemctl:
| Legacy tool | Systemctl equivalent | Description |
| service name start | systemctl start name | Start name (where name is a service) |
| service name stop | systemctl stop name | Stop name |
| service name condrestart | systemctl try-restart name | Restarts name (if it’s already running) |
| service name restart | systemctl restart name | Restarts name |
| service name reload | systemctl reload name | Reloads the configuration for name |
| service name status | systemctl status name | Displays the current status of name |
| service –status-all | systemctl | Displays the status of all current services |
| chkconfig name on | systemctl enable name | Enable name to run on startup as specified in the unit file (the file to which the symlink points). The process of enabling or disabling a service to start automatically on boot consists in adding or removing symbolic links inside the /etc/systemd/system directory. |
| chkconfig name off | systemctl disable name | Disables name to run on startup as specified in the unit file (the file to which the symlink points) |
| chkconfig –list name | systemctl is-enabled name | Verify whether name (a specific service) is currently enabled |
| chkconfig –list | systemctl –type=service | Displays all services and tells whether they are enabled or disabled |
| shutdown -h now | systemctl poweroff | Power-off the machine (halt) |
| shutdown -r now | systemctl reboot | Reboot the system |
Systemd também introduziu os conceitos de unidades (que podem ser um serviço, um ponto de montagem, um dispositivo ou um soquete de rede) e alvos (que é como o systemd gerencia o início de vários processos relacionados ao mesmo tempo e pode ser considerado – embora não igual – como o equivalente aos níveis de execução em sistemas baseados em SysVinit.
Resumindo
Outras tarefas relacionadas com o gerenciamento de processos incluem, mas não estão limitadas a, a capacidade de:
1. Ajustar a prioridade de execução no que diz respeito ao uso de recursos do sistema de um processo:
Isto é realizado através do utilitário renice, que altera a prioridade de agendamento de um ou mais processos em execução. Em termos simples, a prioridade de agendamento é um recurso que permite ao kernel (presente nas versões => 2.6) alocar recursos do sistema conforme a prioridade de execução atribuída (também conhecida como “nice”, em uma faixa de -20 a 19) de um determinado processo.
A sintaxe básica do renice é a seguinte:
# renice [-n] priority [-gpu] identifier
Na instrução genérica acima, o primeiro argumento é o valor de prioridade a ser usado, enquanto o outro argumento pode ser interpretado como IDs de processo (que é a configuração padrão), IDs de grupo de processo, IDs de usuário ou nomes de usuário. Um usuário normal (exceto o root) só pode modificar a prioridade de agendamento de um processo que ele ou ela possui e apenas aumentar o nível de gentileza (o que significa usar menos recursos do sistema).
2. Matar (ou interromper a execução normal) de um processo conforme necessário:
Em termos mais precisos, matar um processo significa enviar a ele um sinal para terminar sua execução graciosamente (SIGTERM=15) ou imediatamente (SIGKILL=9>) através dos comandos kill ou pkill.
A diferença entre essas duas ferramentas é que a primeira é usada para encerrar um processo específico ou um grupo de processos inteiro, enquanto a segunda permite fazer o mesmo com base no nome e em outros atributos.
Além disso, o pkill vem junto com o pgrep, que mostra os PIDs que serão afetados caso o pkill seja usado. Por exemplo, antes de executar:
# pkill -u gacanepa
Pode ser útil ver de relance quais são os PIDs pertencentes a gacanepa:
# pgrep -l -u gacanepa
Por padrão, tanto o kill quanto o pkill enviam o sinal SIGTERM para o processo. Como mencionamos anteriormente, este sinal pode ser ignorado (enquanto o processo termina sua execução ou permanentemente), então quando você realmente precisa parar um processo em execução com um motivo válido, você precisará especificar o sinal SIGKILL na linha de comando:
# kill -9 identifier # Kill a process or a process group # kill -s SIGNAL identifier # Idem # pkill -s SIGNAL identifier # Kill a process by name or other attributes
Conclusão
Neste artigo, explicamos o básico do processo de inicialização em um sistema RHEL 7 e analisamos algumas das ferramentas disponíveis para ajudá-lo a gerenciar processos usando utilitários comuns e comandos específicos do systemd.
Observe que esta lista não pretende cobrir todos os detalhes deste tópico, então sinta-se à vontade para adicionar suas próprias ferramentas e comandos preferidos a este artigo usando o formulário de comentários abaixo. Perguntas e outros comentários também são bem-vindos.
Source:
https://www.tecmint.com/rhcsa-exam-boot-process-and-process-management/