O sistema de supervisão e inicialização de serviços Systemd foi anunciado como o novo, revolucionário e totalmente inovador substituto do venerável SysVinit. De fato, na descrição teórica ele parece ser muito poderoso, embora menos flexível do que uma série de scripts de shell.

Para testar o Systemd, resolvi experimentá-lo em minha máquina pessoal de produção, equipada com um sempre moderno Gentoo.

Instalação

A quem se interessar pelo Systemd, ele está facilmente disponível para Fedora e também para Gentoo.

Depois de instalar e configurar tudo, basta iniciar o sistema normalmente, mas com uma opção para o kernel:

  init=/sbin/systemd

Problema 1: peso

Entre seus poderes especiais, cobertos num artigo anterior aqui no blog, está o de garantir que determinado serviço foi parado e, com ele, todos os processos filhos (e netos, bisnetos...) que este havia gerado. O subsistema que permite esse recurso é conhecido como Cgroups (Control Groups, ou grupos de controle) e reside no kernel. Os Cgroups permitem atribuir rótulos (ou tags) a cada processo que for iniciado no sistema, além de registrar tais informações (processos e seus respectivos rótulos) num pseudo-sistema de arquivos, o que facilita imensamente sua consulta por qualquer programa ou usuário.

Contudo, o recurso de Cgroups é conhecido por requerer mais ciclos de CPU a cada criação de um novo processo, assim como em todas as rotinas de gerenciamento de processos internas ao kernel.

Nos meus testes, o sistema não ficou mais lento. O recurso de Cgroups já existe há bastante tempo no kernel 2.6, mas somente agora está tendo um maior uso, tanto em função do Systemd quanto em virtude do "patch maravilha" que reduz drasticamente a percepção de latência pelo usuário. Se você nunca usou os Cgroups, em breve chegará a hora de ativá-lo no seu kernel, pois ele tende a se tornar um item indispensável.

Problema 1 resolvido.

Problema 2: montagem de sistemas de arquivos

O Systemd é dotado de inteligência onde necessário. Ele lê o arquivo /etc/fstab durante a inicialização do sistema, e cria as políticas de montagem automática dos sistemas de arquivos descritos no arquivo. Desde meu primeiro boot com o Systemd, a partição raiz foi montada com sucesso e de forma transparente, assim como todas as demais, incluindo a /home.

Diferentemente do que eu imaginava a princípio, o Systemd não faz uso do serviço autofs. Ele utiliza o suporte do kernel ao autofs, mas implementa internamente as montagens automáticas, de forma totalmente independente do serviço autofs.

No entanto, no meu sistema, eu já usava o serviço autofs para realizar a montagem automática de uma partição btrfs, assim como a do meu /home. Portanto, é hora de converter meus automounts para os arquivos do Systemd.

Estrutura da configuração do Systemd

O Systemd armazena suas configurações de serviços em diversos arquivos. Os arquivos de automount fornecidos pelo pacote do Systemd se localizam em /lib/systemd/system/. Há arquivos com sufixos .service (serviços propriamente ditos, como Apache, Postfix etc.), .target (semelhantes — não iguais — aos runlevels), .automount e .mount, entre outros.

O Systemd não precisa do arquivo /etc/fstab para saber quais sistemas de arquivos montar em quais diretórios. Cada montagem é definida em um arquivo .mount, que deve ter como nome o diretório de montagem. Exemplos:

  var-run.mount
  sys-kernel-debug.mount

O primeiro realiza a montagem do diretório /var/run, enquanto que o segundo monta /sys/kernel/debug.

O sistema de arquivos a ser montado nesses diretórios é definido nos próprios arquivos. Vejamos um trecho do arquivo var-run.mount:

  [Mount]
  What=tmpfs
  Where=/var/run
  Type=tmpfs
  Options=mode=755,nosuid,nodev,noexec

Praticamente auto-explicativo, não? O arquivo define qual é o sistema de arquivos (What=tmpfs), o ponto de montagem (Where=/var/run), o tipo (Type=tmpfs) e as opções de montagem (Options=mode=755,nosuid,nodev,noexec).

Confuso com as linhas What= e Type=? Então vamos logo ao exemplo do /home.

  cat /etc/systemd/system/home.mount
  (...)
  [Mount]
  What=/dev/sda7
  Where=/home
  Type=ext4
  Options=noatime

Minha partição /dev/sda7 será montada em /home, com tipo ext4 e com a opção de montagem noatime. Simples, não?

Problema 2 quase resolvido.

Se tivermos somente um arquivo .mount, o Systemd montará o sistema de arquivos assim que possível — isto é, durante a inicialização do sistema — e não o desmontará mais. Para reduzirmos o tempo de boot, o ideal é permitir que os sistemas de arquivos não essenciais ao próprio boot sejam montados sob demanda quando necessário, certo? É aí que entra o arquivo com sufixo .automount

  cat /etc/systemd/system/home.automount
  (...)
  [Automount]
  Where=/home

Pronto. Com esse arquivo, o Systemd já sabe que, sempre que algum processo acessar /home, ele deve ser montado, caso já não esteja montado.

A princípio, pode parecer que os arquivos .mount e .automount poderiam ser unidos em um único, mas é importante definir se determinado sistema de arquivos deve permanecer montado ou não. E se você acha que os arquivos .automount deveriam poder existir sozinhos — isto é, sem um .mount para acompanhá-los e definir os dados da montagem — lembre-se que você pode preferir que determinado sistema de arquivos seja montado sob demanda em uma situação, mas que permaneça montado em outra. Mais sobre isso em um post futuro.

Com os dois arquivos — o .mount e o .automount criados, basta fazer com que um deles (no nosso caso, o home.automount, pois queremos a montagem sob demanda) seja carregado pelo nosso .target padrão:

  # systemctl enable home.automount

Agora sim: problema 2 resolvido.

No próximo post da série, veremos como gerenciar serviços no Systemd. Se este post já despertou seu interesse, fique à vontade para largar na frente e ler os artigos do autor do Systemd, Lennart Poettering, voltados a administradores de sistema:

• systemd for Administrators, Part I
• systemd for Administrators, Part II
• systemd for Administrators, Part III
• systemd for Administrators, Part IV

Até o próximo post!

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

Marcações:  systemd