Entendendo e descomplicando o Systemd

entendendo e descomplicando o systemd

O systemd é um sistema de gestão, gerenciamento e inicialização de todos os processos no sistema de forma centralizada, isso vai desde o processo de carregar scripts, todo processo de inicialização do sistema, até o seu desligamento. Ao contrário do poderoso e tradicional SysVinit que possuia varios shells scripts realizando o seu trabalho, do que a bagunça do upstart que armazenada seus registros em /etc/init/ e ao mesmo tempo trabalhando com os scripts padrão do SysvInit, não sendo todos suportados inicialmente por initctl que é o comando que permite o administrador interadir com o upstart atraves dos seus comandos start, stop, restart, reload e status. Enfim, amados por uns, odiados por outros. Eu não vou entrar em muito detalhe nesta materia porque eu ja escrevi sobre o systemd sobre a sua forma de trabalhar com o cgroups e como ele funciona desde o boot.

Mas lembre-se, a vantagem inicial do systemd é centralizar todos o processo de inicialização do sistema em forma de unidade, gerenciamento de scripts e daemons,logs, data e hora, hostname e eventos de execução (muito mais do que isso viu). Tudo em um só lugar, da mesma forma que ja é realidade a muito tempo nos sistemas da Apple pelo launchd e no formato Service Management Facility (SMF) do Solaris. Sim, se parece muito, muito mesmo!

Da mesma forma aconteceu com o Solaris que até a versão 9 (SunOS 5.9) que ainda ainda trabalhava com o formato padrao do SysvInit, se parecendo muito que temos no Linux até então, centralizando tudo em /etc/init.d, também recebeu uma grande inovação na versão 10 para o gerenciamento do sistema, o SMF.

O Solaris 10 (SunOS 5.10), veio com o SMF que melhora e centraliza o serviço de monitoramento, depuração, recuperação automática, rastreamento de dependencias e melhor suporte para delegar algumas tarefas administrativas para os usuários, alem de cuidar de todo processo de inicialização e desligamento. No formato SMF do Solaris todos os serviços podem ser visualizados pelo comando svcs que permite visualizar todos os serviços e instancias e seus eventos e gerenciados pelo comando svcadm com suas opções enable, disable, restart, refresh, clear e outros.

O Solaris 10 foi lançado em 1992 se não me engano e muitos acharam na epoca muito complicado e diferente do que ja estavam acostuado, desde as versões betas. O OSX trocou o comando service por launchctl desde as versões 10.6.8 (Snow Leopard) e forçou tambem muitos entederem o novo método e sistema. Hoje, sucesso no gerenciamento dos preferences lists. Ja no sistema da Apple, OSX (Darwin/XNU) todos os serviços são verificados e gerenciados pelo launchctl e geralmente estão em /System/Library/LaunchDaemons/, seja com load, unload, start, remove, stop, list, e por ai vai.

No Linux não é muito diferente, antes o systemd era substituido vagamente forçando os usuários a colocarem o init=/sbin/systemd no kernel que seria carregado para o software controlar todo o sistema. Agora o systemd ja foi adicionado automaticamente no boot de distribuições que fazem o uso como padrão, assim como no kernel 2.6.39 que algumas opções obrigatorias e opcionais, ja estão la.  Note que o comando init continua e o seu binário /usr/sbin/init é um link simbolico para ../lib/systemd/systemd, ou sejaa, não sendo mais necessário adicionar o systemd no grub pois as distribuições ja vem preparadas para o seu uso, como default.

As distribuições como o Fedora desde a versao 15, RHEL/CentOS desde a versao 7, SLES 12 (SuSE Enterprise), Gentoo, Archlinux e outras ja usam o systemd como padrão. Outras distribuições como o Debian estão ainda em discursão para definir o serviço padrão e consequentemente o Ubuntu, por ser baseado em Debian (enfim, vai depender do Debian Team, rs). Ja Ubuntu 14.x, Debian 7.x, SLES 11, RHEL 6 usam o formato SysvInit OU upstart.

Nota: a Red Hat passou a utilizar o upstart desde a versão 6.x e apartir da versão 7.0 implementou o systemd e passou a utilizar como padrão. Isso aconteceu com o Gentoo que removeu o OpenRC e passou a utilizar tambémo systemd.

Assim como aconteceu com o Solaris (para o SMF), MacOS (para o launchd) o systemd será uma questão de tempo para que todas as distros assumam sua metodologia, permitindo melhor centralização das tarefas, pontos de montagens, autofs, logs, scripts de inicialização e daemons, facilitando a vida do administrador.

Facilitando a vida do administrador? Como assim? Um exemplo, o meu serviço gsad.service falhou durante o boot e eu precisei saber o que aconteceu. Antes, eu precisava verificar nos logs e todos os registros locais da aplicação em /var/log/* tanto quanto o dmesg, mas agora eu tenho tudo centralizado no systemd e observei que durante o boot o serviço falhou então listei todos os serviços com o comando systemctl -t service e verifiquei que ele estava ” vermelinho ” e com um baita ” failed”. Então para entender o seu problema eu fui verificar com o comando systemctl status gsad.service e o mesmo me forneceu todos os erros que não permitiram carregar o serviço (olha, o systemd não faz milagres não heim!). Com isso, ajustei o problema e apos um systemctl start gsad.service, o serviço subiu. Hoje praticamente quase tudo que vc instala na sua distribuição ele terá um serviço sendo gerenciado pelo systemd, deixando o seu /etc/init.d bem mais vazio :)

Nota: Voce pode verificar se algum serviço controlado pelo systemd falhou com o comando systemctl –failed e verificar os registros do seu boot utilize o journalctl –boot

Então vamos entender:

Antes voces iniciavam um serviço com o comando /etc/init.d/poder start ou service poder start (redhat) ou invoke-rc.d poder start (debian) ou start poder (upstart/ubuntu), resumindo: /etc/init.d/poder start, agora voce pode fazer o mesmo com o comando systemctl start poder

Vamos imaginar o serviço foo (bem coisa de LPI né?), 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çoPara 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 voce possui apenas 2 *teoricamente, sendo multi-user.target para boot apenas em modo texto e graphical.target para modo grafico. É possivel 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 systemctlsystemctl list-unit-files –type=servicelsls /lib/systemd/system/*.service

ls /etc/systemd/system/*.service

Lista todos os serviços que existem ativos no seu sistema. Informa tambem quem esta com falhas.
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 proprio 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 list-unit-files –type=servicesystemctl list-unit-files -t service

ls /etc/systemd/system/*.wants/

systemctl -t service (mais completo)

Exibe todos os serviços que estão vinculados aos niveis de execução do systemd, seja multi-user (antiga runlevel 3) ou graphic-user (antiga runlevel 5).
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 (grafico)*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 grafico)systemctl isolate multi-user.target
(para alterar para a runlevel 3, ou seja, sem grafico)
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 simbolico para ../lib/systemd/systemd.
Powered by Moblie Video for WordPress + Daniel Watrous