Latest revision as of 22:40, 11 September 2015

In other languages: English (en) español (es) italiano (it) português do Brasil (pt-br) 中文（中国大陆） (zh-cn) [edit]

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:

service - serviço: a mais óbvia das unidades: daemons que podem ser iniciados, parados, reiniciados e recarregados.
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).
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.
mount: esta unidade encapsula um ponto de montagem, na hierarquia do sistema de arquivos.
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.
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).
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

http://0pointer.de/blog/projects/ - Blog do Lennart, que possui muitas informações. Ele é o desenvolvedor principal do projeto.
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks
Features Fedora 15:systemd
Site do Projeto
Entrevista com o desenvolvedor
cgroups

@@ Line 21: / Line 21: @@
 # <code>target</code> - 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).
 # <code>snapshot</code>: 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 <code>comment=</code>  no arquivo <code>/etc/fstab</code>permite 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 <code>stdin/stdout/stderr</code> para serviços como <code>syslog</code>, <code>/dev/kmsg</code>, 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 <code>.desktop</code>: É 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.
+{{admon/note|systemadm |
+Existe uma interface gráfica mínima, batizada <code>systemadm</code> 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 <code>/dev/initctl</code>. 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 <code>utmp</code> e <code>wtmp</code> (Extendendo de forma mais saudável, levando em conta o quão [http://en.wikipedia.org/wiki/Cruft crufty] o <code>wtmp</code> e <code>utmp</code> são).
+Para maiores detalhes, visite [http://0pointer.de/blog/projects/systemd.html A pequena lista de outras funcionalidades] no blog do desenvolvedor.
+== Ferramentas ==
+* <code>systemctl</code>: utilizado para inspecionar e controlar o estado do sistema systemd e gerenciador de serviços.
+* <code>systemd-cgls</code>: exibe recursivamente o conteúdo da árvore de hierarquia de um determinado grupo de controle do Linux.
+* <code>systemadm</code>: 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 ==
@@ Line 41: / Line 91: @@
 * [[Features/systemd | Features Fedora 15:systemd]]
 * [http://www.freedesktop.org/wiki/Software/systemd Site do Projeto]
-* [http://fosdem.org/2011/interview/lennart-poettering Entrevista com o desenvolvedor]
+* [http://fosdem.org/2011/interview/lennart-poettering.html Entrevista com o desenvolvedor]
 * [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]
+[[Category:Brazilian translations]]

Search

Systemd/pt-br: Difference between revisions