Saltar para o conteúdo

systemd

Origem: Wikipédia, a enciclopédia livre.
A versão imprimível já não suportada e pode apresentar defeitos de composição gráfica. Atualize os favoritos do seu navegador e use a função de impressão padrão do navegador.
systemd
Logótipo
Systemd
Captura de tela
Systemd
Arranque do systemd no Debian GNU/Linux
Autor Lennart Poettering, Kay Sievers Harald Hoyer, Daniel Mack, Tom Gundersen e David Herrmann
Desenvolvedor Lennart Poettering, Kay Sievers, Harald Hoyer, Daniel Mack, Tom Gundersen, David Herrmann, e outros
Modelo do desenvolvimento Software livre
Lançamento 30 de março de 2010 (14 anos)
Versão estável 255[1] (6 de dezembro de 2023; há 10 meses)
Idioma(s) Inglês
Escrito em C[2]
Sistema operativo Linux
Gênero(s) daemon init, software de sistema
Licença LGPL 2.1+
Estado do desenvolvimento Ativo
Tamanho ~9.0 MB
Página oficial freedesktop.org/wiki/Software/systemd
systemd.io
Repositório github.com/systemd/systemd
Componentes do systemd A arquitetura de systemd como é usado por Tizen. Vários componentes, incluindo serviços de telefonia, bootmode, dlog e tizen são de Tizen e não são componentes do systemd.[3]

systemd é um conjunto de softwares que fornecem blocos de construção fundamentais para um sistema operacional Linux. Entre outros recursos, ele inclui o systemd "System and Service Manager" (em português, "Gerenciador do Sistema e Serviços" do systemd), um sistema init usado para inicializar o espaço do usuário e gerenciar processos do sistema após a inicialização (boot). É um substituto para os sistemas init do UNIX System V e do Berkeley Software Distribution (BSD).

Um dos principais objetivos do projeto systemd é a unificação de configurações básicas e comportamentos de serviços do Linux entre todas as distribuições Linux.[4]

A partir de 2015, a maioria das distribuições do Linux adotaram o systemd como seu sistema init padrão,[5] apesar dessa crescente adoção de systemd tem sido controversa, com os críticos argumentando que o software violou a filosofia Unix tornando-se cada vez mais complexa, e que as distribuições foram forçados a adotá-lo devido à dependência de vários outros softwares sobre ele, incluindo, o ambiente de trabalho do GNOME 3.

O nome systemd adere à convenção Unix de nomeação de daemons anexando a letra d.[6] Ele também reproduz o termo "Sistema D", que se refere à capacidade de uma pessoa de se adaptar rapidamente e improvisar para resolver problemas.

É mantido por Lennart Poettering e Kay Sievers, com muitos outros contribuintes,[7] e publicado como software livre e de código aberto nos termos da Licença Pública Geral Menor GNU (LGPL) versão 2.1 ou posterior.[8]

História

Lennart Poettering e Kay Sievers iniciaram o projeto para desenvolver o systemd em 2010.[9]

Em maio de 2011, o Fedora se tornou a primeira grande distribuição Linux a habilitar o systemd por padrão.[10]

Entre outubro de 2013 e fevereiro de 2014, um longo debate entre o Comitê Técnico do Debian ocorreu na lista de discussão do Debian,[11] discutindo qual sistema init usar como padrão no Debian 8 "jessie", e culminou em uma decisão a favor do systemd. O debate foi amplamente divulgado[12][13] e, na sequência da decisão, o debate continua na lista de discussão do Debian. Em fevereiro de 2014, após a decisão do Debian ter sido tomada, Mark Shuttleworth anunciou em seu blog que o Ubuntu seguiria na implementação do systemd.[14][15]

Em novembro de 2014, o Desenvolvedor Debian Joey Hess,[16] os membros do Comitê Técnico do Debian Russ Allbery[17] e Ian Jackson,[18] e o mantenedor do pacote systemd Tollef Fog Heen[19] renunciaram às suas posições. Todos os quatro justificaram sua decisão na lista de discussão pública do Debian e em blogs pessoais com suas exposições a níveis de estresse extraordinários relacionados a disputas contínuas na integração do systemd dentro da comunidade Debian e open-source que tornaram a manutenção regular virtualmente impossível.

Em agosto de 2015, o systemd começou a fornecer um shell de login, que pode ser chamado via machinectl shell.[20]

Em setembro de 2016, foi descoberto uma falha de segurança que permitia a qualquer usuário não privilegiado executar um ataque de negação de serviço contra o systemd.[21] Rich Felker, desenvolvedor do musl, afirmou que essa falha revela uma grande "falha no projeto de desenvolvimento do sistema".[22] Em 2017, outra falha de segurança foi descoberta no systemd, a CVE-2017-9445, que "permite a interrupção do serviço" por um "servidor DNS malicioso".[23][24]

Projeto

Lennart Poettering e Kay Sievers, os engenheiros de software que trabalham para a Red Hat, que inicialmente desenvolveu o systemd, procuraram superar a eficiência do daemon init de várias maneiras. Eles queriam melhorar a estrutura de software para expressar dependências, para permitir que mais processamento fosse feito simultaneamente ou em paralelo durante a inicialização do sistema e para reduzir a sobrecarga computacional do shell.

Poettering descreve o desenvolvimento do sistema como "nunca terminado, nunca completo, mas acompanhando o progresso da tecnologia". Em maio de 2014, Poettering definiu ainda mais o sistema como tendo como objetivo unificar "diferenças sem sentido entre distribuições", fornecendo as três funções gerais a seguir:

  • Um gerente de sistema e serviço (gerencia tanto o sistema, como aplicando várias configurações, e seus serviços)
  • Uma plataforma de software (serve como base para o desenvolvimento de outro software)
  • A cola entre aplicações e o kernel (fornece várias interfaces que expõem as funcionalidades fornecidas pelo kernel)

systemd não é apenas o nome do daemon init, mas também se refere a todo o pacote de software em torno dele, que, além do daemon systemit init, inclui os daemons journald, logind e networkd, e muitos outros componentes de baixo nível. Em janeiro de 2013, Poettering descreveu systemd não como um programa, mas sim um grande pacote de software que inclui 69 binários individuais. Como um conjunto de software integrado, o systemd substitui os scripts de inicialização e os níveis de execução controlados pelo daemon tradicional do init, juntamente com os scripts de shell executados sob seu controle. O systemd também integra muitos outros serviços que são comuns em sistemas Linux ao lidar com logins de usuários, console de sistema, hotplugging de dispositivos (ver udev), execução agendada (substituindo cron), logging, hosts e locales.

Como o daemon init, o systemd é um daemon que gerencia outros daemons, que, incluindo o systemd, são processos em segundo plano. systemd é o primeiro daemon a iniciar durante a inicialização e o último daemon a terminar durante o desligamento. O daemon systemd serve como raiz da árvore de processos do espaço do usuário; O primeiro processo (PID 1) tem um papel especial nos sistemas Unix, pois recebe um sinal SIGCHLD quando um processo do daemon (que se separou do seu pai) termina. Portanto, o primeiro processo é particularmente adequado para a finalidade de monitorar os daemons; systemd tenta melhorar nessa área específica sobre a abordagem tradicional, que normalmente não reiniciaria os daemons automaticamente, mas só os lançaria uma vez sem monitoramento adicional.

systemd executa elementos de sua sequência de inicialização em paralelo, o que é mais rápido do que a seqüência de inicialização tradicional abordagem seqüencial. [13] Para a comunicação entre processos (IPC), o systemd disponibiliza soquetes de domínio Unix e D-Bus para os daemons em execução. O estado do systemd também pode ser preservado em uma snapshot para futura recuperação.

Ele inicializa uma plataforma, mas também serve para consolidar o registro de eventos e pode substituir o syslog. Devido a ele substituir dois sistemas administrativos, para administradores de sistema isto significa que o número de mecanismos internos do kernel que ele trata oferece uma curva de aprendizagem excessiva.

Ficheiros de unidade

O systemd registra as instruções de inicialização para cada daemon em um arquivo de configuração (conhecido como um "arquivo de unidade") que usa uma linguagem declarativa, substituindo os scripts de shell de inicialização por daemon tradicionalmente usados. Os tipos de arquivo de unidade incluem:

  • service
  • socket
  • device
  • mount
  • automount
  • swap
  • target
  • path
  • timer (que pode ser usado como um agendador de trabalho, semelhante ao cron)
  • snapshot
  • slice (usado para agrupar e gerenciar processos e recursos)[25]
  • scope

Componentes centrais e bibliotecas

Seguindo sua abordagem integrada, o systemd também fornece substitutos para vários daemons e utilitários, incluindo os scripts de shell de inicialização, pm-utils, inetd, acpid, syslog, watchdog, cron e atd. Os principais componentes do systemd incluem o seguinte:

systemd é um gerenciador de sistemas e serviços para sistemas operacionais Linux.

systemctl pode ser usado para intro-inspecionar e controlar o estado do sistema systemd e gerenciar serviços.

systemd-analyze pode ser usado para determinar as estatísticas de desempenho de inicialização do sistema e recuperar outras informações de estado e rastreamento do sistema e do gerenciador de serviços.

systemd rastreia processos usando o subsistema cgroups do kernel do Linux em vez de usar identificadores de processo (PIDs); Assim, os daemons não podem "escapar" do systemd, nem mesmo por bifurcação dupla. systemd não só usa cgroups, mas também systemd-nspawn e machinectl, dois programas utilitários que facilitam a criação e gerenciamento de containers Linux. Desde a versão 205, o systemd também oferece ControlGroupInterface, que é uma API para os cgroups do kernel do Linux. Os cgroups do kernel do Linux são adaptados para suportar kernfs, e estão sendo modificados para suportar uma hierarquia unificada.

Componentes auxiliares

Uma captura de tela do systemd-boot
Uma captura de tela do timedatectl

Além de seu principal objetivo de fornecer um sistema de init Linux alternativo, o conjunto de sistemas fornece funcionalidades adicionais, incluindo os seguintes componentes:

consoled

systemd-consoled foi um daemon do console do usuário, com a intenção de substituir o suporte do terminal virtual do kernel do Linux por um componente de espaço de usuários mais capacitado. Sua versão preliminar foi lançada em outubro de 2014, como parte da versão 217 do sistema. Systemd-consoled foi removido do systemd em 29 de julho de 2015 por David Herrmann.

journald

systemd-journald é um daemon responsável pelo registro de eventos, com arquivos binários anexados apenas servindo como seus arquivos de log. O administrador do sistema pode escolher se deseja registrar eventos do sistema com systemd-journald, syslog-ng ou rsyslog. A corrupção e a ofuscação do formato binário levou a um debate muito aceso.

logind

systemd-logind é um daemon que gerencia logins do usuário e assentos de várias maneiras. Trata-se de um gerenciador de logon integrado que oferece melhorias multiseat e substitui o ConsoleKit, que não é mais mantido. Para os window managers X11 a substituição para logind requer uma quantidade mínima de portabilidade. Ele foi integrado na versão systemd 30.

networkd

networkd é um daemon para lidar com a configuração das interfaces de rede; Na versão 209, quando foi integrado pela primeira vez, o suporte foi limitado a endereços estaticamente atribuídos e suporte básico para configuração de ponte. Em julho de 2014, a versão 215 do sistema foi lançada, adicionando novos recursos, como um servidor DHCP para hosts IPv4 e suporte a VXLAN.

timedated

systemd-timedated é um daemon que pode ser usado para controlar configurações relacionadas ao tempo, como a hora do sistema, o fuso horário do sistema ou a seleção entre o UTC e o relógio do sistema de fuso horário local. É acessível através de D-Bus. Ele foi integrado na versão systemd 30.

udevd

udev é um gerenciador de dispositivos para o kernel do Linux, que manipula o diretório /dev e todas as ações do espaço do usuário ao adicionar / remover dispositivos, incluindo o carregamento do firmware. Em abril de 2012, a árvore de origem para udev foi mesclada na árvore de origem systemd.

libudev

É a biblioteca padrão para utilizar udev, que permite que aplicativos de terceiros consultem recursos udev.

systemd-boot

systemd-boot é um gerenciador de inicialização, anteriormente conhecido como gummiboot. Kay Sievers fundiu-lo em systemd com rev 220.

Front-ends gráficos

Captura de tela do systemd-ui, um frontend baseado em GTK+ para systemd

Algumas interfaces gráficas estão disponíveis, incluindo:

Systemd-ui

Também conhecido como systemadm, é um front-end gráfico simples baseado em GTK+ para systemd. Ele fornece uma interface de usuário simples para gerenciar serviços e um agente gráfico para solicitar senhas do usuário. A partir de 2014, o programa systemadm recebeu pouco desenvolvimento ou manutenção nos últimos anos, porque o foco do desenvolvimento mudou para ferramentas de linha de comando como systemctl e systemd-analyze.

Systemd-kcm

Fornece um frontend do systemd gráfico para o desktop KDE Plasma 5. Ele se integra na janela de configurações do sistema e permite monitorar e controlar as unidades systemd e sessões de logind, bem como a edição gráfica de arquivos de configuração. Systemd-kcm foi renomeado para SystemdGenie e agora é um aplicativo autônomo.

Ver também

Referências

  1. «systemd 255 released». systemd-devel (Lista de grupo de correio). 6 de dezembro de 2023. Consultado em 5 de maio de 2024 
  2. «systemd». Analysis Summary. Black Duck Open Hub. Consultado em 30 de outubro de 2020 
  3. Vincent, John E. «The End of Linux - blog dot lusis». blog.lusis.org. Consultado em 29 de dezembro de 2016 
  4. «InterfaceStabilityPromise». www.freedesktop.org. Consultado em 29 de dezembro de 2016 
  5. «Linux 101: Get the most out of Systemd | Linux Voice». www.linuxvoice.com. Consultado em 29 de dezembro de 2016. Arquivado do original em 29 de maio de 2016 
  6. «Control Centre: The systemd Linux init system - The H Open: News and Features». 14 de outubro de 2012. Consultado em 29 de dezembro de 2016 
  7. «README», freedesktop.org, systemd, consultado em 9 de setembro de 2012 
  8. Poettering, Lennart. «systemd Status Update». 0pointer.de. Consultado em 29 de dezembro de 2016 
  9. Simmonds, Chris (2015). «9: Starting up - the init Program». Mastering Embedded Linux Programming. [S.l.]: Packt Publishing Ltd. p. 239. ISBN 9781784399023. Consultado em 20 de junho de 2016. systemd defines itself as a system and service manager. The project was initiated in 2010 by Lennart Poettering and Kay Sievers to create an integrated set of tools for managing a Linux system including an init daemon. 
  10. «F15 one page release notes», fedoraproject.org, 24 de maio de 2001 
  11. «#727708 - tech-ctte: Decide which init system to default to in Debian.». 25 de outubro de 2013. Consultado em 14 de setembro de 2014 
  12. «Which init system for Debian?». 5 de novembro de 2013. Consultado em 14 de setembro de 2014 
  13. «Debian Still Debating systemd Vs. Upstart Init System». Phoronix. 30 de dezembro de 2013. Consultado em 14 de setembro de 2014 
  14. «Losing graciously». 14 de fevereiro de 2014. Consultado em 14 de setembro de 2014 
  15. «Quantal, raring, saucy...». 18 de outubro de 2013. Consultado em 14 de setembro de 2014 
  16. Hess, Joey. «on leaving». Consultado em 15 de julho de 2015 
  17. Allbery, Russ (16 de novembro de 2014). «Resigning from the Technical Committee». debian-ctte (Lista de grupo de correio). Consultado em 15 de julho de 2015 
  18. Jackson, Ian (19 de novembro de 2014). «Resignation». debian-ctte (Lista de grupo de correio). Consultado em 15 de julho de 2015 
  19. Heen, Tollef Fog (16 de novembro de 2014). «Resignation from the pkg-systemd maintainer team». pkg-systemd-maintainers (Lista de grupo de correio). Consultado em 15 de julho de 2015 
  20. Carroty, Paul (28 de agosto de 2015). «Lennart Poettering merged "su" command replacement into systemd: Test Drive on Fedora Rawhide». Arquivado do original em 4 de setembro de 2015 
  21. «Assertion failure when PID 1 receives a zero-length message over notify socket #4234». 28 de setembro de 2016 
  22. Felker, Rich (3 de outubro de 2016). «Hack Crashes Linux Distros with 48 Characters of Code». Kaspersky Lab 
  23. «CVE-2017-9445 Details», National Institute of Standards and Technology (U.S.), National Vulnerability Database, 6 de julho de 2017, consultado em 6 de julho de 2018 
  24. «CVE-2017-9445», The Mitre Corporation, The Common Vulnerabilities and Exposures database, 5 de junho de 2017, consultado em 6 de julho de 2018 
  25. «systemd.slice (5) - Linux Man Pages». Consultado em 12 de março de 2018. [...] a slice [.-..] is a concept for hierarchically managing resources of a group of processes. 

Ligações externas

  • «Sítio oficial» (em inglês)