Se tudo correu certo até agora, você já deve ter um sistema todo baseado no systemd. Talvez ele utilize a "camada de compatibilidade" com o SysVinit, chamando os scripts localizados em /etc/init.d/ a partir dos arquivos de unidade do systemd, ou talvez você tenha criado os seus próprios arquivos de unidade.

Uma correção, antes que seja tarde demais: o nome do projeto é systemd, segundo sua página no freedesktop.org (item "Spelling"). Falha minha.

Contribuição de código para o systemd

Se você criou um arquivo de unidade que não é distribuído pelo systemd upstream (ou seja, que não veio em /lib/systemd/system/), você pode enviar seu novo arquivo de unidade para o bugzilla do projeto ou para a lista de discussão.

Serviços sob demanda

Conforme prometido, demonstrarei neste último artigo da série como usar o systemd para iniciar seu serviço sob demanda — isto é, somente e imediatamente quando necessário.

Ativação por socket

Você conhece o "super-servidor" xinetd? Pois bem, o systemd inclui os recursos do xinetd para iniciar serviços sob demanda. Existem duas justificativas para utilizar esse tipo de ativação sob demanda.

A primeira justificativa é para acelerar a inicialização do sistema. Sistemas como o syslog precisam ser iniciados assim que o sistema liga, é claro. O syslog é utilizado por todos os demais daemons do sistema, de forma que ele certamente será necessário na inicialização. Porém, serviços como SSH e CUPS geralmente não têm essa necessidade tão estrita. O CUPS pode ser iniciado, por exemplo, somente quando um cliente na rede enviar um documento para impressão no servidor. E o SSH pode ser iniciado somente quando um cliente desejar se conectar. Se selecionarmos o CUPS e o SSH para serem ativados sob demanda, poderemos pulá-los na inicialização do sistema e, com isso, economizar alguns preciosos segundos.

A segunda justificativa é o consumo de recursos. E esta é muito mais simples: por que iniciar serviços que não serão usados muitas vezes e que não precisam responder imediatamente quando solicitados? Se tais serviços puderem ser iniciados somente quando necessário e, ao fim de seu uso, forem novamente desligados, poderemos economizar recursos preciosos.

Ativação por sockets na prática

Da mesma forma como unidades .automount (montagens sob demanda) requerem uma unidade .mount correspondente, as unidades .socket requerem unidades .service correspondentes.

No entanto, para ativação sob demanda, o nome da unidade .service correspondente ao socket deve terminar em @:

  $ ls /lib/systemd/system/ssh*
  
  /lib/systemd/system/sshd.service
  /lib/systemd/system/sshd.socket
  /lib/systemd/system/sshd@.service

Note que temos uma unidade sshd.service e outra sshd@.service. A unidade sshd.service pode ser usada quando for desejável que o serviço SSH esteja constantemente ativado (ou seja, quando quisermos abrir mão da ativação sob demanda do serviço SSH). Já a unidade sshd@.service é utilizada para ativação via socket, em conjunto com a sshd.socket.

Vejamos os conteúdos da unidade sshd@.service:

  $ cat /lib/systemd/system/sshd@.service
  
  [Unit]
  Description=SSH Per-Connection Server
  After=syslog.target
  
  [Service]
  ExecStart=/usr/sbin/sshd -i
  StandardInput=socket

É este serviço que será iniciado em cada requisição recebida no socket informado ao systemd.

Note que o comando de execução usado nesta unidade é sshd -i. Na manpage do sshd (man 8 sshd), a opção -i indica que o sshd está sendo iniciado pelo inetd (antecessor do xinetd) — ou seja, está sendo iniciado sob demanda.

E agora, a unidade do socket:

  $ cat /lib/systemd/system/sshd.socket
  
  [Unit]
  Conflicts=sshd.service
  
  [Socket]
  ListenStream=22
  Accept=yes
  
  [Install]
  WantedBy=sockets.target

A diretiva Conflicts= serve para esta unidade parar outra unidade quando for iniciada, ou ser parada no caso contrário. Ou seja, o comando systemctl start sshd.service automaticamente faz o serviço sshd.socket parar, e vice-versa.

Toda unidade do tipo socket precisa de uma seção [Socket]. Nela, é informada a porta onde o serviço escutará (ListenStream para TCP e ListenDatagram para UDP) e a opção entre aceitar e rejeitar a comunicação (Accept=no significa que o serviço SSH será desativado).

Se você desejar escutar SSH em múltiplas portas, basta usar múltiplas linhas ListenStream=, cada uma com uma das portas.

No caso de você precisar alterar a porta padrão do SSH, lembre-se de copiar o arquivo /lib/systemd/system/sshd.socket para /etc/systemd/system/ e editar somente esta cópia do arquivo — os arquivos em /lib/systemd/ jamais devem ser editados.

Note também um ponto muito importante: a seção [Install]. É fundamental que toda unidade .socket contenha WantedBy=sockets.target. Este target é o responsável por iniciar todos os sockets na inicialização do sistema. Assim que o seu sistema iniciar, ele abrirá o(s) socket(s) especificado(s) em cada serviço do sockets.target e o próprio systemd escutará em todos eles. Assim que for recebida uma comunicação em um desses sockets (por exemplo, um pacote na porta TCP 22, em nosso exemplo), o systemd iniciará o serviço sshd@.service, cederá a ele o socket aberto e permitirá ao sshd@.service encarrergar-se do pacote recebido.

Ou seja, neste caso a primeira comunicação pode demorar um pouco mais (nada significativo, já que o sshd costuma subir bem rápido), mas o restante da sessão SSH seguirá sem qualquer atraso.

Para ativar o serviço sob demanda:

  # systemctl disable sshd.service
  # systemctl start sshd.socket
  # systemctl enable sshd.socket

Para confirmar que é o systemd quem está escutando nas portas do SSH, experimente usar o netstat:

  # netstat -ltnp
  (...)
  tcp   0   0     0.0.0.0:22    0.0.0.0:*   OUÇA     1/systemd
  (...)

Confirmado: é o systemd quem escuta na porta 22 TCP.

Ativação por D-Bus

Antes de iniciar o assunto, uma breve explicação sobre o D-Bus, já que ele não é tão conhecido pelo público em geral. O D-Bus (de desktop bus, ou barramento do desktop) foi concebido juntamente com o HAL e o Udev para compor a base do desktop livre (todos são hospedados em freedesktop.org). O D-Bus provê um mecanismo de comunicação entre processos, de forma bem semelhante ao SysV IPC e outros métodos de IPC (inter-process communication).

Para exemplificar: é o D-Bus quem permite que o seu desktop exiba anúncios sobre pen drives conectados e desconectados, mensagens instantâneas recebidas e atualizações de pacotes disponíveis. O programa de mensagens instantâneas, por exemplo, se conecta ao D-Bus e "cria um canal" (que pode se chamar org.freedesktop.IM, digamos). Quando você recebe uma mensagem instantânea, o programa de mensagens instantâneas envia uma notificação pelo canal. Como o aplicativo de notificação na bandeja do sistema também está conectado a esse mesmo canal, as informações emitidas pelo programa de mensagens instantâneas são tratadas por ele e exibidas em um balão ou em forma de um ícone que pisca, por exemplo.

De volta aos serviços. Uma unidade do systemd pode ser ativada por D-Bus. Para isto, basta que ela se registre no D-Bus e abra um "canal". Com isso, tanto o systemd quanto os demais aplicativos e serviços do sistema podem se comunicar com o serviço em questão por meio do D-Bus. A grande vantagem disso é poder iniciar o serviço sob demanda.

O exemplo do CUPS também vale neste caso. Quando um usuário local manda um programa imprimir determinado documento, o programa entra em contato com o daemon do CUPS via D-Bus para fazer o pedido e passar as informações necessárias. Isto requer, evidentemente, que o CUPS tenha aberto um canal no D-Bus para escutar tais pedidos.

Porém, novamente não precisamos iniciar o CUPS já no boot, certo? Podemos deixar para iniciá-lo somente quando alguém pedir para imprimir algo. É esta a ativação por D-Bus: o systemd abre a conexão do serviço ao D-Bus e fica escutando, mesmo sem o serviço subir. Assim que é recebido um pedido de conexão, o systemd sobe o serviço requisitado (o CUPS, no nosso exemplo) e entrega o pedido a ele. Da mesma forma como ocorre na ativação por socket, o serviço talvez demore um pouco mais para responder o primeiro pedido, mas econimiza-se tempo de boot e recursos do sistema.

Ativação por D-Bus na prática

Vejamos o exemplo do Network Manager:

  $ cat /lib/systemd/system/NetworkManager.service 
  
  [Unit]
  Description=Network Manager
  After=syslog.target
  
  [Service]
  Type=dbus
  BusName=org.freedesktop.NetworkManager
  ExecStart=/usr/sbin/NetworkManager --no-daemon
  
  [Install]
  WantedBy=network.target multi-user.target
  Alias=dbus-org.freedesktop.NetworkManager.service

Note que não é necessário ter múltiplos arquivos de unidade; basta o arquivo .service.

Na seção [Service], é preciso declarar que o tipo do serviço é dbus (Type=dbus) e, em seguida, informar o nome do barramento (BusName=...).

Infelizmente, não é possível implementar imediatamente a ativação por D-Bus para todos os serviços. É preciso que os desenvolvedores do daemon incluam nele esse recurso (comunicação via D-Bus).

Neste momento, são poucos os serviços que oferecem esse suporte (confira com um grep Type=dbus /lib/systemd/system/*). Porém, qualquer daemon pode implementar esse tipo de interface. O objetivo dos desenvolvedores do systemd é que todos os serviços possam ser ativados desta maneira — a ativação por D-Bus pode ser considerada a forma "nativa" do systemd iniciar serviços. No entanto, saiba que esse objetivo, caso seja alcançado, ainda demorará muito para chegar.

Conclusão

O systemd já é uma realidade. Não apenas ele será o sistema de init padrão no Fedora 15 (a ser lançado em maio deste ano) — ainda com uso intensivo da compatibilidade com SysVinit, claro — como já é possível hoje usá-lo completamente em substituição ao init padrão em sistemas Gentoo e Arch Linux (pelo menos). No meu laptop com Gentoo, o systemd entrou para não sair mais.

Se você desenvolve algum daemon de serviço que pode ser iniciado via SysVinit, seja gentil e pró-ativo(a) e certifique-se de cumprir todas as etapas indicadas na seção New-Style Daemons na manpage daemon(7) distribuída pelo systemd. Assim, seu serviço já estará prontíssimo para todas as distribuições.

Fim de papo. Hora de variar o assunto. :)

Links interessantes

• Wiki do Fedora sobre o systemd
• Wiki do Gentoo sobre o systemd
• Systemd para administradores, parte I
• Systemd para administradores, parte II
• Systemd para administradores, parte III
• Systemd para administradores, parte IV
• Lar do systemd em freedesktop.org

Outros posts desta série

• Bê-á-bá do Systemd, parte 1
• Bê-á-bá do Systemd, parte 2
• Bê-á-bá do Systemd, parte 3
• Bê-á-bá do Systemd, parte 4
• Bê-á-bá do Systemd, parte 5

Outros artigos deste autor

• Informações de automount via LDAP
• O fim da eth0?
• Uma loja de aplicativos para qualquer sistema GNU/Linux
• Próxima versão do kernel já tem direção
• Configuração de touchpad no xorg.conf.d
• Gentoo, uma ótima distribuição em queda:
• Bê-á-bá do MAC no Linux, parte 6: AppArmor
• Espionagem industrial: evite-a de forma colaborativa
• As novidades do Linux 2.6.37
• A fragmentação dos contêineres no Linux
• Melhorias no script de atualização do arquivo hosts
• Espírito natalino no Software Livre: você já fez sua doação?
• Tem disco na rede: ATA over Ethernet
• Bê-á-bá do MAC no Linux, parte 5: SELinux, (continuação)
• Bê-á-bá do MAC no Linux, parte 4: SELinux
• Navegação mais segura e rápida com um bom arquivo hosts
• Ative a compactação de memória com Zram
• Bê-á-bá do MAC no Linux, parte 3: Smack
• Bê-á-bá do MAC no Linux, parte 2: TOMOYO
• Bê-á-bá do MAC no Linux
• Kernel Linux, blobs binários, liberdade de software e Linux-libre
• Fcron: melhor que Cron e Anacron juntos
• Com getopts, seus scripts ficam mais profissionais
• Systemd: Boot mais rápido, preciso, econômico...
• Novidades do kernel 2.6.36
• Dica rápida: Automount mais inteligente
• Dica rápida: otimização de desktops com kernel Linux no /proc e /sys
• Fez besteira no /etc? Use o git para retornar tudo ao normal
• Renomear interface de rede com Udev
• Servidores atacados: culpa do distribuidor do kernel?
• Dica rápida: calendário anual no OpenOffice.org
• Prompt de Bash mais útil
• Bê-á-bá do SSH, parte 9: Controle de acesso
• O planeta inteligente, na visão da IBM. Temos tempo até a Copa do Mundo?
• As novidades do kernel Linux 2.6.35
• Bê-á-bá do SSH, parte 8: Proxy HTTP em túnel
• Bê-á-bá do SSH, parte 7: Túneis
• Snapshots COW para os menos favorecidos: cron, rsync e hardlinks
• Bê-á-bá do SSH, parte 6: X remoto
• Bê-a-bá do SSH, parte 5: O uso da randomart
• Bê-a-bá do SSH, parte 4: Execução de comandos remotos
• Bê-á-bá do SSH, parte 3: Trabalhando com chaves criptográficas públicas e privadas
• Be-a-bá do SSH, parte 2: Cópia de arquivos pela rede
• Bê-á-bá do SSH, parte 1: Apresentação do SSH
• As novidades do kernel Linux 2.6.34
• Protocolos da Internet: futuro e futuro do pretérito
• Tux3, o sistema de arquivos que (mais uma vez) não aconteceu
• Compiladores melhorados pela genética  

Tags:  systemd