Home / Dicas e Tutoriais / SysVinit Vs Systemd

SysVinit Vs Systemd

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.

upstart

O que é o Systemd?

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:

init-comand

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.

Captura de tela de 2016-06-17 08-30-22

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:

systemctl

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

About Cleuber

Cleuber Silva Hashimoto. Administrador

Leave a Reply

x

Check Also

Elementary OS 6 Odin Lançado – Confira as Novidades

Desenvolver um sistema operacional não é ...