Introdução aos Runlevels e comandos de gerenciamento do Systemd

Quinta, 06 de Novembro de 2014 às 14:38. Carla Schroder. Exclusivo

cgroups, ou control groups, estão presentes no kernel Linux há alguns anos, mas não vem sido muito utilizado até o systemd.

Em tempos antigos nós tínhamos runlevels estáticos. systemd tem mecanismos para controle mais flexível e dinâmico do seu sistema.

Antes de entrarmos em mais aprendizado de mais comandos uteis do systemd, vamos dar uma pequena viagem na estrada na lembrança. Há essa esquisita dicotomia no Linux-land, onde o Linux e o FOSS estão sempre avançando e progredindo, e as pessoas estão sempre reclamando disso. É por isso que estou reduzindo todo esse tumulto anti-systemd a um grão de sal, por que eu me lembro quando:

• Pacotes eram ruins, por que usuários de Linux de verdade construíam tudo a partir do código fonte e mantinham controle estreito do que acontecia nos seus sistemas.
• Gerenciadores de resolução de dependências (Dependency-resolving) de pacotes eram ruins, por que usuários de Linux de verdade dependências manualmente.
• Exceto pelo apt-get, que sempre foi bom, então somente o Yum era ruim.
• Por que a Red Hat era a Microsoft do Linux.
• Yxi Ubuntu!
• Bú seu Ubuntu!

E por aí vai... como eu disse muitas vezes anteriormente, mudanças são perturbadoras. Elas mexem com o nosso fluxo de trabalho, que já não são coisas pequenas por que qualquer rompimento tem um verdadeiro custo de produtividade. Mas nós ainda estamos no estágio infantil da computação, então ela vai continuar mudando e avançando rapidamente por um bom tempo. Tenho certeza que você pessoas que estão presas na ideia de que uma vez que você compra algo, como uma chave inglesa ou uma peça de mobília ou um flamingo rosa ornamental de gramado, é para sempre. Essas são as pessoas que ainda estão rodando Windows Vista, ou Deus no ajude Windows 95 em algum PC antiquado, débil com um monitor CRT, e que não entende por que você continua bugado-os para que sejam substituídos. Ele ainda funciona, certo?

Que me lembra do meu grande triunfo em manter um computador antigo rodando bem depois que ele deveria ter sido aposentado. Era uma vez uma amiga que tinha esse 286 velhinho rodando alguma versão inadequada do MS-DOS. Ela o utilizava para algumas tarefas básicas como compromissos, diário, e um programinha velho de conta que eu escrevi para ela em BASIC para seu registro de verificação. Quem liga para atualizações de segurança, certo? Ele não está conectado a nenhuma rede. Então de tempos em tempos eu substituía o resistor e capacitor de falha ocasional, o suprimento de energia, e a bateria CMOS. E continuava levando. Seu velho e minúsculo monitor CRT ambar escurecia cada vez mais, e finalmente ele morreu depois de mais de 20 anos de serviço. Agora ela está utilizando um Thinkpad antigo rodando Linux para as mesmas tarefas.

Se há uma moral nessa tangente ela me escapou, então vamos nos ocupar com o systemd.

Runlevels vs. States

SysVInit utiliza runlevels estáticos para criar states diferentes para bootar, e a maioria das distros utilizam cinco:

• Single-user mode
• Multi-user mode sem serviços de rede iniciado
• Multi-user mode como serviços de rede iniciado
• System shutdown
• System reboot.

Particularmente, Eu não vejo muito valor pratico em ter múltiplos runlevels, mas lá estão eles. Ao invés de runlevels, o systemd lhe permite criar states, que lhe dá mecanismo mais flexível por criar configurações diferentes para bootar. Esses states são compostos de múltiplos arquivos unit empacotados dentro de targets (alvos). Os targets tem bons nomes descritivos aos invés de números. Arquivos unit controlam serviços, dispositivos, sockets, e montagens. Você pode ver como esses arquivos se parecem ao examinar os targets prefab que vem com o systemd, por exemplo /usr/lib/systemd/system/graphical.target, que é o padrão no CentOS 7:

[Unit]

Description=Graphical Interface

Documentation=man:systemd.special(7)
Requires=multi-user.target

Conflicts=rescue.target
After=multi-user.target

[Install]
Wants=display-manager.service
AllowIsolate=yes

Alias=default.target

Então, como os arquivos unit se parecem? Espreitemos um. Arquivos unit estão em dois diretórios:

• /etc/systemd/system/
• /usr/lib/systemd/system/

O primeiro é para nós atuarmos, e o segundo é aonde os pacotes os arquivos unit. O /etc/systemd/system/ leva precedência ao /usr/lib/systemd/system/. Urrah, humano sobre a maquina. Esse é o arquivo unit para o servidor Web Apache:

[Unit]

Description=The Apache HTTP Server

After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify

ExecStart=/usr/sbin/httpd/ $OPTIONS -DFOREGROUND
EnvironmentFile=/etc/sysconfig/httpd

ExecStop=/bin/kill -WINCH ${MAINPID}
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
KillSignal=SIGCONT
PrivateTmp=true

WantedBy=multi.user.target

[Install]

Esses arquivos são bem compreensiveis mesmo para recém-chegados ao systemd, e os aquivos são bastante simples do que um arquivo SysVInit init, como esse snippet a partir do /etc/init.d/apache2 exibe:

SCRIPTNAME="${0##*/}"

SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then

        if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
        else

                DIR_SUFFIX=

O arquivo inteiro tem 410 linhas.

Você pode visualizar as dependências unit, e sempre é surpreendente para mim como eles são complexos:

$ systemctl list-dependencies httpd.service

cgroups

cgroups, ou control groups (grupos de controle), tem estado presente no kernel Linux há alguns anos, mas não tem sido muito utilizado até o systemd. A documentação do kernel diz: "Control Groups fornecem um mecanismo por agregar/particionar conjuntos de tarefas, e todas as suas futuras children, nos grupos hierárquicos com comportamento especializado."Em outras palavras, ele tem o potencial para controlar, limitar, e alocar recursos em múltiplos jeitos uteis. systemd utiliza o cgroups, e você pode vê-los. Ele exibe sua arvore de cgroup inteira:

$ systemd-cgls

Você pode gerar uma visualização diferente com o bom e antigo comando ps :

$ ps xawf -eo pid,user,cgroup,args

Comandos uteis

Esse comando recarrega o arquivo de configuração de uma daemon, e não seu arquivo de de serviço systemd. Utilize isso quando você fizer uma alteração de configuração e quiser ativar-lo como a menor descrição, como esse exemplo para o Apache:

# systemctl reload httpd.service

Recarregar um arquivo de serviço para-o completamente e reinicia um serviço. Se não estiver rodando, Ele o inicia:

# systemctl restart httpd.service

Você pode reiniciar todas as daemons como um único comando. Isso reinicia todos os arquivos unit, e re-cria toda a arvore de dependência do systemd:

# systemctl daemon-reload

Você pode rebootar, suspender, e desligar como um usuário comum não privilegiado:

$ systemctl reboot

$ systemctl suspend

$ systemctl poweroff

Como sempre, há muito, muito mais a se aprender sobre o systemd. Aqui vamos nós de novo, mais um Linux Init: Introdução ao systemd e Entendendo e utilizando o Systemd são ótimas introduções ao systemd, com links para recursos mais detalhados.

Fonte:  Introdução aos Runlevels e comandos de gerenciamento do Systemd

 QUER APRENDER A UTILIZAR O BTRFS NO FEDORA, ENTÃO VENHA APRENDER LINUX COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux