O Que é o Init?
No Linux, o init é uma abreviatura para Inicialização. O init é um processo daemon, que começa assim que o computador é iniciado e continuar a executar até o desligamento. De fato, o init é o primeiro processo que começa quando um computador é iniciado, tornando-se o pai de todos os outros processos em execução direta ou indiretamente e, portanto, normalmente é atribuído “pid = 1”.
Se de alguma forma o daemon do init não iniciar, nenhum processo será iniciado e o sistema irá chegar a uma fase chamada “Kernel Panic”. O init é mais comumente referido como System V Init. Sistema V é o primeiro sistema operacional UNIX comercial projetado e usos do init e a maior parte das distribuições Linux de hoje são idênticas ao System V OS com algumas exceções, como Slackware usando BSD-estyle e Gentoo usando o init personalizado.
Substitutos do Init
A necessidade de substituir o init por algo melhor foi sentida a partir de um longo tempo e várias alternativas foram desenvolvidas, de tempos em tempos, algumas das quais se tornaram substitutas para a inicialização nativa de distribuição, alguns dos quais são:
Upstart – Um daemon de substituição de init implementado no Ubuntu GNU / Linux e projetado para iniciar o processo de forma assíncrona.
Epoch – Um daemon de substituição de init construído em torno de simplicidade de gestão e serviço, projetado para iniciar o processo de single-threaded.
Mudar – Um daemon de substituição de inicialização escrito em Python, implementado em Pardus GNU / Linux e projetado para iniciar o processo de forma assíncrona.
Systemd – Um daemon de substituição de init projetado para processar em paralelo, implementado em uma série de distribuição padrão – Fedora, openSUSE, a Arch, RHEL, CentOS, e recentemente o Ubuntu.
OpenRC – Um substituto do init e baseado nele criado por e para o Gentoo.
Obs. Inclusive, se você usa o Ubuntu, (acima da versão 15.10), já notou, no grub, existe, desde então, a opção de “upstart”, que é a opção caso você queira usar o upstart novamente ao invés do atual systemd.
O que é o Systemd?
O systemd é um Daemon de Sistema de Gestão de chamada com a convenção UNIX para adicionar a letra ‘d’ no final para indicar que é um daemon para ser facilmente reconhecida. Inicialmente, ele foi liberado sob a licença GNU General Public License, mas agora os lançamentos são feitos sob a GNU Lesser General Public License. Similar ao init, systemd é o pai de todos os outros processos direta ou indiretamente, e é o primeiro processo que começa na inicialização, portanto, tipicamente atribuído um
um “pid = 1”.
Ele foi projetado para superar as deficiências de inicialização. É em si é um processo em segundo plano que é projetado para iniciar processos em paralelo, reduzindo assim o tempo de inicialização e sobrecarga computacional. Tem muitos outros recursos, em comparação com o init.
Por que houve a necessidade de substituir o init?
O init inicia um processo em série, ou seja, uma tarefa só começa depois que a execução da última tarefa foi bem sucedida e ela foi carregada na memória. Isso muitas vezes resultou em tempo de inicialização mais longo.
Características do systemd
- Limpo, stateforward e design eficiente.
- Simples processo de inicialização.
- Processamento simultâneo e em paralelo durante o boot.
- Melhor API.
- Unidade simples Syntax.
- Capacidade de remover componentes opcionais.
- Uso de pouca memória.
- Técnica melhorada para expressar dependências.
- Instrução de inicialização escrito no arquivo de configuração e não em shell script.
- Faz uso de Domínio Unix Socket.
- Agendamento de trabalho usando Timers agendados do Systemd.
- Registro de Eventos com journald.
- Escolha de eventos de log do sistema com systemd, bem como syslog.
- Os registros são armazenados em arquivo binário.
- Estado systemd pode ser preservado para ser chamado mais tarde no futuro.
- Processo de faixa utilizando cgroup do kernel e não PID.
- Login de usuários gerido por systemd-logind.
- Melhor integração com o Gnome para a interoperabilidade.
Distros Que Usam Systemd
Linux Distribution | Integration |
Fedora | Sim, primeira a adotá-la |
Arch | Sim |
RedHat | Sim |
CentOS | Sim |
Debian | Sim, desde o Debian 8 Jessie |
Gentoo | Sim, removeu o OpenRC e passou a utilizar também o systemd. |
OpenSUSE | Sim |
Slack | Não (até onde eu sei) |
Ubuntu | Sim, desde o 15.10 |
Para saber qual seu sistema está usando, você pode usar este comando:
readlink /sbin/init
Estou no momento usando o Ubuntu Gnome 16.04 e a minha saída veio:
Outro comando bacana para visualizar a árvore de processos é o simples pstree.
Repare na imagem abaixo como no meu caso o systemd está é o processo pai e está gerenciando todos.
Systemd Vs Init
Características | Init | systemd |
DBus Dependência – Obrigatório | Não | sim |
Ativação baseada dispositivo | Não | sim |
configuração de dependência de dispositivos com udev | Não | sim |
Ativação baseada temporizador | Cron/at | proprietário |
Gestão de Quotas | Não | sim |
Manipulação automática de dependência de serviço | Não | sim |
Mata usuários Processo no logout | Não | sim |
Gestão de swap | Não | sim |
integração SELinux | Não | sim |
Suporte para criptografados HDD | Não | sim |
Estática kernle módulo de carga | Não | sim |
GUI | Não | sim |
Listar todos os processos filhos | Não | sim |
sysv compatível | sim | sim |
inicialização interativo | Não | sim |
Portátil para não x86 | Sim | Não |
Adotada em | várias Distros | várias Distros |
inicialização do serviço paralelo | Não | sim |
limite de recursos por serviço | Não | sim |
script de inicialização extensível fácil | sim | Não |
Código separado e Arquivo de Configuração | sim | Não |
cálculo automática de dependência | Não | sim |
depuração verboso | sim | Não |
Versão | N / D | V44 + |
Tamanho | 560 KB | N/D |
Número de Arquivos | 75 arquivos | 900 arquivos + glib + DBus |
Linhas de código – LOC | 15000 (aprox) | 224000 (aprox) (códigos inc, comentários e espaço em branco) 125000 (aprox) (código acctual) |
Comparativo Entre os Comandos Para Gerenciar Serviços no SysVinit e Comandos do Systemd
Como sabemos, os dois não apenas gerenciam todos os serviços que se iniciam durante o boot, mas também continuam em execução o tempo todo enquanto você utiliza a máquina. E através deles, você pode gerenciar os serviços em execução, ou tornar um programa em um serviço ou daemon.
Então, abaixo uma lista de comandos para gerenciar serviços com o SysVinit e no Systemd.
Vamos imaginar o serviço foo, então vamos lá:
Como era no SysVinit | Como é no systemd | observações |
---|---|---|
/etc/init.d/foo start/etc/init.d/foo stop | systemctl start foosystemctl stop foo | Inicia um serviço/Para um serviço |
tail -f /var/log/messages | journalctl -f | Centralizando a leitura dos eventos de logs principais, lembrando que ele esta capturando todos os registros de logs como as facilities e prioridades. |
/etc/init.d/foo restart | systemctl restart foo | Reinicia o serviço |
/etc/init.d/foo reload | systemctl reload foo | Reinicia o serviço, recarregando apenas o arquivo de configuração, validando sem interromper o serviço em execução. |
/etc/init.d/foo status | systemctl status foosystemctl status foo.service
(voce não precisa colocar o .service) |
Reinicia o serviço |
who -r | systemctl get-default | Verifica a runlevel que esta conectada. No systemd você possui apenas 2 *teoricamente, sendo multi-user.target para boot apenas em modo texto e graphical.target para modo grafico. É possível alterar a runlevel para o proximo boot com o comando systemctl set-default <coloque aqui qual voce quer>.target |
ls /etc/rc.d/init.d/
initctl list (no upstart) ou service –status-all |
systemctl list-unit-files | Lista todos os serviços que existem no seu sistema. E informa quem está ativo ou desabilitado.
obs. Use o “q” para sair. |
chkconfig foo on | systemctl enable foo | Habilita o serviço das runlevels 2345 para o proximo boot. (voce não precisa colocar o .service) |
chkconfig foo off | systemctl disable foo. | Desabilita o serviço das runlevels 2345 para o proximo boot. (voce não precisa colocar o .service) |
chkconfig foo
(o que pode ser visualizado pelo próprio status direto no daemon) |
systemctl is-enabled foo | Utilizado par verificar se o serviço esta ativo ou não. Qual o status do serviço. Voce nao precisa colocar o .service, como antes. |
chkconfig --list |
systemctl -t service (mais completo) | Exibe todos os serviços que estão vinculados aos níveis de execução do systemd, seja multi-user (antiga runlevel 3) ou graphic-user (antiga runlevel 5).
obs. Use o “q” para sair. |
chkconfig foo --list |
ls etc/systemd/system/*.wants/foo.service | Lista todos os serviços que existem no systemd para serem gerenciados, no seu nivel de execução é claro. |
init 3 (texto)
init 5 (gráfico)* somente se aplica a distribuições baseadas em Red Hat, pois Debian sempre é 2. |
systemctl isolate graphical.target
(para alterar para runlevel 5 ou seja, com gráfico) systemctl isolate multi-user.target (para alterar para a runlevel 3, ou seja, sem gráfico) |
O comando isolate permite alterar a runlevel em tempo real no sistema, como voce fazia antes com o comando init. O comando init ainda funciona? SIM! No Fedora e geralmente em quase todas as distribuições o comando init é um link simbólico para ../lib/systemd/systemd. |
Para saber mais como gerenciar serviços do Systemd através do Systemctl, dê uma olhada neste artigo abaixo:
Conclusão
Realmente o Systemd há alguns anos veio e veio para ficar se mostrando superior, e qualquer mudança para melhor é muito bem vinda. Claro que existem muitas controvérsias sobre o assunto, inclusive do próprio Linus Torvalds e muitos outros desenvolvedores famosos.
Mas o que você acha sobre o assunto?
Abraços,
Cleuber
fonte: tecmint