From Fedora Project Wiki

O systemd é um sistema de gerenciamento de serviços para o Linux, compatível com o SysV e Scripts de init LSB. Ele prove paralelização agressiva, utilizando socket e ativações D-Bus para iniciar serviços, oferece arranque de serviços sob demanda, mantém auditoria de processos através dos cgroups do Linux, suporta snapshotting e restauração de estado de sistema, mantem pontos de montagem mount e automount e implementa um elaborado sistema transacional baseado em dependências para controle lógico dos serviços. O systemd funciona como um substitudo por completo do sysvinit. Para maiores informações, assista os vídeos http://linuxconfau.blip.tv/file/4696791/ e http://www.youtube.com/watch?v=TyMLi8QF6sw

Para administradores de sistema
Administradores de sistema podem visitar esta página, para entender como as chamadas do systemctl substituem o antigo workflow do SysVinit. Note que os comandos service e chkconfig continuarão funcionando como o esperado no mundo do systemd.

Porque o systemd?

http://0pointer.de/blog/projects/why.html - Em inglês

Introdução

O systemd inicia e supervisiona o sistema como um todo, e é baseado na notação de unidades, compostas de um tipo que correspondem a um arquivo de configuração com o mesmo nome e tipo(ex: a unidade avahi.service é um arquivo de configuração de mesmo nome, que encapsula o daemon do Avahi). Existem sete tipos diferentes de unidades. A tradução das unidades não será feita por completo, visto que elas utilizam arquivos com a extensão em inglês, em seus arquivos de configuração:

  1. service - serviço: a mais óbvia das unidades: daemons que podem ser iniciados, parados, reiniciados e recarregados.
  2. socket - socket: esta unidade encapsula um socket no sistema de arquivos ou na Internet. O systemd atualmente suporta sockets do tipo AF_INET, AF_INET6, AF_UNIX, de stream, datagrama e pacote sequencial. Também suporta os clássicos FIFOs como transporte. Cada unidade socket tem uma unidade service equivalente, que é iniciado quando a primeira conexão se iniciar ao um socket ou FIFO(ex: nscd.socket inicia o nscd.service em uma conexão de entrada).
  3. device - dispositivo: esta unidade encapsula um dispositivo na árvore de dispositivos do Linux. Se um dispositivo é marcado através de regras no udev, ele será exposto a um dispositivo de unidade no systemd. Propriedadoes configuradas com o udev podem ser utilizadas como origem de configuração par o systemd, para ajustar dependencias entre dispositivos.
  4. mount: esta unidade encapsula um ponto de montagem, na hierarquia do sistema de arquivos.
  5. automount: este tipo de unidade encapsula um ponto de montagem automático(automount) na hierarquia do sistema de arquivos. Cada unidade automount, tem uma unidade mount correspondente, que é iniciada(montada) assim que o diretório automount é acessado.
  6. target - alvo: este tipo de unidade é usado para agrupamento lógico de unidades. Ao invés de fazer algo, ela simplesmente referencia outras unidades, que podem ser controladas então de forma conjunta(ex: multi-user.target, é uma unidade que basicamente equivale a regra do run-level 5 no clássico SysV; ou o bluetooth.target que executa requisições assim que o bluetooth ficar disponível e simplesmente carrega serviços relacionados ao mesmo, que por algum motivo, não precisavam ser iniciados: bluetoothe a obexd por exemplo).
  7. snapshot: similar a unidade target, a unidade snapshot não faz nada por si so a não ser referenciar outras unidades.


Características do systemd

O systemd possui as seguintes características:

  • Paralelismo agressivo utilizando socket: Para aumentar o tempo de boot e o iniciar mais processos de forma paralela, o systemd cria os sockets de escuta antes de subir o serviço(daemon) e após este processo, apenas passa os sockets para eles. Todos os sockets referentes a todos os serviços são criados de uma vez durante o init, e então um segundo passo roda todos os daemons de uma vez. Se um serviço necessita outro que não está completamente pronto, acontecerá que a conexão é enfileirada no referente serviço e o cliente será bloqueado naquela requisição. Porém, apenas aquele cliente será bloqueado para aquela requisição. Desta forma, dependências entre serviços não necessitam ser configurados para uma inicialização paralelizada: todos os sockes são iniciados de uma vez, e um serviço quando precisar do outro, garantindo a conexão ao socket.
  • Ativação D-Bus para iniciar serviços: Utilizando uma ativação bus, um serviço pode ser iniciado a primeira vez que é acessado. A ativação bus requer uma mínima sincronização por requisição para iniciar os provedores e consumidores de serviços D-Bus ao mesmo tempo: iniciando um serviço ao mesmo tempo que outro, e caso um seja mais rápido, então através de ativação bus o D-Bus enfileira a requisição até que outro serviço consiga se enomear.
  • Oferece inicialização de daemons sob demanda
  • Rastreamento de processos utilizando http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]: Cada processo executado tem seu próprio cgroup e é muito fácil de configurar o systemd para interagir com cgroups configurados externamente, como por exemplo, através dos utilitários do libcgroups.
  • Suporta snapshotting e restauração de estados do sistema: Snapshots podem ser utilizados para salvar/restaurar o estado de todos os serviços e unidades do sistema init. Possui dois casos de uso primários: permitir ao usuário para entrar temporariamente em algum estado, como uma "Shell de emergência", terminando todos os processos correntes, e prover uma forma fácil para retornar ao estado anterior, subindo novamente dodos os serviços colocados em um estado temporário de "parada".
  • mantem pontos de montagem(mount) e montagem automática(automount): O systemd monitora todos os pontos de montagem e a forma como vão e chegam, e tambem pode ser utilizado para montar e desmontar pontos de montagem. /etc/fstab pode ser utilizado para configuração adicional para estes pontos de montagem. Utilizando a opção comment= no arquivo /etc/fstabpermite que as entradas podem ser automaticamente controladas pelo systemd, através de seu recurso de automount.
  • implementa e elabora uma logica de controle de serviços transacional, baseado em dependências: O systemd suporte diversos tipos de dependências baseadas em serviços(ou unidades) utilizando as opções After/Before, Requires e Wants no arquivo de configurações de unidade para corrigir o ordenamento de como as unidades são ativadas. Requires e Wants, exprimem um requisito positivo de dependencia, mandatório ou opcional. Existe a expressão Conflicts, que exprime um requisito de dependência negativa, e outras expressões menos utilizadas. Como controle transacional, se uma unidade requer o inicio e parada, o systemd adicionará todas as dependências a uma transação temporária, verificando se a transação é consistente(ou o ordenamento através de After/Before de todas as unidades não forma um loop). Se não possuir sucesso, o systemd não tentará corrigir, removendo todas as ações não essenciais que podem acarretar no loop.

E:

  • Para cada processo criado, ele controla: O ambiente, limites de recursos, diretório atual e root, umask, Ajuste de travas a OOM(falta de memória), nice, classe de IO e prioridade, política e prioridade de CPU, afinidade de CPU, timer, user id, group id, ids de grupos complementares, diretórios de leitura/escrita/inacessíveis, flags de montagem shared/private/slave, configurações de capabilities, secure bits, reinicio de scheduler de CPU, name-space privado de /tmp, controle de cgroup e vários subsistemas. Também pode facilmente conectar stdin/stdout/stderr para serviços como syslog, /dev/kmsg, TTYs arbitrárias. Se uma TTY for conectada o systemd gerenciará o acesso exclusivo de processos, opcionalmente esperando, ou forçando.
  • A configuração de arquivos do sistema possui uma sintaxe parecida da encontrada aos arquivos .desktop: É uma sinaxe simples, onde "parsers" existem em vários frameworks. Também permite a reutilização de ferramentas existentes para i18n para descrições de serviços, e similares, evitando que administradores de sistemas tenham que aprender novas sintaxes.
systemadm
Existe uma interface gráfica mínima, batizada systemadm que permite a parada/inicio e instrospecção de serviços. Este é parte do pacote systemd-gtk e está em pesado desenvolvimento não sendo ainda funcional, porém é uma ferramenta util para debug. É escrita em Vala. Não utilize a não ser que você seja um desenvolvedor

(... e mais avançadas)

  • Compatibilidade com os antigos scripts SysV: Tomando vantagem da LSB e cabeçalhos chkconfig quando disponíveis, se não, utiliza as informações constantes em outras localizações como por exemplo, as em /etc/rc.d. Estes init scripts são simplesmente considerados diferentes fontes de configuração, provendo um fácil caminho de atualização para o systemd.
  • arquivo de configuração /etc/fstab: apenas uma outra fonte de configuração. Utilizando a opção do fstab comment=, é possível marcar as entradas do /etc/fstab para serem controladas pelo systemd, através de pontos automáticos de montagem.
  • Suporte a simples mecanismo de template/instancias: Por exemplo, ao invés de possuir seis arquivos de configuração para seis gettys, apenas um arquivo enomeado getty@.service que será inicializado para getty@tty2.service e assim por diante. A parte de interface do systemd pode herdar dependências através de expressões como por exemplo, o serviço dhcpcd@eth0.service, que carrega o avahi-autoipd@eth0.service deixando a string eth0 como coringa de dependência.
  • Compatibilidade, em partes com o /dev/initctl. Esta compatibilidade é de fato implementada através de serviços ativados via FIFO, que apenas traduz estas requisições legadas para requisições D-Bus. Efetivamente, isto signigica que antigos comandos de shutdown, poweroff e similares do Upstart e sysvinit continuam a funcionar com o systemd.
  • Compatibilidade com utmp e wtmp (Extendendo de forma mais saudável, levando em conta o quão crufty o wtmp e utmp são).

Para maiores detalhes, visite A pequena lista de outras funcionalidades no blog do desenvolvedor.

Ferramentas

  • systemctl: utilizado para inspecionar e controlar o estado do sistema systemd e gerenciador de serviços.
  • systemd-cgls: exibe recursivamente o conteúdo da árvore de hierarquia de um determinado grupo de controle do Linux.
  • systemadm: interface grávica pra gerenciamento de serviços no systemd que permite inspecionar e controlar o systemd. éÉ parte do pacote systemd-gtk. Não utilize a não ser que você seja um desenvolvedor, pois está em uma versão não muito madura.

Visualize as páginas de manual para maiores detalhes.

Documentação do systemd

O systemd possui uma documentação extensa(em inglês) no seguinte link:

http://0pointer.de/blog/projects/systemd-docs.html

Páginas de documentação(man)

O sytemd possui uma documentação extensa, incluindo várias páginas de manual. Uma versão web pode ser encontrada em:

http://0pointer.de/public/systemd-man/

Referências

Retrieved from "https://fedoraproject.org/w/index.php?title=Systemd/pt-br&oldid=421941"