Quais são os prós / contras do Upstart e systemd?

183

Parece que systemd é o novo e quente sistema init do bloco, o mesmo que o Upstart foi há alguns anos atrás. Quais são os prós / contras de cada um? Além disso, como cada um se compara a outros sistemas init?

init upstart systemd tshepang
fonte
4
@keith IIRC openrc simplesmente usa SysV, a vantagem é uma coleção bem desenhado de scripts de inicialização que usam componentes comuns e são portáteis (que significa trabalhar em qualquer shell) É uma boa limpeza, mas não é realmente uma nova initd
xenoterracide
@ xeno Sim, mas você não pode realmente dizer. não há links simbólicos rcX.d ou [KS]. Na verdade, o sysv init em si é bastante flexível, e os níveis de execução não são realmente usados ​​da maneira usual.
Keith
Embora o autor deste blog seja contra o systemd, sugiro que leia isto. Ele aborda os prós e os contras do systemd e do BSD init. textplain.net/blog/2015/…
Peschke
1
Acesse a atualização de 2016 unix.stackexchange.com/a/287282/49091 também.
igaurav
Quaisquer vantagens pretendidas do systemd não compensarão em 100 anos o custo já incorrido no mundo para implementá-lo. Cada minuto, hora ou dia gasto por um administrador de Unix para lidar com esse lixo já deve somar bilhões e para quais benefícios reais, além de alguns sinos e assobios?
Waslap 14/12

Respostas:

90

Atualização de 2016

A maioria das respostas aqui tem cinco anos, então é hora de fazer algumas atualizações.

O Ubuntu costumava usar o upstart por padrão, mas eles o abandonaram no ano passado em favor do systemd - veja:

Por isso, há um belo artigo Systemd para usuários iniciantes no wiki do Ubuntu - comparação muito detalhada entre upstart e systemd e um guia de transição de iniciante para systemd.

(Observe que, de acordo com o wiki do Ubuntu, você ainda pode executar o startstart nas versões atuais do Ubuntu por padrão instalando upstart-sysve executando, sudo update-initramfs -umas considerando o escopo do projeto systemd, não sei como ele funciona na prática, ou se o systemd está ou não possível desinstalar.)

A maioria das informações nas seções de Comandos e Scripts abaixo é adaptada de alguns dos exemplos usados ​​nesse artigo (que é convenientemente licenciado como as contribuições dos usuários do Stack Exchange sob a Licença Creative Commons Attribution-ShareAlike 3.0 ).

Aqui está uma rápida comparação de comandos comuns e scripts simples, consulte as seções abaixo para obter uma explicação detalhada. Esta resposta está comparando o comportamento antigo dos sistemas baseados no Upstart com o novo comportamento dos sistemas baseados no systemd, conforme solicitado na pergunta, mas observe que os comandos marcados como "Upstart" não são necessariamente específicos do Upstart - geralmente são comandos que são comuns a todos os sistemas Linux e Unix que não são do sistema.

Comandos

Executando su:

  • subir na vida: su
  • systemd: machinectl shell

(consulte a seção "substituição de comando su" abaixo)

Tela de corrida:

  • subir na vida: screen
  • systemd: systemd-run --user --scope screen

(consulte a seção "Eliminação inesperada de processos em segundo plano" abaixo)

Executando o tmux:

  • subir na vida: tmux
  • systemd: systemd-run --user --scope tmux

(consulte a seção "Eliminação inesperada de processos em segundo plano" abaixo)

Iniciando o trabalho foo:

  • subir na vida: start foo
  • systemd: systemctl start foo

Parando o trabalho foo:

  • subir na vida: stop foo
  • systemd: systemctl stop foo

Reiniciando o trabalho foo:

  • subir na vida: restart foo
  • systemd: systemctl restart foo

Listagem de trabalhos:

  • subir na vida: initctl list
  • systemd: systemctl status

Verificando a configuração do trabalho foo:

  • subir na vida: init-checkconf /etc/init/foo.conf
  • systemd: systemd-analyze verify /lib/systemd/system/foo.service

Listando as variáveis ​​de ambiente do trabalho:

  • subir na vida: initctl list-env
  • systemd: systemctl show-environment

Configurando a variável de ambiente do trabalho:

  • subir na vida: initctl set-env foo=bar
  • systemd: systemctl set-environment foo=bar

Removendo a variável de ambiente do trabalho:

  • subir na vida: initctl unset-env foo
  • systemd: systemctl unset-environment foo

Logs

No início, os logs são arquivos de texto normais no diretório / var / log / upstart, para que você possa processá-los normalmente:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

No systemd, os logs são armazenados em um formato binário interno (não como arquivos de texto), portanto, você precisa usar o journalctlcomando para acessá-los:

sudo journalctl -u foo
sudo journalctl -u foo -f

Scripts

Exemplo de script inicial, escrito em /etc/init/foo.conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

Exemplo de script systemd escrito em /lib/systemd/system/foo.service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

substituição de comando su

Uma susubstituição de comando foi mesclada no systemd na solicitação pull 1022:

porque, de acordo com Lennart Poettering, "su é realmente um conceito quebrado" .

Ele explica que "você pode usar su e sudo como antes, mas não espere que funcione completamente " .

A maneira oficial de obter um sucomportamento semelhante é agora:

machinectl shell

Foi explicado ainda mais por Lennart Poettering na discussão da edição 825:

"Bem, houve longas discussões sobre isso, mas o problema é que o que su deve fazer é muito claro. [...] Resumindo a história: su é realmente um conceito quebrado. Ele fornecerá uma espécie de casca , e é bom usá-lo para isso, mas não é um login completo e não deve ser confundido com um. " - Lennart Poettering

Veja também:

Matança inesperada de processos em segundo plano

Comandos como:

não funciona mais como o esperado . Por exemplo, nohupé um comando POSIX para garantir que o processo continue em execução após o logout da sessão. Já não funciona no systemd. Também programas como screene tmuxprecisam ser invocados de uma maneira especial ou, caso contrário, os processos que você executa com eles serão eliminados (embora a não eliminação desses processos seja geralmente o principal motivo da execução do screen ou tmux, em primeiro lugar).

Isso não é um erro, é uma decisão deliberada, portanto não é provável que seja corrigido no futuro. Foi o que Lennart Poettering disse sobre esse assunto:

Na minha opinião, era realmente muito estranho para o UNIX que, por padrão, deixasse o código arbitrário do usuário ficar irrestrito após o logout. Foi discutido há muito tempo entre muitas pessoas de SO, que isso deve ser possível, mas certamente não é o padrão, mas ninguém se atreveu até agora a mudar o interruptor para transformá-lo de um padrão em uma opção. Não limpar as sessões do usuário após o logout não é apenas feio e um tanto burro, mas também um problema de segurança. O systemd 230 agora finalmente apertou o botão e finalmente, por padrão, limpa tudo corretamente quando o usuário efetua logout.

Para mais informações, consulte:

Conceito de inicialização de alto nível

De certa forma, o systemd funciona ao contrário - nos trabalhos iniciados, o mais rápido possível, e no systemd, quando necessário. No final do dia, os mesmos trabalhos podem ser iniciados pelos dois sistemas e praticamente na mesma ordem, mas você pensa nisso olhando de uma direção oposta, por assim dizer.

Aqui está como o Systemd for Upstart Users explica:

Upstart modelo 's para iniciar processos (empregos) é 'ganancioso evento-based', empregos ou seja, todos disponíveis cujos eventos de inicialização acontecer são iniciados tão cedo quanto possível. Durante a inicialização, o upstart sintetiza alguns eventos iniciais, como inicialização ou rcS, como a "raiz da árvore", os serviços iniciais iniciam nesses e os serviços posteriores são iniciados quando os primeiros estão em execução. Um novo trabalho apenas precisa instalar seu arquivo de configuração no / etc / init / para se tornar ativo.

O modelo do systemd para iniciar processos (unidades) é "baseado na dependência lenta", ou seja, uma unidade será iniciada apenas se e quando alguma outra unidade inicial depender dela. Durante a inicialização, o systemd inicia uma "unidade raiz" (default.target, pode ser substituída no grub), que então se expande transitivamente e inicia suas dependências. Uma nova unidade precisa se adicionar como uma dependência da unidade da sequência de inicialização (geralmente multiusuário.target) para se tornar ativa.

Uso em distribuições

Agora, alguns dados recentes, de acordo com a Wikipedia:

Distribuições usando upstart por padrão:

Distribuições usando systemd por padrão:

(Veja Wikipedia para informações atualizadas)

Distribuições usando nem Upstart nem systemd:

Controvérsia

No passado, um fork do Debian foi proposto para evitar o systemd . O Devuan GNU + Linux foi criado - uma bifurcação do Debian sem systemd (obrigado a fpmurphy1 por apontá-lo nos comentários).

Para mais informações sobre essa controvérsia, consulte:

Como muitos de vocês já devem saber, o voto do Init GR Debian promovido por Ian Jackson não foi útil para proteger o legado do Debian e seus usuários da avalanche do sistema.

Esta situação prevê um bloqueio nas dependências do sistema, o que está de fato ameaçando a liberdade de desenvolvimento e tem sérias conseqüências para o Debian, seu upstream e downstream.

O CTTE conseguiu trocar uma dependência e ganhar tempo com uma instalação sutil do systemd sobre o sysvinit, mas mesmo esse processo foi exaustivo e cheio de drama. Por fim, há uma semana, Ian Jackson renunciou. [...]

Estou renunciando ao Comitê Técnico com efeito imediato.

Embora seja importante que as visões dos 30-40% do projeto que concordam comigo continuem sendo representadas no CT, eu mesmo sou claramente uma figura controversa demais neste momento. Devo me afastar para tentar reduzir em que medida as conversas sobre a governança do projeto são personalizadas. [...]

O Devuan nasceu de uma controvérsia sobre a decisão de usar como o sistema init padrão para o Debian. A posição oficial do Debian no systemd está cheia de reivindicações que outros desmascararam . Os leitores interessados ​​podem continuar discutindo esse tópico importante em A controvérsia do sistema . No entanto, recomendamos que você mantenha a cabeça fria e a voz civilizada. Na Devuan, estamos mais interessados ​​em programá-los de maneira errada do que olhar para trás. [...]

Alguns sites e artigos dedicados à controvérsia do systemd foram criados:

Há muitas discussões interessantes sobre o Hacker News:

Tendências semelhantes em outras distros também podem ser observadas:

Filosofia

O iniciante segue a filosofia Unix de DOTADIW - "Faça uma coisa e faça bem". É um substituto para o daemon init tradicional. Ele não faz nada além de iniciar e parar serviços. Outras tarefas são delegadas a outros subsistemas especializados.

O systemd faz muito mais que isso. Além de iniciar e interromper os serviços, ele também gerencia senhas, logins, terminais, gerenciamento de energia, redefinições de fábrica, processamento de log, pontos de montagem do sistema de arquivos, rede e muito mais - consulte o arquivo NEWS para alguns dos recursos.

Planos de expansão

De acordo com A Perspective para systemd O que foi alcançado e a apresentação de Lennart Poettering em 2014 no GNOME.asia, aqui estão os principais objetivos do systemd, áreas que já foram cobertas e que ainda estavam em andamento:

objetivos do sistema:

Nossos objetivos

  • Transformando o Linux de um pacote de bits em um sistema operacional de uso geral competitivo.
  • Construindo o sistema operacional de próxima geração da Internet Unificando diferenças sem sentido entre distribuições

  • Trazendo a inovação de volta ao SO principal

  • Desktop, Servidor, Contêiner, Incorporado, Móvel, Nuvem, Cluster,. . . Essas áreas estão mais próximas do que você imagina

  • Reduzindo a complexidade do administrador, a confiabilidade sem supervisão
  • Tudo introspectável
  • A descoberta automática, plug and play é fundamental
  • Nós consertamos as coisas onde elas estão quebradas, nunca as colamos

Áreas já cobertas:

O que já cobrimos:

sistema init, registro em diário, gerenciamento de logon, gerenciamento de dispositivos, gerenciamento de arquivos temporários e voláteis, registro de formato binário, salvamento / restauração de luz de fundo, salvamento / restauração de rfkill, bootchart, readahead, configuração de armazenamento criptografado, descoberta de partição EFI / GPT, máquina virtual / contêiner registro, gerenciamento mínimo de contêiner, gerenciamento de nome de host, gerenciamento de localidade, gerenciamento de tempo, gerenciamento aleatório de sementes, gerenciamento de variáveis ​​sysctl, gerenciamento de console,. . .

Trabalho em progresso:

No que estamos trabalhando:

  • Gerenciamento de rede
  • systemd-networkd
  • Cache DNS local, respondedor mDNS, respondedor LLMNR, verificação DNSSEC
  • IPC no kernel
  • kdbus, sd-bus
  • Sincronização de tempo com NTP
  • systemd-timesyncd
  • Maior integração com contêineres
  • Sandbox de Serviços
  • Sandbox de aplicativos
  • Formato de imagem do SO
  • Formato de imagem do contêiner
  • Formato de imagem da aplicação
  • GPT com descoberta automática
  • Sistemas sem estado, sistemas instantâneos, redefinição de fábrica
  • / usr é o sistema operacional
  • / etc é (opcional) configuração
  • / var é o estado (opcional)
  • Inicialização e atualizações do nó atômico
  • Integração com a nuvem
  • Gerenciamento de serviço entre nós
  • Imagens verificáveis ​​do SO
  • Todo o caminho até o firmware
  • Carregamento de inicialização

Escopo desta resposta

Como fpmurphy1 observou nos comentários, "Deve-se ressaltar que o systemd expandiu seu escopo de trabalho ao longo dos anos muito além do simples início de inicialização do sistema".

Tentei incluir a maioria das informações relevantes aqui. Aqui, estou comparando os recursos comuns do Upstart e systemd quando usados ​​como sistemas init, conforme solicitado na pergunta, e mencionei apenas os recursos do systemd que vão além do escopo de um sistema init porque eles não podem ser comparados ao Startup, mas sua presença é importante para entender a diferença entre esses dois projetos. A documentação relevante deve ser verificada para mais informações.

Mais informações

Mais informações podem ser encontradas em:

Extras

A equipe do LinOxide criou uma folha de dicas do Systemd vs SysV Init Linux .

rsp
fonte
4
... e uma bifurcação do Debian ocorreu. O Devuan GNU + Linux é um fork do Debian sem o systemd.
precisa saber é o seguinte
2
Deve-se ressaltar que o systemd expandiu seu escopo de trabalho ao longo dos anos muito além do simples início da inicialização do sistema.
precisa saber é o seguinte
1
Excelente post e extremamente útil para Cent guy. Obrigado por tomar o tempo senhor !!!
Origin1tech
4
@ronsmith service <foo> start/stop/restart/statusainda funciona muito bem. Como a maioria dos softwares unix, o systemd fornece compatibilidade de comandos com padrões conhecidos.
Shadur
2
Resposta muito boa. Porém, um ponto: os sistemas operacionais BSD não são distribuições Linux: são sistemas operacionais Unix diferentes com seu próprio kernel.
Giorgio
68

Tanto o iniciante quanto o systemd são tentativas de resolver alguns dos problemas com as limitações do sistema init SysV tradicional. Por exemplo, alguns serviços precisam iniciar após outros serviços (por exemplo, você não pode montar sistemas de arquivos NFS até que a rede esteja em execução), mas a única maneira de lidar com o SysV é definir os links no diretório rc # .d de modo que um esteja antes do outro. Além disso, pode ser necessário renumerar tudo mais tarde, quando as dependências forem adicionadas ou alteradas. Upstart e Systemd têm configurações mais inteligentes para definir requisitos. Além disso, há o problema com o fato de que tudo é algum tipo de script de shell, e nem todos escrevem os melhores scripts de inicialização. Isso também afeta a velocidade da inicialização.

Algumas das vantagens do systemd eu posso ver:

  • Todo processo iniciado obtém seu próprio cgroup ou um cgroup específico.
  • Pré-criação de soquetes e identificadores de arquivo para serviços, semelhante ao xinetd para seus serviços, permitindo que serviços dependentes iniciem mais rapidamente. Por exemplo, systemd manterá aberta a manipulação de arquivo para / dev / log para syslog, e os serviços subseqüentes enviados para / dev / log terão suas mensagens em buffer até que o syslogd esteja pronto para assumir o controle.
  • Menos processos são executados para realmente iniciar um serviço. Isso significa que você não está escrevendo um script de shell para iniciar seu serviço. Isso pode ser uma melhoria de velocidade e (IMO) algo mais fácil de configurar em primeiro lugar.

Uma desvantagem que conheço é que, para aproveitar a pré-localização do socket / FH do systemd, muitos daemons precisarão ser corrigidos para que o FH seja transmitido a eles pelo systemd.

jsbillings
fonte
13
O PulseAudio é um sistema de som muito difamado ( pulseaudio.org ), originalmente escrito por Lennart Poettering, autor do systemd. Eu estava principalmente fazendo uma piada aqui, porque conheço várias pessoas que gostam de reclamar sobre o pulseaudio e tenho certeza de que também reclamariam do systemd. Honestamente, não tive problemas com o systemd ou o pulseaudio.
Jsbillings
4
Dá quase um pinheiro pelos abundantes fiordes do Plan9 ... tudo é um arquivo.
dhchdhd
4
Para ser sincero, o pulseaudio foi a solução para um problema inexistente. Não há nada que a PA possa fazer que a ALSA não possa, e eu ouvi MUITAS pessoas tendo problemas com a PA repetidas vezes.
WhyNotHugo
3
Você perdeu duas desvantagens do sistema: (1) todos os scripts de inicialização precisam ser reescritos. (2) há muito menos compatibilidade com sistemas operacionais não-linux (como BSDs, por exemplo).
WhyNotHugo
8
Apenas ótimo. Veja 0pointer.de/blog/projects/the-biggest-myths . Testemunhei o crescimento do systemd e posso atestar que muitas das críticas aqui apresentadas são completamente infundadas. No link, você encontrará um golpe por golpe, refutação fundamentada .
precisa saber é
30

Vi systemdmencionado no Arch General ML hoje. Então leia sobre isso. O H Online, como sempre, é uma excelente fonte para a Tecnologia Linux e foi onde encontrei o meu lugar para começar a pesquisar o Systemd como a alternativa SysV Init e Upstart . No entanto, o artigo do H Online (neste caso) não é uma leitura muito útil, o uso real por trás disso é fornecer links para as leituras úteis.

A resposta real está no anúncio do systemd . O que fornece alguns pontos cruciais do que há de errado com o SysV initd e o que os novos sistemas precisam fazer

  • Para começar menos.
  • E para começar mais em paralelo.

Seu principal plano para fazer isso parece ser o de iniciar serviços apenas quando necessário e iniciar um soquete para esse serviço, para que o serviço necessário possa se conectar ao soquete criado muito antes de o daemon estar totalmente online. Aparentemente, um soquete retém uma pequena quantidade de dados em buffer, o que significa que nenhum dado será perdido durante o atraso; ele será tratado assim que o daemon estiver online.

Outra parte do plano parece não ser serializar sistemas de arquivos, mas montar os sob demanda também, dessa forma, você não está esperando o seu /home/, etc (para não confundir com /etc) a montagem e / ou fsckquando você pode daemons iniciando como /e /var/etc, já estão montados. Ele disse que iria usar autofs para esse fim.

Ele também tem o objetivo de criar .desktopdescritores de init de estilo como um substituto para scripts. Isso impedirá toneladas de shprocessos lentos e ainda mais bifurcações de processos de coisas como sede grepque são frequentemente usadas em scripts de shell.

Eles também planejam não iniciar alguns serviços até que sejam solicitados, e talvez até desligá-los se não forem mais necessários, o módulo bluetooth e o daemon são necessários apenas quando você estiver usando um dispositivo bluetooth, por exemplo. Outro exemplo dado é o daemon ssh. Este é o tipo de coisa que o inetd é capaz. Pessoalmente, não tenho certeza se gosto disso, pois pode significar latência quando preciso deles e, no caso do ssh, acho que significa uma possível vulnerabilidade de segurança, se meu inetd estivesse comprometido, todo o sistema estaria. No entanto, fui informado de que usar isso para violar esse sistema é inviável e que, se eu quiser, posso desativar esse recurso por serviço e de outras maneiras.

Aparentemente, outro recurso será a capacidade de iniciar com base em eventos de horário, em um intervalo agendado regularmente ou em um determinado horário. Isso é semelhante ao que cronde atdfazemos agora. Embora me disseram que não suportará o usuário "cron". Pessoalmente, isso parece a coisa mais inútil. Eu acho que isso foi escrito / pensado por pessoas que não trabalham em ambientes multiusuário, não há muito propósito para o usuário agendar se você é o único usuário no sistema, além de não estar executando como root. Trabalho diariamente em sistemas multiusuário, e a regra é sempre executar scripts de usuário como usuário. Mas talvez eu não tenha a previsão que eles têm, e isso não fará com que eu não possa correr crondou atdque não machuque ninguém além dos desenvolvedores, suponho.

A grande desvantagem do systemd é que alguns daemons precisarão ser modificados para tirar o máximo proveito dele. Eles funcionarão agora, mas funcionariam melhor se fossem escritos especificamente para seu modelo de soquete.

Parece que, em grande parte, o problema dos povos do sistema com o inicio é o sistema de eventos, e eles acreditam que não faz sentido ou é desnecessário. Talvez as palavras deles sejam as melhores.

Ou, para simplificar: o fato de o usuário iniciar o D-Bus de maneira alguma é uma indicação de que o NetworkManager também deve ser iniciado (mas é isso que o Upstart faria). É o contrário: quando o usuário solicita o NetworkManager, isso é definitivamente uma indicação de que o D-Bus também deve ser iniciado (o que certamente é o que a maioria dos usuários esperaria, certo?).
Um bom sistema de inicialização deve iniciar apenas o necessário e sob demanda. Preguiçosamente ou paralelamente e com antecedência. No entanto, não deve iniciar mais do que o necessário, principalmente nem tudo instalado que possa usar esse serviço.

Como eu já disse, isso é discutido de maneira muito mais abrangente no anúncio do systemd .

xenoterracida
fonte
desculpe, mas o anúncio é como um livro. Eu tenho que ler e grochar, antes que eu possa realmente incluir mais aqui.
Xenoterracide
2
Como isso é melhor do que a resposta de @ John? É um espaço reservado? Uma promoção do H Online ?
tshepang
1
@tshepang bem, na verdade, ele tem links para o anúncio do sistema d e o material on-line tem links para esse e outros links interessantes. é uma leitura longa e tediosa. Devo acrescentar mais uma vez que eu tenha grunhido ... esse não é um assunto simples . quando escrevi isso, achei que você poderia querer começar a ler mais cedo ou mais tarde. mas sinta-se livre para me modificar. certamente a resposta do @jsbillings é decente e melhor do que a minha até agora. mas não tão bom quanto ler o anúncio em si
xenoterracide
@tshepang Provavelmente vou adicionar mais amanhã, depois de dormir. O material on-line era apenas eu sendo um bom jornalista e citando minhas fontes.
Xenoterracide
@tshepang. Eu atualizei minha resposta. Tenho certeza de que estou pronto, a menos que as pessoas úteis em irc: //frenode.net/systemd decidam que desejam oferecer uma correção de algum tipo.
Xenoterracide
11

Bem, uma coisa que muitos de vocês esqueceram é a organização dos processos nos cgroups .

Portanto, se o systemd iniciou alguma coisa, ele a colocará em seu próprio cgroup e não há meios (sem privilégios) para o processo escapar desse cgroup. Aqui estão as consequências disso:

  • Um administrador de um grande sistema com muitos usuários possui novas maneiras eficientes de identificar usuários / processos maliciosos.
  • As prioridades para o agendamento da CPU podem ser determinadas melhor como feito pelo "patch do autocgroup Wonder" .
tshepang
fonte
8

Para uma visão muito detalhada do systemd, começando com os primeiros rascunhos de design (e uma crítica detalhada dos sistemas init existentes, incluindo o iniciante e como o systemd se propõe a corrigi-los), acesse a página inicial . Com o tempo, vários artigos sobre inicialização foram publicados no LWN . Apenas esteja ciente de que qualquer menção a systemd (ou pulseaudio) aciona inflamações infindáveis.

IMVHO (e como usuário do Fedora) estou muito feliz com isso. Algo nessa linha estava muito atrasado para lidar com a complexidade dos sistemas Linux atuais. O Fedora usou o upstart por um tempo, mas nunca saiu do estágio de ser um substituto sofisticado para o sysvinit, executando principalmente scripts init inalterados. Sua promessa de simplificar a configuração de inicialização custa mais uma vezconfigurar manualmente interdependências e isso simplesmente não funciona. O systemd calcula as dependências por si só (ou apenas permite iniciar coisas sem considerar as dependências, elas se resolvem). Outra grande vantagem (alguns dizem que é uma grande desvantagem) é que ele explora recursos específicos do Linux ao máximo (notavelmente, o cgroups permite isolar um daemon e todos os seus descendentes, por isso é fácil monitorar, limitar os recursos ou matá-los como um grupo; existem muitos outros).

vonbrand
fonte
3

Registro no diário - O Systemd é literalmente como a pasta WinSXS quando se trata de registrar coisas, ele cria cópias de cópias, a menos que você exclua ou reduza manualmente o tamanho do arquivo que ele continuará corroendo sua unidade. Eu chamo isso de cookies do carregador de inicialização.

Bert
fonte
errado. essas não são cópias e possui limite configurável freedesktop.org/software/systemd/man/journald.conf.html
pal