systemd

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]

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

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.

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.

• Initng
• OpenRC
• runit
• SysVinit
• Upstart

• Sítio oficial (em inglês)